Re: PRIMER: new draft data model section

Comments below:

Patrick.Stickler@nokia.com wrote:
> 
> > -----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'll see what it might look like.


> 
> 
> > >
> > > 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.

Actually, Ntriples is a simplification of N3, which was introduced as
making it easier to *write* graphs, and it is.  I'd prefer to see
Ntriples made more official, if that's necessary.  

> 
> >
> > >
> > > 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
> in RDF/XML.
> 

I'm not sure I understand what your concern is (and there are a couple
of things going on here), so perhaps we could consider an example.  Take
Figure 14 in the M&S.  There's a blank node that represents the value of
the "subject" predicate.  The RDF/XML (just below the figure) has no
"rdf:about" or "rdf:ID" that creates that node;  rather, the RDF/XML
syntax permits you to elide the explicit specification of nodes (with
accompanying identifiers) that, in fact, have to be there in the RDF
graph.  Now, does the blank node itself "have no real representation in
RDF/XML"?  Of course, a nodeID per se has no *explicit* representation
in RDF/XML (the whole point of eliding the specification of nodes is to
avoid having to create those identifiers), but it certainly stands for
the existence of a blank node in the Ntriples representation of the
graph.  The next example (Figure 15) illustrates another blank node, but
slightly different RDF/XML (here, the blank node has a
rdf:parseType="Resource" attribute, but still no ID or about).  What do
you think the problem is?

--Frank

-- 
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 Tuesday, 13 November 2001 11:31:12 UTC