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

switching semantics

From: Sandro Hawke <sandro@w3.org>
Date: Fri, 24 Aug 2012 12:32:05 -0400
Message-ID: <5037AC85.5010403@w3.org>
To: Pat Hayes <phayes@ihmc.us>
CC: Richard Cyganiak <richard@cyganiak.de>, RDF Working Group WG <public-rdf-wg@w3.org>
On 08/24/2012 11:43 AM, Pat Hayes wrote:
> On Aug 23, 2012, at 2:09 PM, Sandro Hawke wrote:
>
>> [combining responses to Pat and Richard]
>>
>> On 08/23/2012 02:02 PM, Pat Hayes wrote:
>>>>> Partial-graph quoting semantics might also be called "quad" semantics.   You can decompose the dataset into quads that each stands on its own; merging datasets is just the set-union of the quads.  Each quad tells you that a particular triple is in a particular named graph.    There is no way to form a contradiction among such quads.
>>> True, but this also makes the "naming" useless for most purposes, as with this semantics there is no way to ever discover what graph the "name" actually names. It would be consistent to assume that all graph "names" denote the full RDF graph containing all possible RDF triples. This negates the whole point of having such a semantics, IMO. It is certianly not what the original term 'named graph' was supposed to mean, and I strongly suspect is not a sense of 'named graph' that is in use anywhere outside the WG.
>> This was a surprise to me, too, but Lee reported that they often wrote TriG like this:
>>
>> === file 1
>> ... stuff
>>
>> <g1> { ... some triples that go in g1 ... }
>>
>> ... more stuff
>>
>> <g1> { ... more triples that go in g1 ... }
>>
>> === file 2
>>
>> <g1> { ... even more triples that go in g1 ...}
>>
>> ============
>>
>> When I suggested that file1 and file2 contradicted each other, I recall several people agreeing with Lee.  They want to be able to have the triples in g1 spread out throughout multiple locations in multiple files.
>>
>> When we talked about this, it seemed to many people to be perfectly natural, to be "Open World."   Saying that some triples are in some named graphs isn't as useful as enumerating all the triples in that named graph (and declaring you are doing so), but it's not useless.
> Well, OK, so some people like to work in this way. But others want to be bale to actually name graphs, and know what graph they are naming. And if these two needs are incompatible, then we have to make a decision which will annoy someone. Maybe what we should decide is, to give people who need a precise meaning that precise meaning, and let the people who are going to break the semantic rules anyway (because the don't know them or dont care about them) to carry on breaking even more rules.

I agree there are two styles.  I think they are:  SPARQL style (named 
g-boxes) and N3 style (g-snap values).   There have been a couple of 
messages today arguing against the value of named g-snaps [1][2].   I 
think it just gets folks into trouble to try to use TriG to work with 
g-snaps.

I think it would be MUCH better to have two distinct syntaxes with 
different semantics than one syntax with a subtle flag for which 
semantics is intended.     So, we could have a named-g-box syntax 
(looking like TriG) and a g-snap-literals syntax (looking a bit like 
N3), if we want to support both communities.

For myself, I've been in the g-snap-values camp for about 12 years --- 
BUT I've convinced myself I can address all the use cases just fine 
(maybe better) with named g-boxes.

I don't think either group wants or needs to break/ignore any semantics, 
FWIW.

       -- Sandro


[1] http://lists.w3.org/Archives/Public/public-rdf-wg/2012Aug/0217.html
[2] http://lists.w3.org/Archives/Public/public-rdf-wg/2012Aug/0215.html

> Pat
>
>> On 08/23/2012 11:46 AM, Richard Cyganiak wrote:
>>> On 23 Aug 2012, at 16:17, Sandro Hawke wrote:
>>>>> The quoting semantics makes it a contradiction if dataset A and dataset B contain the same graph IRI with different associated graphs. We cannot do semantic extensions that produce useful additional entailments from a contradiction.
>>>> Not true.   There are two versions of the quoting semantics -- partial-graph semantics and complete-graph semantics.
>>> The "partial-graph quoting semantics" is really just a broken form of "truth semantics". It is broken because it arbitrarily emulates one effect of entailment (the fact that dropping any triple from a true graph yields a true graph), while not emulating all the other effects of entailment (e.g., the fact that substituting any subject or object with a blank node in a true graph yields another true graph, or that adding redundant inferred triples doesn't affect truth, or that substituting one literal with an equal-valued literal doesn't affect truth, or that replacing one blank node with another fresh blank node doesn't affect truth).
>> I agree the machinery of partial-graph quoting semantics is the same as that of a very limited truth semantics, as you describe it.    I think the intuitions and motivations are quite different, however.
>>
>>>>    The discussion here in recent days has focused on the complete-graph quoting semantics, but in previous telecons we had near consensus (everyone but Eric) on using the partial-graph semantics.
>>> No, we had near consensus that "complete-graph quoting semantics" is not desirable. I think what you interpret as support for "partial-graph quoting semantics" was mostly support for "some form of truth semantics".
>>>
>> That's not how I recall it, and looking over the record doesn't change my mind.   It doesn't really matter whether we had consensus or not, except as far as it helps shed light on where we are now, so I only bring it up for that purpose.   But please do look over point 7 on http://lists.w3.org/Archives/Public/public-rdf-wg/2012Apr/0165.html .
>>
>> Also, to be clear, I'm not trying to advocate for any particular semantics -- I just would like something that gets folks closer to being able to address the use cases.   I think complete-graph quoting semantics is probably that, but I took guidance from that 25 April meeting that partial-graph quoting semantics was a more promising route.   In my implementation, as I recall, partial worked fine, with the usual RDF best-practice that systems semantically *can* drop triples but in general they do/should not.
>>
>>      -- Sandro
>>
>>
>>
>>
>>
>>
>>
>>
> ------------------------------------------------------------
> 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 Friday, 24 August 2012 16:32:08 UTC

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