Re: Proposing new terms for g-snap and g-text

On Wed, 2011-07-06 at 16:26 +0100, Richard Cyganiak wrote:
> I took ACTION-64 in the joint RDF+SPARQL call to propose new terms for g-snap and g-text. I'm doing so in this message. (Opinion on g-box was that it needs more clarification or crisper definition before we can talk about a replacement term.)

Sorry I couldn't make it.   Was there any specific aspect of "g-box"
identified that needed to be clarified?   Where there any questions
people had about the characteristics of g-boxes about which there were
disagreements?

> Best,
> Richard
> 
> 
> 
> g-snap: Let's call it RDF Graph.
> 
> “RDF graph” is a technical term with a precise definition that matches the meaning we want for g-snap.
> 
> Some people use RDF Graph when they really mean g-box, but that clearly contradicts what's actually in the spec and doesn't seem to be *too* common.

Don't most libraries that implement RDF use the term "RDF Graph" for
g-box instead of g-snap?

I guess the key question here is whether we can, or should, get folks to
start using the term gbox (or whatever) in their code and books, instead
of graph.    I'm not sure...   Programmers are used to some handwaving
on things like this, as with mutable "Set" structures.

> 
> 
> g-text: Let's avoid this concept.
> 
> Back in the days when RDF/XML was the only game in town, the “g-text” concept made sense. But today it is difficult to maintain because what is a “g-text” to some, might just be a “text” to others; and the specific triples that you get from a given “g-text” depend on who does the parsing. Consider an HTML document. Is it a g-text? After all, it can serialize an RDF graph using RDFa markup. Or, these days, using Microdata markup. Or using eRDF or RDF/XML in comments or a number of other archaic schemes for shipping triples in HTML. Or using one of the quasi-canonical microformat-to-RDF mappings. Do you consider a document with media type application/rss+xml a g-text? What about application/powder+xml? What about text/plain, it could be N-Triples or not?

But you can't even ASK those fascinating questions without a term like
g-text.

> So my advise is to avoid this term as much as possible.
> 
> There are some useful related concepts which in my opinion should be used in preference over the g-text concept:
> 
> “Serialization of an RDF graph [in RDF syntax XYZ]”

It looks to me like you're just proposing using "Serialization of an RDF
Graph" as the replacement for "g-text", which I think is a reasonable
proposal.

The qualification in square brackets applies to g-text as well, it seems
to me.

> “Representation of a resource [in RDF syntax XYZ]”

I wish we could somehow get the TAG to use the word "Serialization"
instead of "Representation".  :-(

(The Provenance WG is amusing in their dislike of the word "resource".
In the left column of this picture....

http://lists.w3.org/Archives/Public/public-prov-wg/2011Jul/att-0035/prov-f2f1-whiteboard.jpg

you can see the words we were discussing for this concept, which was
called "stuff" until this week's F2F.  I wrote "resource" there, and
made the case that it's what RDF and the Web Community use for this
idea, but was shouted down so strongly by all 18 people in the room, it
nearly scorched a hole in the whiteboard.)

> These differ slightly from g-text because they are defined in relation to another entity (the graph and the resource, respectively). If used in the right context, these terms are accurate, well-defined and unambiguous.

I see only the subtlest of differences between:
 
        "<a> <b> <c>" is a turtle serialization of an RDF Graph with one
        triple.
        
and

        "<a> <b> <c>" is a turtle g-text, serializing an RDF Graph with
        one triple.
        
In any case, I think the term g-text is now understood, and if somehow
"serialization" doesn't fill the void, we can revive it in discussion.
I think in the specs, "serialization" is fine.

      -- Sandro

Received on Friday, 8 July 2011 12:34:48 UTC