Re: Comments on RDF Spaces document

Hi Ivan,

On 26 May 2012, at 16:19, Ivan Herman wrote:
>> I strongly disagree with defining “space” based on the nature or characteristics of the thing identified. Strongly disagree with the whole “container” metaphor. The definitions mean that if I produce some triples by running some NLP on web pages, I'm not allowed to stick that into a SPARQL store using the web page URL as graph name. This is not acceptable to me.
> 
> I am not sure that your last objection is actually fair.

My objection is fair.

> The text discloses NLP, but only because extraction with NLP is too vague (the results would depend on the NLP engine).

Of course the results would depend on the NLP engine, but nevertheless they are a true representation of the meaning that is conveyed by the web page.

> I believe, taking a different example, that the current "space" notion would allow an HTML5+microdata page being a space (ie, its URI being the identifier of the space), because there is a well defined algorithm that produces RDF triples.

That is true but besides the point. The point is that Sandro's text, as I understand it, forbids the use of RDF datasets with NLP, and, as far as I can tell, forbids the use of any non-W3C-recommended method of turning some contents into triples.

> To come back to your text, if the URI of the text made it clear that that the NLP extraction is based on, say, Zemanta's tagging engine then, for me, that would be a perfectly o.k. name for a space.

It is explicitly an example that is *not* an o.k. graph name in Sandro's definition.

> In other words: apart from a terminological mismatch, I do not think that the differences are so utterly huge as you seem to say.

My point is that any definition that explicitly outlaws any currently conforming use of RDF Datasets in SPARQL is not acceptable.

> One the other hand: shouldn't we, somewhere in our documents (remember that I look at this document as a 'gathering place') define quads? After all, they *are* widely used, and some sort of a relationships to named graphs should be defined somewhere.

I don't see why. The only spec that has any reason to mention quads is N-Quads. (Well, JSON-LD may too but it uses a definition that's different from Sandro's.) Other uses of quads are implementation strategies and those don't belong into the specs.

For example we don't mention prefix maps either, despite the fact that every RDF implementation has something like that in the codebase.

>>> 3.6 Graph Store
>> 
>> Not entirely convinced that we need both the “snapshot” and “mutable” versions of the abstract syntax. Why do you think we do?
> 
> Hm. My reading of this section is how the rest relates to what SPARQL 1.1 defines (not being 100% up-to-date with that part of SPARQL 1.1, I cannot judge whether what is in this section is correct or not).

Sure, this section simply copies what's in SPARQL Update, and is consistent with SPARQL Update, but if graph stores are purely a SPARQL Update thing, then I don't see why we need to talk about it. SPARQL Update already explains the relationship between graph stores and RDF datasets.

The way I see it: As a rule of thumb, once a concept is used not just in one spec but across a larger number of Semantic Web specs, then it is a candidate for being moved into the core specs. I am not sure whether that's the case for the “graph store” concept. Maybe it is the case, but I'd like to see someone making the case.

Best,
Richard

Received on Monday, 28 May 2012 08:59:29 UTC