- From: Jeremy J Carroll <jjc@syapse.com>
- Date: Fri, 27 Sep 2013 16:12:34 -0700
- To: Sandro Hawke <sandro@w3.org>
- Cc: Pat Hayes <phayes@ihmc.us>, Dan Brickley <danbri@danbri.org>, Gregg Reynolds <dev@mobileink.com>, www-archive <www-archive@w3.org>
I also wish to use dcterms:issued Adam and Bettie issued the graph for different purposes on different dates, and the issued property is really about the named graph and not about the graph per se. Jeremy J Carroll Principal Architect Syapse, Inc. On Sep 27, 2013, at 2:34 PM, Sandro Hawke <sandro@w3.org> wrote: > > > Jeremy J Carroll <jjc@syapse.com> wrote: >> 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. >> > > This use case can be addressed by I(n)=g. If some of the graph contents turn out to be the same, that's fine. If Adam and Bettie created the same RDF triples, then it's fine to say they created exactly the same thing. That is, there is one thing and they both "created" it. (I put l "created" in quotes because in a sense all RDF graphs already exist. But in the same sense all character strings already exist, so I'm not exactly creating this message.) > > - Sandro > >> 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 >>> >>> >>> >>> >>> >>> > > -- > Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Received on Friday, 27 September 2013 23:13:05 UTC