Re: Domain/Range Woes

Bob,

I'm afraid I don't understand your explanation below.  I tried using Protege
and applying the same predicate to different (non-inherited) classes, but it
just put multiple domain constraints into the schema.  I haven't read the
full Protege manual yet, but I thought I might be able to quickly ascertain
what you mean when you said "subdomain".

Also, can you elaborate on the "Union" option.  Do you mean to say that I
create a class as the union of two or more other classes?  For example,
"Nameable" is the union of "Person" and "ContentProvider".  How is that any
different from making "Person" and "ContentProvider" subclasses of
"Nameable"?

--- Stephen


----- Original Message -----
From: "Bob MacGregor" <macgregor@ISI.EDU>
To: "Brian McBride" <bwm@hplb.hpl.hp.com>; "Stephen K. Rhoads"
<rhoads@thrupoint.net>; <www-rdf-interest@w3.org>
Sent: Friday, January 31, 2003 11:32 AM
Subject: 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 Wednesday, 5 February 2003 16:53:24 UTC