Re: Role of N-Triples (was Re: datatyping revised draft)

I didn't intend for this to become such a big issue, and don't
intend to proactively perpetuate the thread after this posting,
aside from responding to direct questions and the like.

Also, I wasn't meaning to single out the Primer, which I personally
think is shaping up beautifully (and really has very little NTriples
in it)

That said...


On 2002-06-03 17:34, "ext Frank Manola" <fmanola@mitre.org> wrote:

> Patrick Stickler wrote:
> 
>> 
> 
> snip
> 
>> 
>> A good rule of thumb would be: is the example trying to capture some
>> feature specific to the graph syntax -- or is it simply expressing
>> RDF statements. If the former, then go ahead and use NTriples, but
>> if the latter, then let's stick to RDF/XML.
> 
> 
> It seems to me that your rule of thumb is slightly backwards.  The graph
> isn't "syntax", it's the basic model (that is, the abstract concept of
> the graph is the basic model, not the specific N-Triples or drawing
> expressions of it).

I was referring to the graph syntax. Nodes and arcs. Not the RDF/XML syntax.

> And "RDF statements" are components of the graph
> (in fact, the M&S defines a statement as a triple).  The graph isn't a
> "realization" of a set of statements;  it *is* a set of statements.

Right.

> RDF/XML happens to be an XML-based serialization of the graph, but it is
> not true that RDF/XML expresses statements and the graph does not.

Never meant to say so. I was thinking in terms of content creators
making statements in RDF.

Yes, they can make them in NTriples, but that IMO undermines the
point of having a standardized encoding to express RDF statements,
namely RDF/XML.

> I 
> think the issue is what are you attempting to talk about when you
> present a statement.  Are you attempting to talk about some basic aspect
> of the statement, in an abstract (model) sense, or are you trying to
> talk about some aspect of the XML serialization of the statement (or
> something which could equally well be illustrated by the XML
> serialization).

I'm simply talking about whether content creators are going to
be encouraged by the specs to express their RDF statements in
RDF/XML versus NTriples.

Yes, *some* RDF users need to *understand* NTriples, as a tool for
concisely reflecting the graph. But RDF users need never *write*
NTriples, ever -- and most RDF users need never understand, use,
or see NTriples. They should express their RDF statements in
RDF/XML. And they should only ever interchange their RDF in RDF/XML.

RDF parsers are neither required to import or export NTriples,
and until they do, it should be clearly stated and understood
that NTriples is not a serialization for the authoring or
interchange of RDF.

>> Let's not "be lazy" and use NTriples just because it's easier to
>> type. Unless it's clearly showing graph structure, let's not. Eh?
> 
> 
> I don't think most of us are "being lazy" when we write N-triples;
> we're trying to express what we need to express in what we think is the
> clearest way possible, using the abstract graph model, of which
> N-triples seems to be the most direct representation.

Personally, I find the node and arc graphs to be far clearer, as I
expect most users will -- hence the recent graphical authoring tools,
and heavy use of graph generators rather than NTriples generators. NTriples
is just a machine readable version of those graphs which facilitates
automated validation of parser behavior. The test case results could
also have been expressed by a set of graphics reflecting the resultant
graph and have been just as informative and authoratative. Humans should be
provided with nodes and arcs graphics in the specs when the graph
must be represented explicitly (IMHO).

> The RDF/XML 
> syntax is confusing to many people, and hence not the clearest way to
> explain things.  Also, the XML serialization has many alternative ways
> to express the same RDF, and often we want people to be focusing on the
> basic RDF model, not on a particular serialization.  I think we are, in
> fact, acting on principle when we use N-Triples, but the principle is to
> try to explain the more complicated (RDF/XML) in terms of the simpler
> and more fundamental (N-Triples), rather than the other way around.
> This may be an unfortunate situation, but I think it's an accurate
> reflection of the facts.

I understand the motivations for wanting to use NTriples. It boils down
to a matter of principle, really.

For better or worse, there is only *one* official, standard interchange
serialization for RDF statements, and that is RDF/XML, and the
specs should strongly and clearly reflect that. Even though NTriples
are defined and used by a normative spec, their role is explicitly
for reflecting the behavior of a parser, not for the general
expression and interchange of RDF encoded knowledge. It is very
important not to loose sight of that.

The graphical node and arcs representation is more than sufficient
to clarify to the users what the RDF/XML represents, and while the
node and arcs representation is not explicitly christened as
official, it is not in a machine readable form, and thus the confusion
between it and RDF/XML is not an issue. Confusion between RDF/XML
and NTriples, however, is a very likely possibility.

Also, if an example can be shown in RDF/XML versus NTriples, it
helps the user more to see the RDF/XML in order to understand
how the XML relates to the graph. The side-by-side XML+graphic
format used for the examples in the Datatyping spec serves to
provide and reinforce understanding of the relationship between
the RDF/XML serialization and the resultant graph. There is no
need for NTriples in such examples and use of NTriples would
not help users understand how they actually *have* to express
RDF in XML as *required* by the standard.

And let's look at the usage of NTriples in the Primer. They occur
only in sections 2.3 - 2.4 in only 6 examples, yet the content
intended to be reflected could just as easily (and surely just as
effectively) be represented with node and arc diagrams. There
simply is no need for most users to have to understand NTriples
in order to understand the normative parts of the RDF specifications.

And that's my point. Users should not have to learn and understand
NTriples in order to understand and use RDF. It is not necessary,
and thus, the Primer and the other RDF documents, other than the
test cases document, should not require it.

NTriples could simply be left in the test cases document where
they are primarily relevant, and only those folks mucking with
parser internals and behavior need ever have to learn NTriples
syntax -- in order to understand the specs.

Let me stress here I'm not saying that the RDF community does
not benefit from using N3 or NTriples in email discussions, etc.
but that insofar as we are defining a standard, we should not
impose unnecessary requirements on readers for them to understand
the core normative content. The only document that should
*require* understanding of NTriples is the test cases document.
That's all. The rest should be free of NTriples.

> PS:  I wouldn't mind at all seeing N-Triples passing about the Web.

I would. A system that interchanges NTriples is a non-conformant system
and undermines the very purpose of having a standardized representation
for knowledge intended to facilitate global interchange. Hell, why
not then just interchange any old serialization syntax which purports
to express RDF statements?! N3, Prolog, KIF, COBOL, whatever....

If the WG feels strongly that NTriples should be applicable *anywhere*
that RDF/XML is, then let us make NTriples an official alternate
*interchange* serialization of RDF.

But unless and until that happens, I remain, for the record, opposed
to its use in the normative sections of the spec and where RDF/XML
or nodes and arcs diagrams would serve in all examples, normative or
not.

And again, in case it was missed when I said it earlier, I'm not
against NTriples. I think NTriples are great, and essential for
automating the validation of parser behavior. But their scope of
usage reflected in the specs is too broad.

Patrick

--
               
Patrick Stickler              Phone: +358 50 483 9453
Senior Research Scientist     Fax:   +358 7180 35409
Nokia Research Center         Email: patrick.stickler@nokia.com

Received on Tuesday, 4 June 2002 02:10:40 UTC