[Ontology] UCDs vs ontologies?
edward.j.shaya.1 at gsfc.nasa.gov
Wed Jun 1 12:34:18 PDT 2005
I will try to answer some of your questions posted at the ivoa web site.
* 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.
First you need to import the other ontology:
Then you just use them. In this case you want
http://ivoa.org/ont/STC.owl#STCEntity to be a subclass of WhenWhere. Or
you could add STCEntity in the range of hasWhenWhere.
Version 3.1 is better at working with multiple ontologies.
By the way, I am planning on working on STC.owl soon. But you are
welcome to take a first crack at it if you wish.
* *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
I am doing essentially the same thing. Also, I am making classes begin
with a capital letter and properties (object or dataproperties) start
with a lower case letter. But I could easily be convinced to have both
start with lower case unless it is a mnemonic or a proper name.
* 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?
a) your way.
b) One could just use string and then any number is acceptable as well.
c) One could use xsd:AnySimpleType for value and then in Param restrict
it to xsd:string and in Importance restrict it to integer.
Note that I prefer q:hasValue which takes a q:Quantity which has datum,
error, and units. Of course then one has an issue with datum.
* 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.
I have not seen this yet.
* 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?
You did good. The terms in VOEvent do have superclasses in the larger
ontology that I am working on, but these were not needed in what your
small cut. As one digs in deeper one may find one needs subclasses.
Classification may require subclass spectralClassificat which has
subclass MKClassification which has subclass MKLuminosityClassification etc.
* 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.
Not sure, what you mean. LastName can be functional, meaning one value
is required. Beyond that one can specify the cardinality.
* Can all cardinalities or 1:N restrictions be set in the rules
engine, or is there a better way to do that?
In the class menu, right click on the property and choose the
cardinality. At least that is how it is in 3.1.
* Is there any reason for or against making any or all of these
Not here. Be careful with disjoint. It can blow up the size of the
ontology with little benefit. A case where setting classes as disjoint
is useful is to explicitly say that you will not tolerate a galaxy
instance being classified as elliptical in one place and as a spiral in
another. You are then saying that we can not go on until this conflict
Elizabeth Auden wrote:
>> On the other hand, we're told that the role of UCDs is distinct from
>> that of ontologies. An ontology is an (attempt) at expressing the
>> complete range of some knowledge domain. Astronomy is a big subject
>> - its ontology will be big.
>> Personally, I think the VO community will need to develop several
>> separate ontologies over time as well as several separate glossaries
>> of UCDs or UCD-like constructs. It is not obvious that a glossary of
>> UCDs for tabular convenience is equivalent to a glossary of UCDs for
>> VOEvent convenience. An ontology can afford to be large and unwieldy
>> to reach its goal of being complete and accurate.
> Incidentally, I've posted a first go at a VOEvent ontology (OWL-DL
> format) on the VOTech wiki at
> http://wiki.eurovotech.org/bin/view/VOTech/VoEventOntology. Any
> comments on the structure, concepts, and coverage of this v0.000000001
> ontology would be appreciated.
More information about the dm