Re: Issue http://www.w3.org/2000/03/rdf-tracking/#rdfms-not-id-and-resource-attr

>>>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