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

Hi Andy,

On 12 Jul 2011, at 21:09, Andy Seaborne wrote:
> People talk about "querying a graph at <URL>" and URL is a g-box.

Well, no. A URL *names* a g-box. And the graph that is “at” <URL> today might well be a different one from the graph “at” this <URL> yesterday. So this particular usage isn't even inconsistent with understanding RDF Graph as g-snap.

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

Ok, right.

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

In this reading, any HTML5 document would be a g-text, because one can extract at least a dc:title triple from *every* HTML5 document using the microdata-to-RDF mapping in the spec. I think that's a weird way of looking at things. If one has the right kind of parser, *any* sequence of characters can convey a g-snap.

> Anything where there is one graph so not TriG.

Right

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

There are many kinds of “texts” that one can parse to RDF, but that certainly are not RDF documents. Images and PDFs containing XMP metadata. HTML5 documents containing a single dc:title triple. SVGs with embedded RDFa metadata.

A book is not a “metadata record” just because there's metadata written on it. In the same way, a text is not an “RDF document” or “graph serialization” or “g-text” just because one can parse a few triples from it.

In my eyes, thinking of texts as merely conveying a particular RDF graph is in the best case forgetting about several major RDF deployment scenarios, and in the worst case committing a category error.

Hence my rejection of the g-text concept.

The multigraph support this group is supposed to standardize may be about multiple g-boxes or about multiple g-snaps. It's certainly not about multiple g-texts.

It is good that we talked about g-texts in order to clarify that they are *not* what we are interested in. I don't see any point in further discussing what they ought to be called.

Best,
Richard

Received on Wednesday, 13 July 2011 15:33:24 UTC