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

Re: ACTION 2001-10-12#5: frankm respond to gk text

From: Sergey Melnik <melnik@db.stanford.edu>
Date: Mon, 15 Oct 2001 16:39:34 -0700
Message-ID: <3BCB73B6.727DBDE4@db.stanford.edu>
To: Pat Hayes <phayes@ai.uwf.edu>
CC: Frank Manola <fmanola@mitre.org>, w3c-rdfcore-wg@w3.org
Pat Hayes wrote:
> [...]
> > Frank Manola wrote:
> > [...]
> >[2.] If so, should they be clearly distinguishable as parser generated URI's?
> >  -- Stricly speaking, the parser is not required to generate URIs.
> >The parser *is* required to generate local names (that are not URIs)
> >for anonymous resources. These names *are* distinguishable from URIs.
> What exactly is 'the parser' here? (Parser of what?) If the parser is
> parsing an Ntriples document, then the bNode ids are in the document
> already and nothing needs to be generated.

Not quite... If an Ntriple document contains bNode _x the parser must
generate different internal ids for _x each time the document is parsed,

> If the parser is dealing
> directly with the graph syntax, then there is no need for the bNode
> labels at all, and nothing needs to be generated. If the parser is
> reading RDF/XML and constructing a graph, no new names need to be
> generated.

Again, some sort of internal ids (objects, or other data structures)
still need to be generated...

> The only case that requires generating any new names is
> when something is reading either a graph or RDF/XML, and *generating*
> an N-triples document. In that case, and that case alone, it needs to
> generate some bNode names (since the Ntriples syntax requires them
> and they aren't present in any other version of RDF.)  But that is an
> issue with Ntriples, not (centrally) with RDF itself, and I think we
> should keep those issues separate. Our remit, after all, is to
> clarify RDF;  N-triples is only a handy notation we have invented for
> describing RDF graphs, right? The graph is central.
> Pat Hayes

Received on Monday, 15 October 2001 19:13:40 UTC

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