Re: defn of Named Graph

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 18:46:46 UTC