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

On 06/07/11 16:26, 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.)
>
> 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.

+1

(an RDF graph is a set of triples - a value)

> Some people use RDF Graph when they really mean g-box, but that
> clearly contradicts what's actually in the spec

yes - but partly because the RDF spec doesn't cover change at all so 
g-box/g-snap punning works.

> and doesn't seem to
> be *too* common.

I think it's common.  People talk about "querying a graph at <URL>" and 
URL is a g-box.

We just been to be precise in the formal parts of the specs but 
acknowledge language will be used elsewhere that is not technically 
perfect.  This isn't something that's unique to RDF or the semantic web.

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

Sandro defined g-text as:

[[
A "g-text" is a particular sequence of characters or bytes which
conveys a particular g-snap in some language (eg turtle or rdf/xml).
]]
which works for RDFa etc reading it as not ruling other bytes about 
something else as well.

Anything where there is one graph so not TriG.

In fact, if we don't have something for g-text, I think it might default 
to "[RDF] document". "serialization" is OK but it is bulky.

“Representation of a resource [in RDF syntax XYZ]” feels like it begs 
the question again even if technically correct.  I have also seen "a 
graph represents ..." using representation at a different level.

 Andy

Received on Tuesday, 12 July 2011 20:09:46 UTC