W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > July 2002

Re: editorial guideline: representing triples

From: Frank Manola <fmanola@mitre.org>
Date: Wed, 10 Jul 2002 13:28:58 -0400
Message-ID: <3D2C6EDA.56CB88E9@mitre.org>
To: Brian McBride <bwm@hplb.hpl.hp.com>
CC: RDF Core <w3c-rdfcore-wg@w3.org>

Some questions/comments about this:

1.  Are we going to vote on this, or should I just go ahead and make the
change (I don't object, I just want to know whether to do it now, or
wait for a vote)?

2.  What are the "standard prefixes" you want in there?

3.  I'm not sure it makes sense to talk about "legal n-triples"
(presumably referencing a definition of what those are) and then say
we're using them but with a whole bunch of differences in the syntax
(I'm assuming people reading the Primer haven't encountered n-triples,
or any other kind of triples, yet).  I'd propose to say something like
that we can record RDF statements by simply writing down the triples of
the subject, predicate, and object URIs (or literals, in the case of
objects);  this produces long triples, and for the rest of the document
we'll simplify those triples by introducing the qname abbreviation.

4.  If you don't use angle brackets, you can't handle "this document"
references (<>) and fragments (<#pat>) the way TBL does in his N3 Primer
(assuming we wanted to do that).   


Brian McBride wrote:
> It has been suggested that we adopt a common notation across all the specs
> for representing triples.
> I suggest we use legal n-triples with the addition that a URI can be
> represented as a qname without angle brackets, e.g.
>    _:a rdf:type rdfs:Class .
> The notation should be explained in the primer which should include a list
> of standard prefixes.  The other documents should reference the description
> in the primer.
> Brian

Frank Manola                   The MITRE Corporation
202 Burlington Road, MS A345   Bedford, MA 01730-1420
mailto:fmanola@mitre.org       voice: 781-271-8147   FAX: 781-271-8752
Received on Wednesday, 10 July 2002 13:29:09 UTC

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