W3C home > Mailing lists > Public > www-rdf-interest@w3.org > September 2000

Re: RDFS bug "A property can have at most one range property"

From: Tim Berners-Lee <timbl@w3.org>
Date: Mon, 11 Sep 2000 16:50:37 -0400
Message-ID: <01aa01c01c32$175a99d0$84001d12@w3.org>
To: "Dan Brickley" <danbri@w3.org>
Cc: <www-rdf-comments@w3.org>, <www-rdf-interest@w3.org>

----- Original Message -----
From: "Dan Brickley" <danbri@w3.org>
To: "Tim Berners-Lee" <timbl@w3.org>
Cc: <www-rdf-comments@w3.org>; <www-rdf-interest@w3.org>
Sent: Monday, September 11, 2000 1:06 PM
Subject: Re: RDFS bug "A property can have at most one range property"


>
> <Sigh/>
>
> I'm inclined to agree.


Inclined? *Inclined?!* You mean there is some possible way in which this
is anything other than a bug!?

> A similar problem comes from implied rdfs:range constraints when an
> application defines an rdfs:subPropertyOf some already-constrained
> property.
>
> example (to use an eg from the old MCF submission
> http://www.w3.org/TR/NOTE-MCF-XML/):
>
>
> rdfs:domain(util:author,util:Document).
> rdfs:range(util:author,util:Person).
>
> ...locally specialised as follows for some 2nd vocabulary:
>
> rdfs:subPropertyOf(s2:technicalAuthor,util:author).
> rdfs:range(s2:technicalAuthor,s2:Engineer).
>
> (in some cartoon world where the technical-author of things will always
> be engineers)
>
> >From one perspective, there are now two rdf:range constraints in effect
> against technicalAuthor, which is fine so long as
> rdfs:subClassOf(s2:Engineer,util:Person). This isn't what the spec says;
> as currently specified, 'there can only be one'.

This "can only be one" actually means nothing in RDF. Can only be in where?
then only sort of constraint you could apply is cardinality=1 which means
that is two things are both ranges of the same thinmg they must be
equivalent
in some way. This would give you
    daml-o:equivalent(s,t)   <=  range(p,s) & range(p,t)
This is of course not the case with range as in your example above.

> This makes it difficult
> to exchange partial knowledge, such as the claim that the technicalAuthor
> of a resource will always be a Person.


"Difficult" is rther an understatement when a spec has something in
it which makes no sense.

> It seems to me cleaner to allow multiple range statements, and be clear
> about what they allow you to infer, rather than assert baldly that 'there
> can only be one'.
>
> Regarding rdfs:domain's weak semantics (as specified it might be useful

I prefer "void" to "weak" actually.

> for hinting to a GUI about possible classes, for eg, but not for
> inference), Ralph's msg is at
> http://lists.W3.org/Archives/Public/www-rdf-comments/2000AprJun/0042.html
> and was crossposted to www-rdf-interest, www-rdf-comments, and the RDF
> Schema WG list. There was only one reply.
>
> I'd encourage anyone who shares Tim's concern that rdfs:domain be
> redefined to followup up the above post (citing implementation experience
> details etc if possible). Ditto for the rdfs:range concern. It's pretty
> late in the process with RDFS. All specs get last minute rushed in bugfix
> and enhancement suggestions. If we want to change things at this late
> stage, we'll need to amass a persuasive case that this is the right thing
> to do.
>
> Dan
>
> On Mon, 11 Sep 2000, Tim Berners-Lee wrote:
>
> > Apologies for the late submission of this comment on RDF-Schema
> > http://www.w3.org/TR/2000/CR-rdf-schema-20000327/
> >
> > On looking at the excellent analysis
> > "A Logical Interpretation of RDF" Wolfram Conen
> > and Reinhold Klapsing can be accessed at:
> > http://nestroy.wi-inf.uni-essen.de/rdf/logical_interpretation.ps
> > (Postscript-Format)
> > http://nestroy.wi-inf.uni-essen.de/rdf/logical_interpretation.pdf
> > (PDF-Format)
> > http://nestroy.wi-inf.uni-essen.de/rdf/logical_interpretation/index.html
> > (HTML-Format)
> > see
http://lists.w3.org/Archives/Public/www-rdf-interest/2000Aug/0122.html
> >
> >
> > (an great sort of thing to happen during CR period , BTW), I find that
it
> > points out where there is clearly a bug in
> > http://www.w3.org/TR/2000/CR-rdf-schema-20000327/#s3.1.3
> >  in that it says that "A property can have at most one range property. "
> > This basically doens't mean anything on the web.
> >
> > (Why haven't I spotted that before? I guess just skipped over range and
> > domain
> > assuming they had their normal meanings).
> >
> > An redfs:range statement about a Property allows one to infer a Class of
> > anything which is the value of that property. The semantics are
> >
> >           rdf:type(x,s)   <= rdfs:range(p,s)  & p(y,x)
> >
> > For example, if s is a range of p, then also so is any t superset of s.
> >
> > It is quite reasonable to make two range statements, which together
> > of course imply that any value must be in the intersection of the ranges
> > given.
> >
> > Saying range(p,t)  should not be illegal! In other words, Conen &
Klapsing's
> > range_cardinality_violation (equation 22) should not be a violation of
> > anything.
> >
> > Ironically, an example of the correct semnatics fo range is actually
given:
> > "The rdfs:range of rdfs:range is the class rdfs:Class. This indicates
that
> > any resource that is the value of a range property will be a class. "
> >
> > This is a closed world type of problem.  The "it is not permitted to
express
> > two or more range constraints on a property"  doesn't specify a scope
within
> > which those delcarations are made. A global scope is of course
impossible to
> > ever validate - how can you know whether anyone else has expressed a
range
> > constraint on a given property?
> >
> > The note in the spec deals with the problem of expressing the range
being a
> > union and mentions that you can't (of course) do that with mutiple range
> > statements.
> >
> > Please remove the offending wording from the spec.
> >
> >   Tim BL
> > ________________________________________________________________
> >
> > PS: The analysis also demonstrates the problem with domain in the not
sign
> > in eqn20, showing domain is meaningless as stated in the spec, but this
bug
> > has been documented already in comments to the spec.
> >
> >
> >
>
Received on Monday, 11 September 2000 16:51:45 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:51:44 GMT