RE: Parsing and Containers

Jason,

Thank you for your comments.  I have put a copy of the
proposal on the web at:

  http://www-uk.hpl.hp.com/people/bwm/rdf/issues/containersyntax/current.htm

I've also put an issues page at:

  http://www-uk.hpl.hp.com/people/bwm/rdf/issues/containersyntax/issues.htm

and added the issue that you have raised to that page.

Whether to allow rdf:li as an attribute was a close run thing
in my mind as we wrote the proposal.

One can either special case it:

  o don't implement the transformation to rdf:_n for attributes
  o disallow rdf:li in attributes (even though it is syntactically valid)
  o rdf:li always means rdf:_1 when its an attribute

or just let the standard rules apply.

I tend to the view that languages should be regular and have
few (no) special cases which is why the initial proposal is
as it is.  This does mean that one can write some pretty dumb
RDF with it, as you point out.

If the consensus is that the ambiguity should be avoided, I
think I'd prefer that rdf:li as an attribute always means
rdf:_1.  I think because that seems the 'most' regular to me.

Brian
  



> -----Original Message-----
> From: Jason Diamond [mailto:jason@injektilo.org]
> Sent: 17 December 2000 06:02
> To: McBride, Brian; RDF Interest (E-mail)
> Subject: RE: Parsing and Containers
> 
> 
> After some more thought, I think that it might be a mistake 
> to allow rdf:li
> as attributes. Example 4 demonstrates the problems this can cause:
> 
> "Example 4:
> 
>        <rdf:Description rdf:about="http://badExample" rdf:li="a"
> rdf:_3="b"/>
> 
> will generate:
> 
>         [http://badExample, rdf:_n, "a"]
>         [http://badExample, rdf:_3, "b"]
> 
> where n is some integer greater than 0."
> 
> Since the order of attributes is indeterminate, it's not 
> certain as to which
> attribute would be processed first as you clearly pointed 
> out. This makes it
> legal for two different RDF parsers to produce two different 
> models from the
> same input. One parser might encounter the li attribute first 
> in which case,
> n would be 1. Another might encounter the _3 first in which 
> case, according
> to your rules, n would be 4. This is especially dangerous if 
> the container
> is a Seq. For the sake of interoperability, I feel that we 
> should try our
> best to avoid this.
> 
> As Dave Beckett points out in his RDF Concepts Reference [1], 
> rdf:li is
> referred to in Section 3.2 of the M&S as a "convenience element" not a
> "convenience property" or some other such term that might be 
> interpreted as
> applying to both elements and attributes.
> 
> Jason.
> 
> [1]
> http://www.redland.opensource.ac.uk/notes/concepts.html
>

Received on Monday, 18 December 2000 07:54:24 UTC