Re: defn of Named Graph

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

I believe that use case can also be addressed by I(n)=g.    There is no metadata about one of these "graphs" that doesn't transfer to all other ones with the same triples, so they can just be ordinary RDF Graphs.

     - Sandro

>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

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Received on Friday, 27 September 2013 22:57:19 UTC