Proposing new terms for g-snap and g-text

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

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.



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?

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]”

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

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.

Received on Wednesday, 6 July 2011 15:26:45 UTC