- From: Dave Beckett <dave.beckett@bristol.ac.uk>
- Date: Wed, 23 May 2001 11:43:40 +0100
- To: w3c-rdfcore-wg@w3.org
- CC: Brian McBride <bwm@hplb.hpl.hp.com>
>>>Brian McBride said: > Dave Beckett wrote: > > In case #1 (empty element) since rdf:ID points to the target > > resource, adding rdf:resource as well would have two statement > > objects which does not make sense. > > I'm not following you here Dave. > > <rdf:Description> > <foo:bar rdf:ID="rs">foobar</foo:bar> > </rdf:Desscription> > > is clearly legal and the rdf:ID attribute defines the URI of the refied > statement the property represents. This is legal and I agree with this as it is a non-empty element; I already described this. > The question that arises is whether > > <rdf:Description> > <foo:bar rdf:resource="http://foo/" rdf:ID="rs"/> > </rdf:Description> > > is legal, with again the rdf:ID attribute defining the URI of the reifed > statement. It does seem a bit irregular to allow the use of an rdf:ID > attribute to identify the reifed statement in the case where the object > is a literal, but not in the case where it is a resource. And strictly > speaking, the grammar does not rule it out as the rdf:resource attribute > matches the idAboutAttr? in the production and the rdf:ID attribute > matches the propAttr*. No. The propertyElt rule 6.12 does not use idAboutAttr anywhere (and indeed that production 6.5 also does not allow rdf:resource) [6.12] propertyElt ::= '<' propName idAttr? '>' value '</' propName '>' | '<' propName idAttr? parseLiteral '>' literal '</' propName '>' | '<' propName idAttr? parseResource '>' propertyElt* '</' propName '>' | '<' propName idRefAttr? bagIdAttr? propAttr* '/>' The above is an empty element so only matches the production 6.12 part 4 above where things allowed are: idRefAttr? = (0 or 1 of idRefAttr) AND bagIDAttr? = (0 or 1 of bagIDfAttr) AND propAttr* = (0 or more of propAttr) expanding: idRefAttr? = (0 or 1 of (idAttr | resourceAttr)) AND bagIDAttr? = (0 or 1 of (bagID="' IDsymbol '"')) AND propAttr* = (0 or more of (typeAttr | propName '="' string '"')) again: idRefAttr? = (0 or 1 of (' ID="' IDsymbol '"' | ' resource="' URI-reference '"')) AND bagIDAttr? = (0 or 1 of (bagID="' IDsymbol '"')) AND propAttr* = (0 or more of ( type="' URI-reference '"' | propName '="' string '"')) Now (IGNORE namespace prefix stuff here) <foo:bar rdf:resource="http://foo/" rdf:ID="rs"/> has an rdf:ID and an rdf:resource. These are not properties but syntax devices so do not match the propAttr rule, although they do match the syntax <- maybe this is where you are diverging from me. Aside 1: Parsers will continue having to look for resource/rdf:resource and other things as special cases, so they will not match general properties. Aside 2: these don't apply to the built-in rdf properties which do match propName. We know RDF syntax has issues. These RDF properties that do match propName are: rdf:type (in grammar too) rdf:value rdf:subject rdf:predicate rdf:object [maybe rdf:li rdf_<n> but that's an issue yet to discuss] Thus rdf:ID and rdf:resource can only match the first part idRefAttr? where they are alternatives and hence having both is not legal. Both the rdf:ID and rdf:resource in this case are used to point to the object of the statement, not the reification of the statement, and as I previously discussed although this is inconsistent with the normal use of rdf:ID, changing it may be break too many things. Dave
Received on Wednesday, 23 May 2001 06:43:45 UTC