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

Re: switching semantics

From: Pat Hayes <phayes@ihmc.us>
Date: Fri, 24 Aug 2012 12:39:29 -0500
Cc: Richard Cyganiak <richard@cyganiak.de>, RDF Working Group WG <public-rdf-wg@w3.org>
Message-Id: <9D305CEF-4997-4165-AF3F-32852B774C15@ihmc.us>
To: Sandro Hawke <sandro@w3.org>

On Aug 24, 2012, at 11:32 AM, Sandro Hawke wrote:

> 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 dont think the box/snap distinction is really the important one here. I am quite happy with Nathan's analysis in [1], that we can only name boxes, but some boxes are "fixed". The distinction we are concerned with here is between being able to associate a name with a specified graph (maybe the association being through a fixed box), and only being able to say that the associated graph contains some triples. Open versus closed graph assumption (or maybe soft vs. hard?), one might phrase it. If we are going to use things like checksums to establish identity, we can't be all sloppy about having triples flop in and out. 

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

I agree entirely, but I worry that if we fix Trig syntax with one interpretation, we will never get around to inventing the syntax for the other case. 

Pat

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

------------------------------------------------------------
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 17:40:03 UTC

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