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

Re: Dataset Syntax - checking for consensus

From: Antoine Zimmermann <antoine.zimmermann@emse.fr>
Date: Thu, 27 Sep 2012 12:09:21 +0200
Message-ID: <506425D1.2090906@emse.fr>
To: public-rdf-wg@w3.org, Pat Hayes <phayes@ihmc.us>
Le 26/09/2012 20:19, Pat Hayes a écrit :
> 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.

This is implied by what you said, but you were making a more precise and 
technical remark, namely that a name denotes one thing and only one, ant 
it is obvious. I don't think there has been, in recent conversations, 
anyone contradicting that. So, pretending that this is not well 
understodd collectively by the WG, in spite of its obviousness, seems harsh.

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

It does not mention the IGEXT mapping indeed. In absence of further 
information, the connection between <n> and the actual graph in the 
dataset is not known. But <n> is not supposed to denote a graph. You 
want to say things like:

<n>  :lastModified  "2001-01-01" .

which requires that <n> is *not* a graph. And that is fine and 
consistent with a semantics of the kind that we proposed.
Now, if you *do* want to have a connection between <n> and the actual 
triples associated with it, there are possible solutions. I may not have 
the best, and with imagination one could invent more elegant ones, but 
maybe the following:

<n>  eg:turtleSerialisation  "<s> <p> <o> . <a> <b> <c>" .

or this horrible solution, less syntax-dependent:

<n>  eg:contains  (
  [a rdfs:Statement; rdf:subject <s>; rdf:predicate <p>; rdf:object <o>]

In fact, using Service description, it would be better to do something 
like this:

<n>  a  sd:NamedGraph;
   sd:name  "n"^^xsd:anyURI;
   eg:contains ...

Because then, the graph IRI is given explicitly (which avoids problems 
that can occur with owl:sameAs, for instance).

And all this is consistent with the semantics.
Of course, something of type sd:NamedGraph should not be an actual pair. 
Rather it should be an entity that serves for the description of a named 
graph pair. In fact, the words in Service description say:

"An instance of sd:Graph represents the description of an RDF graph."

Notice that it does not say that an instance of sd:Graph represents an 
RDF graph.

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

Of course, if they want to actually talk about a specific RDF graph, it 
does not mean what they mean, but I'm sure that in almost all cases, 
even if those people think they want to talk about the RDF graph, they 
actually require something else, like a container, or a description, or 
an avatar of the graph.

> 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

Antoine Zimmermann
ISCOD / LSTI - Institut Henri Fayol
École Nationale Supérieure des Mines de Saint-Étienne
158 cours Fauriel
42023 Saint-Étienne Cedex 2
Tél:+33(0)4 77 42 66 03
Fax:+33(0)4 77 42 66 66
Received on Thursday, 27 September 2012 10:09:47 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:02:07 UTC