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 <pha...@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) > pha...@ihmc.us http://www.ihmc.us/users/phayes > > > > > >
