[Ontology] UCDs vs ontologies?

[Ed Shaya]

Elizabeth,
    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:
<owl:Ontology rdf:about="">
    <owl:imports rdf:resource="STC.owl"/>
</owl: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
      bad practice?

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
      classes disjoint?

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 
is resolved.


Ed

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.
>
> cheers,
> Elizabeth
>