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

> Re: RDFS bug "A property can have at most one range property"
>
> From: Tim Berners-Lee (timbl@w3.org)
> Date: Mon, Sep 11 2000
>
> *Next message: Dan Brickley: "Re: RDFS bug "A property can have at most one range property""
>
>    * Previous message: Tim Berners-Lee: "Re: RDFS bug "A property can have at most one range property""
>    * In reply to: Dan Brickley: "Re: RDFS bug "A property can have at most one range property""
>    * Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
>    * Other mail archives: [this mailing list] [other W3C mailing lists]
>    * Mail actions: [ respond to this message ] [ mail a new topic ]
>
>   ------------------------------------------------------------------------
>
> Message-ID: <000201c01c36$f3432710$84001d12@w3.org>
> From: "Tim Berners-Lee" <timbl@w3.org>
> To: "Dan Brickley" <danbri@w3.org>
> Cc: <www-rdf-comments@w3.org>, <www-rdf-interest@w3.org>
> Date: Mon, 11 Sep 2000 16:50:37 -0400
> Subject: Re: RDFS bug "A property can have at most one range property"
>
> ----- 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.

Well, it makes sense, though it may be undesirable.

Might a way around this be to allow any boolean combination of ranges to count as a range? (Maybe every
positive boolean combination, ie disallowing negation.) The letter, if not the spirit, of the single-range
restriction is then achieved, since adding subsequent range restrictions merely adds extra boolean
structure to the declared (unique) range. This does however mean that range(P,s) has to be understood as
meaning that the range of p is included in s rather than being s (if the system is to be monotonic), which
weakens the logic involved: but then it would seem that the stronger logic is virtually unusable, in any
case.

The key implementation issue is what, if anything, can now be usefully done with a range assertion. If the
information they provide about ranges is this weak, then it is difficult to extract any useful information
from them. Presumably the chief use of a range statement is to allow an inference of a contradiction (or
an error of some kind) when the argument goes out of range. But if a later assertion can widen the range,
it is impossible to make any such inference reliably. An intermediate position would be to allow
subsequent range assertions to restrict the range but not to widen it (basically, by allowing only
conjunctions rather than positive boolean combinations); but now all range restrictions presumably need to
be checked for consistency with one another, since now they can intersect to the empty case.

There is another issue. What does one do when a range constraint is more constraining than the class of
entities to which it is being applied? Is this case simply rejected, or is the machinery capable of
keeping track of the implied restriction on the thing to which the range is applied?

BTW, a similar issue came up in considering a sort inheritance system for KIF. The upshot of that
discussion was that 'strong' sorting (basically insisting on a unique range specification) was the most
computational use for a reasoning engine, but that the 'weaker' sorting was more often what users wanted.

>
>
> > 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.
> > >
> > >
> > >
> >
>
>   ------------------------------------------------------------------------
>
>    * Next message: Dan Brickley: "Re: RDFS bug "A property can have at most one range property""
>    * Previous message: Tim Berners-Lee: "Re: RDFS bug "A property can have at most one range property""
>    * In reply to: Dan Brickley: "Re: RDFS bug "A property can have at most one range property""
>    * Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
>    * Other mail archives: [this mailing list] [other W3C mailing lists]
>    * Mail actions: [ respond to this message ] [ mail a new topic ]

Received on Monday, 4 December 2000 14:14:56 UTC