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

RE: PRIMER: new draft data model section

From: <Patrick.Stickler@nokia.com>
Date: Tue, 13 Nov 2001 15:52:30 +0200
Message-ID: <2BF0AD29BC31FE46B788773211440431621773@trebe003.NOE.Nokia.com>
To: fmanola@mitre.org
Cc: w3c-rdfcore-wg@w3.org

> -----Original Message-----
> From: ext Frank Manola [mailto:fmanola@mitre.org]
> Sent: 13 November, 2001 15:45
> To: Stickler Patrick (NRC/Tampere)
> Cc: w3c-rdfcore-wg@w3.org
> Subject: Re: PRIMER: new draft data model section
> Patrick--
> Thanks for the comments.  Responses below.
> Patrick.Stickler@nokia.com wrote:
> > Frank,
> > 
> > I thought the draft on the data model section was
> > very well written, and I'm happy to see the clear
> > discussion about URLs vs. URIs (though you go on
> > to use HTTP URLs for abstract concepts anyway ;-)
> Yeah, well I didn't want to introduce (and have to explain) a new URI 
> scheme.  However, I can do that if you think it would make the 
> distinction clearer.

Actually, no. I think the recent "clarification" doesn't
clarify much, and in fact I prefer your present treatment. 

I just thought you might toss in a few tag URIs or similar
to show a little more heterogeny.

> > 
> > I am concerned though that the example serializations
> > are in NTriples and not RDF/XML. Have we decided to
> > make NTriples an "officially sanctioned and required"
> > serialization? Will all RDF parsers have to eat
> > NTriples to be fully conformant to the spec?
> My current understanding is that Ntriples was defined only as a 
> simplified notation to express test cases (it's only defined 
> in the Text 
> Case document);  however, there may be an expanded role for 
> it now.  I 
> use it in the Primer because it's a straightforward linearization of 
> the graph structure, which is the *model* I'm trying to 
> convey.  RDF/XML 
> is (so far) the official *syntax* (as in "Model and Syntax") for 
> serializing these models, but if I used it to explain the model, then 
> folks would have to understand that syntax in order to understand the 
> model, and I'd like to keep them separate if possible.  Also, 
> there are 
> all sorts of abbreviations and "irregularities" in the syntax 
> that I'd 
> like to avoid talking about.  

Trust me, I understand ;-)

> It might, however, be worthwhile saying 
> something more (briefly) about the relationship of Ntriples to the 
> RDF/XML syntax.

Well, not to be too pedantic about it, but, if this is going to
be an official WG publication (as opposed to a non-W3C publication)
then I think that all examples should be in RDF/XML and NTriples
shouldn't be used at all.

If you want to reflect graph structure, you should draw the graph.

> > 
> > Also, what is the relation between nodeIDs in NTriples
> > to some representation in RDF/XML. We can't use rdf:ID,
> > since that maps to a URI in the presence of an xml:base
> > definition.
> > 
> > How does one achieve the same instance-specific-only
> > nodeID representations in RDF/XML?
> > 
> NodeIds (or whatever the official name for them is now) were 
> invented in 
> order to be able to express, in Ntriples, the blank nodes (formerly 
> called "anonymous resources") that appear in places like 
> Figure 2 of the 
> M&S.  You'll find other blank nodes, for example, in Figures 
> 4, 14, and 
> 15.  The RDF/XML that expresses the RDF in those figures 
> would need to 
> produce nodeIDs if translated to Ntriples.  So it's not that 
> we now need 
> to provide a way to express nodeIDs in the RDF/XML, it's the 
> other way 
> around:  we created the concept of nodeIDs in order to express in 
> Ntriples what we *already* could express in RDF/XML.

Well, I don't think its as simple as that. The nodeIDs in 
NTriples do not have representation in the graph itself. The
rdf:ID's or rdf:about's that must be used in RDF/XML to 
accomplish the same thing *do* end up with representation
in the graph.

Thus, in the strict sense, nodeIDs have no real representation

Received on Tuesday, 13 November 2001 08:52:47 UTC

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