Re: [All] Proposal: RDF Graph Identification

Hi Pat,

Thanks for the useful feedback.  I can fold in the changes where we agree, hopefully by tomorrow midday.  I've also asked some questions back to you below.

On Aug 16, 2012, at 13:45, Pat Hayes <phayes@ihmc.us> wrote:

> I was lucky enough to get an earlier view of this document, but I still have some comments upon it and some questions about it.  Some of these only occurred to me recently, so I apologize for nor raising them earlier. 
> 
> 
> 1. The use of 'contains' in the figure is potentially misleading, as it can be read as suggesting the container/state relationship. Might be better to use "has component" instead. 

+1

> 
> 2. "The state of an RDF Space at any time is an RDF Graph."  Could the state of a container comprise other things as well as the actual graph? For example suppose there is metadata in the state which could be changed without changing the graph. Or, is the intention that this is not part of a 'space', so that a 'space' has an RDF graph state and nothing else? (I suggest not, eg consider the case where my space just happens to be a mirror of your space, but they are neverthless distinct spaces.)

I agree.  The way I see it is that the sentence is correct; there is no other state.  Of course, the name of space (the name associated with a slot, in SPARQL terms) is not included in the space itself, and so is not applicable here.

> 
> 3. "each query is performed against the information in a specific dataset" // "each query is performed against a specific dataset"  

Sure, that's better.

> 
> 4. "Note that “named graph” is a relation, not a class: we say that something is a named graph of a dataset, not simply that it is a named graph."  What does this mean? Is it intended to convey the idea that the naming is local to the dataset? If not, what is it supposed to convey? Put another way, what is wrong with saying that something just is a named graph? 


The idea is to limit the term "named graph" to a specific defined way that the SPARQL specs use it.  The term "named graph" has been used, and misused, so many ways… any (correct) disambiguation seems useful to me.

Please suggest other wording if you can think of something better.

> 
> 5. "The interpretation of an RDF dataset is the interpretation of its default graph. The presence or absence of named graphs does not affect the truth of a dataset."  That is, so-called quoting semantics. There is a real problem here. If a named graph in a dataset is not asserted by the dataset, then why would SPARQL return any query results from that graph? The basic SPARQL rule is that results are returned when the graph you get by instantiating the query pattern *is entailed by* the dataset. But if named graphs are not asserted in the dataset, they don't entail anything. So acording to this semantics, the only query results that are legal are those which are directed to the default graph. 


> 
> 6. I do not understand what this refers to: "This quoting behavior is considered to be important; it avoids the “superman” effects that plagued RDF reification."

Ivan?

/me refuses to be drawn on http-range-14 or reification ever again :)

> 
> 7. The first three conditions listed under semantics are actually syntactic conditions and should be listed as such, as part of the definition of a dataset. The only genuinely semantic conditions are that I satisfy the default graph and I(ui)=Gi for 1<=i<=n .

I believe you are talking about the first three enumerated items in the math section under section 3.2.  Is that so?  If so, I can make that change.


> 
> 8. (An observation) this semantics means that asserting a dataset makes the graph names into genuine referring global names for the graphs. THis means that the name URIs cannot be consistently used to refer to, for example, time-periods, contexts, provenance sources, etc.. . I am cool with this, but I want the WG to be sure that they know what they are getting. 
> 
> Test case: 
> 
> :A owl:disjoint rdf:Graph
> { :u {:a :b :c}}
> :u rdf:type :A
> 
> is inconsistent.

That is correct to my understanding.  I do note that implementations would be able to (and likely to) address such use cases out of band, e.g. by providing last modified dates upon HTTP HEAD for resolvable identifiers.

> 
> 9. Another obervation: this semantics makes no provision for the meaning of a graph to be dependent upon the 'name' of the graph, so that this does not support such usages as treating named graphs as 'snapshots' of a changing world, or as graphs considered in some kind of "context". As such usages have been widely reported and explicitly mentioned in blogs about good RDF usage, we need to be ready for some pushback at this point. 
> 
> (9a. I have to observe that if we were to adopt some form of context mechanism, this might alleviate the preoblem/pressure mentioned in 9. Although this is not directly about named graphs, it impinges upon it, as the issue seems to be that named graphs have been used to represent contextual assertions (because people need contextual assertions, this is an easy way to do it and the more kosher ways are all very awkward.) So if we give this to them in some other easy way, much of the conflicting pressure on named graphs might be removed.)

Yes.  We at one time had hopes to address more advanced use cases.  This proposal is intended to help define a (nearly) minimally acceptable solution.  I'd be happy if we could get farther, but let's try to get to the basics first.  If we can continue past the baseline once we have reached the baseline, then we should try.  Does that make sense to you?  I do *not* want this WG to fail in relation to its charter.

Regards,
Dave



> 
> Pat
> 
> 
> On Aug 16, 2012, at 8:17 AM, David Wood wrote:
> 
>> Hi all,
>> 
>> The chairs and team contacts for the RDF WG have been working to create a proposal to break the deadlock regarding the "named graphs" portion of our charter.  We call our proposal "RDF Graph Identification" [1].
>> 
>> This proposal has some major differences from previous proposals, but borrows tremendously from many of them.  It is an attempt to find a middle ground, close to minimal, but sufficient to formally define commonly implemented practices and encourage implemented use cases already found in the wild.
>> 
>> This document is *not* intended to be published, nor to have editors past the proposal stage (i.e. don't be confused by scaffolding provided by the use of ReSpec).  Instead, it is intended to be used as source material for changes to other documents (RDF Concepts, Semantics and various format specs).  Each section contains a note showing the intended distribution for that section's material.
>> 
>> Guus, Ivan, Sandro and I have consulted with Andy, Richard and Pat on some details.  Although all of our names appear on the document, that does not infer that everyone on that list agrees with everything there.  Indeed, everyone has something in the proposal that makes them uncomfortable.  We are, however, trying to come together to find a solution.
>> 
>> Many challenges remain before we can claim victory for the RDF WG.  Failing to address the "named graphs" requirement in our charter would not only be a major public embarrassment, but would significantly damage the Semantic Web Activity's perception in both the public eye and within the W3C.  I therefore ask each of you to do the following:
>> 
>> - Please read the proposal carefully in its entirety
>> - Please take a breath :)
>> - Please react professionally and courteously (avoiding nitpicks, personal attacks, etc)
>> - Please suggest *concrete changes* to the document (instead of, e.g., simply denigrating existing content)
>> 
>> I look forward to working with all of you to find a path forward.  Thank you.
>> 
>> Regards,
>> Dave
>> 
>> [1] http://www.w3.org/2012/08/RDFNG.html
>> 
>> 
>> 
>> 
> 
> ------------------------------------------------------------
> 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 Thursday, 16 August 2012 20:57:04 UTC