Re: Dataset Syntax - checking for consensus

On Sep 25, 2012, at 9:28 PM, Sandro Hawke wrote:

> On 09/25/2012 10:08 PM, Pat Hayes wrote:
>> On Sep 25, 2012, at 6:14 PM, Sandro Hawke wrote:
>> 
>>> I'm not sure how much progress we'll be able to make on dataset semantics tomorrow, so I thought I'd draft some proposals on dataset syntax.   The chairs can put this on the agenda is they like (but it's too short notice for these decisions to be binding yet).  I'm thinking it would be useful to see how close we are to agreement on these issues.
>>> 
>>> If you followup with votes, please use -1 for Formal Objection, 0 for abstain, +1 for approve.   Numbers in between are fine, too.
>>> 
>>> PROPOSED: We will produce a W3C Recommendation for a dataset syntax, similar to TriG and to SPARQL's named graph syntax.
>> +1 Although I don't see why we need to add yet a third, why not just follow SPARQL?
>> 
>>> PROPOSED: We'll request a media-type for this syntax which is different from the media-type for Turtle.  (That is, we will not consider this language to supplant Turtle and take over the name, becoming the new "Turtle", as was once proposed.)
>> 0
>> 
>>> PROPOSED: Our dataset syntax will allow for the expression of empty named graphs, whatever their semantics might be (to be decided). The syntax is an empty curly-braces expression, as in "<g> { }".
>> +1. However, note that there is only one empty graph: it is unique.
>> 
>>> PROPOSED: Our dataset syntax will have some standard mechanism (to be determined within the next few weeks) through which a Dataset serialization can include some RDF data about the Dataset (that is, some metadata in the form of an RDF graph).
>> +1, but note that AFAIKS this requires semantics which will be incompatible with some current use cases.
> 
> Explain?

OK, I will try again. 

People want to "label" a graph with a URI they are using to denote something else, eg a person. The same URI cannot denote two things at once. So the current proposal for a minimal semantics distinguishes the thing denoted from the graph "named", by having a GR-EXT function from things to graphs. But this means that when the URI is used in RDF, it denotes the something else, not the graph. So you don't get to use it in RDF metadata to refer to the graph. We could throw this semantics away, and say that the name really does denote the graph it "names", which has always made sense to me (and, apparently, to Peter, who is arguing the case right now), but then it can't also denote this other thing that people want it to denote, or perhaps better, want to have the freedom to make it denote. 

I can't help observing that this very basic point about URIs and naming has been bloody obvious since day one, and yet apparently this WG is STILL, after over a year, unable to gets its collective head around it. 

Pat

> 
>>> 
>>> Below, there are groups of proposals which are alternative solutions to a design issue.   If you approve of more than one of the alternatives, please vote "+2" for your favorite.
>>> 
>>> * Name of the dataset syntax
>>> 
>>> PROPOSED: We will call our recommended dataset syntax "trig", capitalized to Trig as needed.
>>> PROPOSED: We will call our recommended dataset syntax "TriG", but informally and in the media type, "trig".
>>> PROPOSED: We will call our recommended dataset syntax "TriG", and use that capitalization everywhere.
>> 0
>> 
>>> * Use of equals sign, like <g> = { <s> <p> <o> } .  This is not in SPARQL but is in traditional TriG, for compatibility with N3.
>>> 
>>> PROPOSED: In our dataset syntax, a "=" MAY appear between the name and the graph.
>>> PROPOSED: In our dataset syntax, a "=" MUST appear between the name and the graph.
>>> PROPOSED: In our dataset syntax, a "=" MUST NOT appear between the name and the graph.
>> 0
>> 
>>> * Use of the "graph" keyword, which MUST be used in SPARQL and MUST NOT be used in traditional TriG.
>>> 
>>> PROPOSED: In our dataset syntax, the case-insensitive keyword "graph" MAY appear before the name, in a name-graph pair.
>>> PROPOSED: In our dataset syntax, the case-insensitive keyword "graph" MUST appear before the name, in a name-graph pair.
>>> PROPOSED: In our dataset syntax, the case-insensitive keyword "graph" MUST NOT appear before the name, in a name-graph pair.
>> 0
>> 
>>> * Use of curly braces { <a> <b> <c> } around the default graphs.   They MUST be used in traditional TriG, and MUST NOT be used in SPARQL.
>>> 
>>> PROPOSED: In our dataset syntax, triples of the dataset's default graph MAY be surrounded by curly braces.
>>> PROPOSED: In our dataset syntax, triples of the dataset's default graph MUST be surrounded by curly braces.
>>> PROPOSED: In our dataset syntax, triples of the dataset's default graph MUST NOT be surrounded by curly braces.
>> 0
>> 
>>> * Some designs for carrying for metadata
>> I don't like any of these. Seems to me that metadata is just data that refers to graphs, and it doesn't need to be segregated in any particular place.
>> 
>>> PROPOSED: In our dataset syntax, we'll say that metadata goes in the default graph
>>> PROPOSED: In our dataset syntax, we'll say that the default graph goes inside curly braces and the metadata goes outside curly braces
>>> PROPOSED: In our dataset syntax, we'll say that metadata goes inside a set curly braces after a keyword "meta".
>>> PROPOSED: In out dataset syntax, we'll have a keyword "meta" followed by "default" or the name of a named graph, to indicate to readers where the metadata is.
>> And this seems to rather beg a question: have we decided that there *must* be metadata?
> 
> Sorry, I should have marked this one as dependent on the 4th one above (which you said +1 to).     (And I should have numbered them all!)
> 
>       -- Sandro
>> 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
>> 
>> 
>> 
>> 
>> 
>> 
> 
> 
> 

------------------------------------------------------------
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 Wednesday, 26 September 2012 05:22:13 UTC