RDF Schema discussion for F2F day 2: domain/range notes, model theory

RDF Core-ists,

So... I have an [action] to send round RDF Schema issue discussion points
prior to the F2F. I asked Brian to reserve an agenda slot for RDFS issues
on day 2 so that we can start to get things moving on RDF Schema again.

I don't know about the rest of you, but my RDFCore brain cells have been
totally swamped by the Model/Syntax discussions in the last week or 2. I
take this as a warning sign that it might be counter-product to try to get
folk thinking about RDFS in great detail too. Nevertheless, it is
important that we make a start towards re-activiting  RDF Schema during
the meeting, and identifying WG members with a particular interest in
this aspect of our work.

We have a number of issues on the issue list related to RDFS; the only
meaty one that's officially open for discussion is

http://www.w3.org/2000/03/rdf-tracking/#rdfs-domain-and-range
	[[
	Issue rdfs-domain-and-range: Should a property be allowed more than one
	rdfs:range property?
	What should the semantics of multiple domain and range properties be?
	]]

the issue url points into the RDF mailing list archives, which I won't
attempt to reproduced or summarise here. I have tried (and failed) to get
a detailed technical summary of  this issue to the WG in time
for next weeks meeting. In absence of same,  I leave it to Brian's
judgement as to how much face-to-face time to spend on the issue. I'll use
this message to provide some background to discussion of this issue,
putting it in the context of the original RDF Schema design discussions.

So Here, for the record, is the situation (as I see it personally) w.r.t.
rdfs:domain/rdfs:range... These notes assume some familiarity with the
issue as summarised at the above URL and in the hyperlinked messages
gathered there.


First, rdfs:domain

rdfs:domain as currently defined is pretty weak; it serves as a _hint_
that some property is particularly applicable to some specified class.
Many implimentors want the definition changed so that we can draw
inferences when we see rdfs:domain-constrained properties used.


Historical notes on rdfs:domain semantics

the weak semantics of rdfs:domain were fixed by the
original RDF Schema 1.0 WG _before_ we invented the notion of
rdfs:subPropertyOf, a construct that allows us to describe hierarchical
relations amongst similar properties: eg. util:biologicalParent
might have more specialised "sub properties" such as util:humanParent or
util:canineParent. We can say that the rds:domain of util:humanParent
was util:Human, and that the rdfs:domain of util:canineParent is
util:Canine. One the current (weak) definition of rdfs:domain, we can't
infer from this that any object that has a util:canineParent property is a
util:Canine. The widely-requested change to a conjunctive semantics for
rdfs:domain would allow such an inference.

But how did we get into this situation? Here's history-as-I-remember it:
in the old days, we didn't  have rdfs:subPropertyOf, and the prospect of
having to create a new type of property, ie. util:xyzParent,
util:abcParent etc for use with each kind
of thing that can have a parent was mildly distressing for the WG, since
there was no way for RDF processors to tell that these properties
basically meant the same thing. Consequently, the WG decided to weaken the
meaning of rdfs:domain to merely mean "...may be applicable against
resources of type...". This allowed a (rather awkward) compromise, whereby
we could have a common property, eg. util:parent, and give it multiple
domains, eg. util:Mammal, util:Human, util:Canine.

The RDF Schema WG also considered in some detail some designs for
class-contextualised constraints. For example, over 3 years ago I made a
proposal to introduce 'class specific constraints' into RDF Schema.
For the old, W3c-Member protected archive of this discussion see:

http://lists.w3.org/Archives/Member/w3c-rdf-schema-wg/1998AprJun/0300.html
	From: Dan Brickley <Daniel.Brickley@Bristol.ac.uk>
	To: w3c-rdf-schema-wg <w3c-rdf-schema-wg@w3.org>
	Message-ID: <Pine.HPP.3.96.980618143406.6517F-100000@mail.ilrt.bris.ac.uk>
	Subject: Open Issue C23: Class-specific constraints -- proposed closure

This mechanism was considered by the RDFS 1.0 WG but deferred to future
work (I believe the DAML+OIL proposals now contain something similar). The
reason for providing this bit of background is to help us understand the
context to our current RDFS open issue, ie. the design options considered
at the time the current meaning of rdfs:domain was fixed. I am now firmly
of the opinion that the original WG made a mistake: we published RDF
Schema 1.0 with a weakened rdfs:domain, and did not revise this decision
when we went on and...:

 - decided to postpone the 'class specific constraint' machinery to future work
 - introduced rdfs:subPropertyOf as a means of inter-relating families of
   similar RDF property types.

My reading of the RDF mailing list discussions around range and domain is
that the dominant view amongst RDF Schema implementors is in favour of
redefining rdfs:domain so that we can conclude "type(songlines,Book)"
when we see "domain(author,Book), author(songlines,chatwin)". As I say,
I've been buried under the existing RDF Core traffic (anonymous nodes etc)
so haven't assembled an overwhelming case for this claim.  (WG members in
favour of the current definition should make their views known!)

Regarding rdfs:range, I believe the situation is simpler: the spec is
simply in error when it says a property can have only one range. This is
confusing when we consider implied ranges in context of sub-properties.
The DAML+OIL spec seems to clean this up nicely.

I'd (?naively) like to think we could close this issue during the face to
face, and have time to spare. If we manage such a thing, I propose we use the time
to consider the new RDF Model Theory work and how it could relate to our
treatment of datatyping of literals in RDF Schema. Currently the RDF
Schema spec merely says, in effect, "Literals have types (classes)
indicated by URI; we leave the details to future work". The model theory
should provide a basis for this work to be completed.

Apologies for not getting these notes out more in advance of the meeting.

See you all next week.

Dan

Received on Saturday, 28 July 2001 00:55:28 UTC