Re: defn of Named Graph

I feel that Sandro's text has asked the WG for too much and is motivated by the insoluble use case of dealing with time.

A shorter proposal, motivated by other intensional use cases, such as Pat's signing, but any involving stating some intent about a graph, rather than some mathematical property of th graph.

Here is a very short use case:

[[
I wish to publish a dataset involving three graphs - one create by Adam, the second created by Bettie and the third created by Charles.
I wish to use dc:creator to convey this.
]]

Note that the three graphs will generally be different, but could be the same.

And the a short proposed text is to suggest using interpretations where

I(uuu) = < uuu, ggg >

where uuu names ggg in a dataset

How to say that with buy-in is the question - it has the 'right' semantic consequences

It could be with MUST force, SHOULD force or MAY force.

--

Only saying something  in Concepts leaves a mess in the Semantics section that deals with named graphs; so the smallest possible edit is to change that section in semantics only




Jeremy J Carroll
Principal Architect
Syapse, Inc.



On Sep 27, 2013, at 11:46 AM, Pat Hayes <phayes@ihmc.us> wrote:

> 
> On Sep 24, 2013, at 8:31 AM, Sandro Hawke wrote:
> 
>> On 09/20/2013 04:44 AM, Pat Hayes wrote:
>>> On Sep 19, 2013, at 9:52 AM, Sandro Hawke wrote:
>>> 
>>>> ....
>>>> So, I hereby propose we give up on all this until after we solve the change-over-time problem for RDF.
>>> ....
>>> 
>>> Well, I do have other things to do in my life
>> 
>> Sorry....     Hopefully you at least find this satisfying, enjoyable, or entertaining from time to time.
>> 
>>> , but I think this is a very bad stance to take. The change-over-time-problem is not ever going to be "solved". it is not a problem with a solution. If it were, there would be one accepted tense logic and one accepted semantic theory for programming languages.
>> 
>> To me, it would be "solved" if there was a way to handle change-over-time that worked for my applications and that you didn't think was "broken" wrt RDF Semantics.    Hopefully other members of the community would like it, too. I don't think we need the perfect solution, or even consensus at this point.   Just something that some of us can use in our software with some reasonable hope it'll function as expected, and not violate the specs in any problematic way.
>> 
>>> But this type/token business does not require us to solve it. It is a much simpler, more basic kind of clarification that does not depend in ANY WAY on the change-over-time issue. With the greatest respect, Sandro, your obsession with time and change has, I believe, hindered progress here. You keep going back to that issue, even when we have finally managed to agree (at least I thought we had) that the surface/token/named-graph vs. abstract graph distinction did not depend upon time or change, or even involve it.
>>> 
>> 
>> I come back to it obsessively because there is such a dirth of other use cases.  (Perhaps I have a bias of wanting to solved for other uses cases; I'm trying hard to keep that in check.)      In recent weeks, I tried to keep this discussion to being just about identity without touching on change-over-time, but frankly I don't find the use cases compelling.
>> 
>> I'm now confident that you and I (and Jeremy) agree the problem we're trying to solve in this thread is this: people seem to want to have different properties on one "graph" than on another, even when the "graphs" happen to have the same triples.
>> 
>> But why do they want this?   As I poke at that problem, either it turns out this functionality doesn't actually matter to them, or they need it because they are actually dealing with "graphs" which could at least potentially change over time.
>> 
>> Do you have a use case (involving RDF on computers) for having different properties on different "graphs" (which happen to have the same triples), and which does not involve "graphs" changing over time?
> 
> Sure, the use case that was the primary motivation for the original named-graph proposal, which was publishing RDF with a 'warrant' of authenticity, in the form of a robust digital signature, and allowing one of these to mention another using an IRI link. All this secure fixing of provenance and authentication is meaningless if the final contents can be changed at will; and yet it is also meaningless if understood as applying to an abstract set. 
> 
> Pat
> 
> 
> ------------------------------------------------------------
> IHMC                                     (850)434 8903 home
> 40 South Alcaniz St.            (850)202 4416   office
> Pensacola                            (850)202 4440   fax
> FL 32502                              (850)291 0667   mobile (preferred)
> phayes@ihmc.us       http://www.ihmc.us/users/phayes
> 
> 
> 
> 
> 
>

Received on Friday, 27 September 2013 20:19:54 UTC