W3C home > Mailing lists > Public > public-rdf-wg@w3.org > September 2012

Re: Dataset Syntax - checking for consensus

From: David Wood <david@3roundstones.com>
Date: Wed, 26 Sep 2012 15:14:28 -0400
Cc: Antoine Zimmermann <antoine.zimmermann@emse.fr>, Sandro Hawke <sandro@w3.org>, W3C RDF WG <public-rdf-wg@w3.org>
Message-Id: <510A8536-1423-4954-B2A2-3AF2F5804C0F@3roundstones.com>
To: Pat Hayes <phayes@ihmc.us>
On Sep 26, 2012, at 14:19, Pat Hayes <phayes@ihmc.us> wrote:
> On Sep 26, 2012, at 2:23 AM, Antoine Zimmermann wrote:
>> Le 26/09/2012 07:21, Pat Hayes a écrit :
>>> 
>>> On Sep 25, 2012, at 9:28 PM, Sandro Hawke wrote:
>> 
>> <skip/>
>> 
>>>>> 
>>>>>> 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.
>> 
>> This is really a mean attack against the people who are trying to design the semantics.
> 
> No, emphasis on "collective". It is an observation that some of the WG are trying to design semantics for use, and other parts of the WG are assuming, and working on the assumption, that semantics is completely irrelevant and they will implement something handy and ignore the semantics. 

I would characterize that differently:  Some in the WG wish to implement software applications for which they have use cases.  They can't be faulted for doing so.  Naturally, they view semantics as formalizing what they already do (theory following practice).  In converse, others wish to create a model theory and suggest that implementors follow it (practice following theory).  They have good theoretical reasons for thinking so and cannot therefore be faulted.

We have a perspective problem.  Our challenge as a WG is to see each others' (legitimate) perspective.  If we can do that (and occasionally we do) then we can find a compromise on this issue.

Regards,
Dave


> 
>> And, on top of that, it is wrong.
>> 
>> The current proposal is not inconsistent with what Sandro wants. You can say:
>> 
>> { <n> a sd:Graph;
>>   eg:hasSomeMetadataProp <x> . }
>> <n> {
>> #some triples
>> }
>> 
>> Also, make it clear in the graph-metadata vocabulary that a sd:Graph is, say, a graph description.
> 
> How does this work? That first triple is written in RDF, and the RDF semantics says that its truth is determined by whether <I(<n>), I(sd:Graph)> is in I(rdf:type), right? Note, this does not mention any kind of graph extension mapping anywhere. So how does it manage to have any relationship to the graph associated with <n> by pairing <n> with { #some triples }? At least, how without making a basic change to the RDF semantics? (Which I am quite willing to consider, note: I am not just being rhetorical here.) 
> 
>> Oh, BTW, it already exists and it is on the verge of getting standardised. It's called SPARQL 1.1 Service description.
> 
>> 
>> A quick look at the proposed semantics clearly shows that the example is consistent.
> 
> Im sure it is consistent, but seems to me that it doesn't actually say what people are assuming it says. The semantics does not support the natural, intended, meaning. 
> 
> Pat
> 
> 
>> 
>> <skip/>
>> -- 
>> Antoine Zimmermann
>> ISCOD / LSTI - Institut Henri Fayol
>> École Nationale Supérieure des Mines de Saint-Étienne
>> 158 cours Fauriel
>> 42023 Saint-Étienne Cedex 2
>> France
>> Tél:+33(0)4 77 42 83 36
>> Fax:+33(0)4 77 42 66 66
>> http://zimmer.aprilfoolsreview.com/
>> 
>> 
> 
> ------------------------------------------------------------
> 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 19:15:02 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:25:51 GMT