VOEvent Ontology

Development

I am using Protege 3.0 to develop an OWL-DL ontology of the VOEvent 0.90 schema.

Links

• http://www.ivoa.net/internal/IVOA/IvoaVOEvent/VOEvent-v1.0.xsd - VOEvent 1.0 schema
• http://www.ivoa.net/internal/IVOA/IvoaVOEvent/VOEvent-0.90.pdf - VOEvent 0.90
• http://monet.uni-goettingen.de/twiki/bin/view/RTML/ - Remote Telescope Markup Language
• http://www.ivoa.net/Documents/PR/STC/STC-20050315.html - Space-Time Coordinates Metadata for the VO
• http://www.co-ode.org/resources/tutorials/ProtegeOWLTutorial.pdf - Protege OWL Tutorial

Current Questions / Notes

1. Experiment: try making datatype (string, anyURI, dateTime) properties of elements that were previously classes. For example, instead of class Email with associated object property hasEmail, have one datatype property (string) Email.
2. What to do about name vs Name? "Name" is associated with classes like Contact, but "name" is associated with Group and Param.
3. TO DO: Have imported STC ontology in import policy file - how to make VOEvent ObservationLocation^? pick up STC ObservationLocation^??
4. EventID^? - would like to make anyURI datatype property, but it has cite datatype property.

Previous Questions (for 0.90 ontology)

1. How do I include objects and properties from one OWL formatted ontology into another OWL formatted ontology? For instance, the WhenWhere element of the VOEvent schema can "be any legal STC expression", according to VOEvent 0.90. It would make more sense to develop an ontology(ies) for STC and reference the classes / properties from VOEvent than it would be to shoehorn all of STC into the VOEvent ontology.
2. Note: I use the suggested Protege tutorial notation for object properties, beginning the property name with "has" or "is". However, I use datatype properties to represent attributes, and I simply give these properties the name of the attribute. Is this bad practice?
3. The above notation has brought up a problem: for instance, both the Param and Importance classes have a value attribute. For Param, value should be a string, but for Importance, value should be an integer. Should I forget about naming datatype properties after attributes and create two new datatype properties, hasStringValue and hasIntegerValue?
4. The Protege tutorial advises that properties should have descriptive, human readable names. The "English Prose Tooltip Generator" can take advantage of such property names by turning them into specific property descriptions in documentation.
5. There is currently no hierarchy of "is a" relationships - classes are related by "has a" relationships instead. Is this bad practice? Should the ontology be reorganized into a hierarchy of concepts rather than reflecting the VOEvent schema structure?
6. Technical detail - the RTML UML for Contact shows one option of FirstName plus LastName as an alternative to Name. How do I reflect this "!FirstName must be accompanied by LastName"? I bet this is a rules engine thing.
7. Can all cardinalities or 1:N restrictions be set in the rules engine, or is there a better way to do that?
8. Is there any reason for or against making any or all of these classes disjoint?

-- ElizabethAuden - 26 May 2005

* VOEvent1.0.owl: OWL format ontology from VOEvent 1.0