Fwd: [protege-owl] Re: Protege-OWL Tutorial

Folks,

I posted this message over in the Protege-OWL mailing list and I am posting it again over here in order to get input from the wider community.

Regards,

--- Stephen
 

From: Stephen Rhoads <rhoadsnyc@mac.com>
TO: <protege-owl@SMI.Stanford.EDU>
CC: 
Date: Thu Jun 17, 2004 06:26:43 PM EDT
Subject: [protege-owl] Re: Protege-OWL Tutorial


Matthew,

Thanks a million for this *excellent* tutorial.  I was expecting 15 pages of glorified "Small Tutorial".  This is closer to an O'Reilly book!  (A hint to you maybe?)  If I had had my mitts on this puppy three months ago, it would have saved me quite a bit of grief.

Below are some followup questions which I hope that you and/or the community can answer.  I have been struggling with 1 and 2 and hoped that they would be addressed but were not.  3 is a question arising from the tutorial and 4 is both a question and suggestion for a future revision.

Again, thanks for all of your hard work.  Thanks also to Holger and the rest of the CO-ODE group.  Keep it up!

--- Stephen


1.  DLs for Datatype Properties?

Does it make sense to use DLs with Datatype properties?  By way of example, every "Person" has a "name".  Is it advisable/recommended to create a Necessary restriction for class Person of someValuesFrom(hasName, xsd:string)?

DLs seem to be great for logically describing intrinsic properties of classes of individuals, but at the "end of the day", the bulk of what we are doing with OWL is creating distributed knowledge bases containing metadata about *individuals* -- much of which is in the form of values for datatype properties.  Take an example from my project:  every Movie has a title (xsd:string), runtime (xsd:duration), various types of synopsis (xsd:string), copyrightNotice (xsd:string), episodeIndex (xsd:nonNegativeInteger) [if it's part of a series], and many others.  What is considered to be Best Practice for dealing with these types of properties in the "DL Paradigm"?

2.  Not-Quite-Necessary Conditions.

Does it make sense to use DLs to describe (for lack of a better word) "optional" properties?

Another example from my project.  There are a multitude of musical instruments in the world only a few of which will be relevant to any given "Song".  I have properties like "guitarsBy", "percussionBy", "pianoBy", "violinBy", "harpBy", "remixBy", "performedBy", "conductedBy" ... (you get the picture).

What should one do with these types of properties?  It doesn't make sense to include a Necessary restriction on class Song because, well, the properties aren't necessary.  Some options (as I see it):

-- Resort to a more traditional "frame-based" approach and add Song to the Domain of each property.  This frightens me in the "Open World".

-- Create special classes for each property:  "SongWithGuitars" is the intersection of Song and restriction someValuesFrom(guitarsBy, Person).  Well, I don't really want all of those classes in my Ontology; they don't add any value and the properties don't "show up" at class Song.

-- Just define the properties with no restrictions and use them when/where appropriate.  Then you have to manually add the properties to Individuals Forms in order to accommodate Knowledge Acquisition.

-- Create custom Annotation properties like "ex:intendedDomain" and "ex:intendedRange" in order to hint to the intended usage.  That might work, but it's not supported by Protege-OWL.

3.  Class or Individuals?

I'm confused by your use of subclasses where I would expect individuals.  Take MozzarellaTopping and TomatoTopping, for example.  Should these not be Individuals?  Then the description of a MargheritaPizza is the intersection of Pizza and restriction hasValue(hasTopping, Mozzerellla) and hasValue(hasTopping, Tomato)?

The way you've done it using someValuesFrom rather than hasValue seems to be good for describing Pizzas *in general*, but consider the case where someone goes to define an Individual MargheritaPizza using RDF and OWL -- say, "DominosMargheritaPizza".  When they go to describe the Toppings, because MozzarellaTopping and TomatoTopping are classes, rather than individuals, they would have to create "pseudo" Individuals as members of MozzarellaTopping and TomatoTopping to use in the description:

<ex:Pizza rdf:ID="DominosMargheritaPizza">
   <ex:hasTopping rdf:resource="#DominosMozzarellaTopping"/>
   <ex:hasTopping rdf:resource="#DominosTomatoTopping"/>
</ex:Pizza>

<ex:MozzarellaTopping rdf:ID="DominosMozzarellaTopping"/>
<ex:TomatoTopping rdf:ID="DominosTomatoTopping"/>

That seems awkward to me.  The below seems more logical:

<ex:Pizza rdf:ID="DominosMargheritaPizza">
   <ex:hasTopping rdf:resource="&ex;Mozzarella"/>
   <ex:hasTopping rdf:resource="&ex;Tomato"/>
</ex:Pizza>

The same thing with "SpicinessValuePartition".  Wouldn't it make more sense to make "Spiciness" an enumerated class with Individuals "Mild", "Medium" and "Hot" and then use hasValue with the "hasSpiciness" property?  Again, the way you do it, I have to create individual members of Mild, Medium and Hot to use in descriptions of individual Toppings (or anywhere I care to describe "spiciness").

4.  OWL Source Code

In a future version of the tutorial [if you are so inclined to create one ;-)] it would be very helpful if you could display and explain the OWL code resulting from operations in the GUI.

I, for one, am often confused by the underlying code.  For example, I don't understand why it is always necessary to relate a "Named" class to its restrictions/axioms via "subClassOf" or "equivalentClass".  I suspect that it has something to do with an Algebraic or logical equation.  (And maybe it's time for me to go back and re-learn that stuff from High School).

Take the SpicinessValuePartition, for example.  The resultant OWL code looks like this (edited):

<owl:Class rdf:ID="SpicinessValuePartition">
   <owl:equivalentClass>
      <owl:Class>
         <owl:unionOf rdf:parseType="Collection">
            <owl:Class rdf:about="#Mild"/>
            <owl:Class rdf:about="#Medium"/>
            <owl:Class rdf:about="#Hot"/>
         </owl:unionOf>
      </owl:Class>
   </owl:equivalentClass>
</owl:Class>

Why is the following not sufficient?

<owl:Class rdf:ID="SpicinessValuePartition">
   <owl:unionOf rdf:parseType="Collection">
      <owl:Class rdf:about="#Mild"/>
      <owl:Class rdf:about="#Medium"/>
      <owl:Class rdf:about="#Hot"/>
   </owl:unionOf>
</owl:Class>















Matthew Horridge <matthew.horridge@cs.man.ac.uk> wrote:

>
>Firstly, thanks to everyone who has downloaded the tutorial!  Thanks 
>also to the people who have responded with kind comments and feedback - 
>very much appreciated!
>
>I have uploaded a slightly modified version of the tutorial.  The 
>modification is basically a change in paper size and margin size.  I 
>have done this because some users were having problems printing the 
>tutorial (getting it to fit on a page properly) with the way it was set 
>out.  I have also included a section on cardinality restrictions.
>
>As usual the tutorial may be downloaded from here:
>
>http://www.co-ode.org/resources/
>
>Your feedback on the tutorial is welcome and will be appreciated.  I am 
>particularly interested in what people find difficult to understand, 
>how the tutorial could be improved, and what people would like to see 
>included in future versions of the tutorial or training material.  
>Please either post your feedback on the CO-ODE forum at 
>http://www.co-ode.org/forum or e-mail me.
>
>Best wishes,
>
>Matthew Horridge.
>
>-----------------------------------------------------------
>To unsubscribe go to http://protege.stanford.edu/lists.html
>
>
>
-----------------------------------------------------------
To unsubscribe go to http://protege.stanford.edu/lists.html

Received on Wednesday, 23 June 2004 12:59:53 UTC