W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > June 2001

Re: #rdf-containers-syntax-ambiguity, #rdf-containers-syntax-vs-schema

From: <jos.deroo.jd@belgium.agfa.com>
Date: Wed, 13 Jun 2001 18:06:57 +0100
To: bwm@hplb.hpl.hp.com
Cc: w3c-rdfcore-wg@w3.org
Message-Id: <OF6AAD6B0C.AD2C2821-ON41256A6A.005DF727@bayer-ag.com>

going back from the N-triples (in your samples)
to RDF1.X or N3 is I think unambiguous,
so I would proceed


Brian McBride <bwm@hplb.hpl.hp.com>@w3.org on 06/13/2001 04:37:49 PM

Sent by:  w3c-rdfcore-wg-request@w3.org

To:   rdf core <w3c-rdfcore-wg@w3.org>
Subject:  Re: #rdf-containers-syntax-ambiguity, #rdf-containers-syntax-vs-schema

Brian McBride wrote:
> With respect to action:
>   AP: 2001-06-08#3: Brian McBride: pick up on the syntax issues now the
>         model details have been clarified.
> from last weeks teleconference, I would like to propose the attached
> McBride/Beckett proposal for parsing containers.  This proposal was circulated
> on RDF Interest in December 2000

With respect to that proposal, I realised that it suffers from a similar problem
to the one that Dan Connolly pointed out in:


The proposal specifically allows for representing partial descriptions of
containers using the rdf:li syntax.  For example:


will generate (please excuse the abbreviation):

  _:genid <rdf:type> <rdf:Bag>.
  _:genid <rdf:_1>   "1" .
  _:genid <rdf:_10>  "10" .
  _:genid <rdf:_11>  "11" .

In essence, rdf:li translates to rdf:_nnn where nnn is one more than the last
rdf:_mmm encountered in the element.

Now consider property foo:ten which is a subproperty of rdf:_10.


What triples does the above example generate.  Either the parser has to process
subPropertyOf relations, or it will generate a different set of triples from the
first example.

An argument can be made that reseting the count in this way is an example
of feature creep and would be best avoided.  It provides more syntactic sugar
than the language described in M&S.  It adds little value, creates
more work for implementors and creates confusion, as in the case outlined above.

I think therefore there is a case to be made for simplifying this aspect of
the proposal so that rdf:li elements within a description are translated to
rdf:_nnn where nnn starts at 1 and is incremented by one for each rdf:li

This the example given above:


would generate:

  _:genid <rdf:type> <rdf:Bag>.
  _:genid <rdf:_1>   "1" .
  _:genid <rdf:_10>  "10" .
  _:genid <rdf:_11>  "2" .

This solution also neatly ducks the issue of what do to with:

  <rdf:Bag rdf:_1="1" rdf:_2="2">

I'd welcome feedback from the WG on which way they would like me to proceed
as I write up the test cases.

Received on Wednesday, 13 June 2001 12:09:16 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:24:01 UTC