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

Here are some quick comments on your questions.

Peter F. Patel-Schneider
Bell Labs Research


From: Stephen Rhoads <rhoadsnyc@mac.com>
Subject: Fwd: [protege-owl] Re: Protege-OWL Tutorial
Date: Wed, 23 Jun 2004 12:59:51 -0400

> 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)?

Yes, to me this makes perfect sense.  I would, in fact, go farther and have
both some and all restrictions, as in 

DatatypeProperty ( hasName )

Class(Person partial restriction( hasName someValuesFrom (xsd:string)
					  allValuesFrom(hasName xsd:string) ) )

of these two, the first is the most suspect, as, depending on what you mean
by a Person, there may be People with no names (e.g., unbaptized infants).

> 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"?

I don't see a particular problem here.  Make these all properties and
provide restrictions for them, as in 

DatatypeProperty ( title )

Class(Movie partial restriction( title someValuesFrom (xsd:string)
				       allValuesFrom(hasName xsd:string) ) )

you might want to make title single-valued, via 

Class(Movie partial restriction( title cardinality (1) ) )

similarly for the other properties.

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

Again, this should work well in OWL DL.  Do something like

ObjectProperty( guitarsBy range ( Person ) )

Class ( Song restriction ( guitarsBy allValuesFrom ( Person ) ) 
	     ...
      )

Note that I haven't make Song by the domain of guitarsBy, because there
might be some other kind of thing (e.g., a non-Song MusicalComposition)
that should have fillers for this property.  Note also that the restriction
on guitarsBy in Song is not logically needed - however a (very) good UI
for populating songs could take this as a hint that it would be a good idea
to make it easy to add this information for songs.  

> 3.  Class or Individuals?

[...]

Not being familiar with this example, I'm not going to respond.  However,
fixing the class/individual distinction appropriately can be tricky.

> 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>

These two appear to me to be logically equivalent.  

[...]

peter

Received on Thursday, 24 June 2004 09:05:41 UTC