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

<Sigh/>

I'm inclined to agree.

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 makes it difficult
to exchange partial knowledge, such as the claim that the technicalAuthor
of a resource will always be a Person.

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
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 13:06:46 UTC