- From: Bob MacGregor <macgregor@ISI.EDU>
- Date: Fri, 31 Jan 2003 08:32:09 -0800
- To: Brian McBride <bwm@hplb.hpl.hp.com>, "Stephen K. Rhoads" <rhoads@thrupoint.net>, <www-rdf-interest@w3.org>
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