Re: Domain/Range Woes

Stephan,

A few more remarks, in addition to Peter's and Brian's.  What you really
want is a new predicate (I'll call it "subdomain") that means "Whatever the
domain is, this domain is included in it."  So if I say
     [name subdomain Person]
     [name subdomain ContentProvider]
then if the "true" (unmentioned) rdfs:domain is D, then Person and 
ContentProvider
are subclasses of D.

The Protege system got this right -- their domain construct has the 
semantics of
the 'subdomain' that I just made up.  They got it right partly because they 
have been
in the knowledge acquisition business for more than a decade (I'm an avid 
Protege
user).  If you encounter
enough examples, you will find that what you are implicitly looking for is 
in fact
quite a common occurrence in ontologies, but is frequently not 
well-supported by
KR systems.  Being forced to choose overly general domains (one-size-fits-all)
using rdfs:domain is often quite unsatisfactory.

The solution of using the DAML/OWL union construct comes closest to giving
you what you want.  However, the union construct is non-modular.  If a
user wants to extend a union domain by  adding a new 'subdomain' to it, that
requires modifying the original union definition.  If this user is not the 
owner of
the declaration that defines the union, then he/she is out of luck.

Summing up, this is another example where the desire for simplicity in
a logic framework runs counter to real-world modeling needs.  Once we have 
rules, then
designing your own 'subdomain' predicate is easy.  Meanwhile, you just have
to tough it out.

Cheers, Bob




At 05:57 AM 1/31/2003 +0000, Brian McBride wrote:

>Stephen,
>
>A few remarks in addition to Peter's.
>
>If you wish to stay just with RDFS:
>
>It might be worth thinking about what the domain/range statements might be 
>used for.  Possible answers include:
>
>   - validating data
>   - inferring the types of things from their properties
>   - adaptive user interfaces (only showing options that are appropriate 
> to type)
>
>As you point out, sometimes one can have properties that are pretty 
>general in nature.  Lets take name as an example.  One option is, for each 
>such property, is to define a class for its domain, say Nameable.  Then 
>you, or anyone else, can define, each class that can take a name to be a 
>subclass of Nameable.  This approach can support data validation and 
>adaptive user interfaces, but its not much good for inferring types of 
>things from their properties.
>
>An alternative which is better for type inference, is as you suggest, 
>define different properties for each class, such as directorsName, 
>songName etc.  You can define an appropriate domain for each such 
>property, which would allow an RDFS reasoner to make more meaningful type 
>deductions about resources with those properties. It may also be useful to 
>make each such property a subproperty a subproperty of a more general 
>property, say name, so one can, for example query for all names.
>
>Brian
>
>These might defeat your desire for simplicity.
>
>Brian
>
>
>
>At 17:42 30/01/2003 -0500, Stephen K. Rhoads wrote:
>
>>So, given the new "conjunctive" rule governing domain and range constraints,
>>I'm running into problems in the production of my very first
>>(read newbie) RDF schema.  In particular, I find that I have many predicates
>>which apply equally to seemingly disparate types of classes.
>>
>>Here are some examples:
>>
>>-- Predicate "name" could be applied to both "Person" and "ContentProvider"
>>
>>-- Predicate "directedBy" could be applied to the classes "Movie" and
>>"TelevisionProgram", but not to "Song", even though all are subclasses of
>>"Content"
>>
>>I do have an appreciation for the fact that the new rule forces you to think
>>harder about classification of objects, and that in the above
>>examples there is likely some (obscure) superclass to which the predicates
>>can be safely applied (eg "ObjectsWithNames" ... "DirectedContent").  But in
>>the interest of encouraging adoption for this nascent protocol, I want to
>>keep it very simple.
>>
>>What are my options (short of copping out and using, for example,
>>"movieDirectedBy" / "programDirectedBy" or "personName" / "providerName")?
>>
>>--- Stephen
>
>Robert MacGregor
>Project Leader
>USC Information Sciences Institute
>4676 Admiralty Way, Marina del Rey, CA 90292
>macgregor@isi.edu
>Phone: 310/448-8423, Fax: 310/822-6592
>Mobile: 310/251-8488

Received on Friday, 31 January 2003 11:32:21 UTC