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

On Jul 8, 2011, at 7:34 AM, Sandro Hawke wrote:

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

The issue I have is that SPARQL has defined this more elaborate idea of an RDF Store. Now, I believe that a g-box can be characterized as a very simple Store, to wit one without any named graphs and without any name. But this is such a restricted idea that I think it will just cause confusion, particularly as one could make out a case that the graphs in a Store are best thought of as g-boxes themselves, in fact. If we are not careful we will descend into angels-on-pinheads debates about whether a box has another box inside it. So to avoid this kind of nattering before it starts, I suggested we have an idea of *anything* which is (1) potentially mutable, ie has a state, and (2) emits graph representations/serializations when suitably prodded, and have a very generic terminology for any such thing, however complicated. Call it (?) a "graph resource". [*] Then a g-box is the simplest kind of graph resource, which just emits one graph when prodded, regardless of the nature of the prod. A SPARQL RDF store is a much more complicated kind of graph resource, but they are both graph resources. 

[*] Ah, I see (another message) you don't like the "resource" terminology. Well, neither do I, but I had the impression that it was set in stone.  But in any case, this usage actually returns "resource" to something more like what its originator (Doug Engelbart) had in mind.

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

I think it is very common, and we even do it in the WG from time to time. 

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

Indeed, and we can say that people do this, but that if you conflate 'graph' and 'graph resource' then you really need to understand that you are being ambiguous between the resource and an instantaneous state of that resource, and this can give rise to misunderstanding, etc.. People will still do it, but then its THEIR fault.

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

+1

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

:-)  I did try to do this to Dan Connolly in 2001, but I wasn't loud enough. 

Pat


------------------------------------------------------------
IHMC                                     (850)434 8903 or (650)494 3973   
40 South Alcaniz St.           (850)202 4416   office
Pensacola                            (850)202 4440   fax
FL 32502                              (850)291 0667   mobile
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes

Received on Tuesday, 12 July 2011 22:19:36 UTC