Re: RDF based messaging, negotiating, and dataset semantics

Quick response below inline. Basically, I entirely agree with you, BUT…

> On Jul 6, 2017, at 12:24 PM, Sampo Syreeni <decoy@iki.fi> wrote:
> 
> On 2017-07-06, Pat Hayes wrote:
> 
>> There is a conceptual bug in this whole discussion: delete (and undelete) are not RDF properties.
> 
> Or, in other words, RDF deals with logical models of the surrounding world. Factual, static states. If you want to build up a logically coherent system and protocol for transitions between such states, wording it using the RDF machinery, so much the better for you.
> 
> But given how difficult it was to arrive even at the static semantics of RDF as they now stand, systematically incorporating time is going to be a *whole* *project* of its own. The semantics of "delete" might be the paradigmatic example of what could go wrong, but they're not the only one by a long shot.
> 
> I'm a relational guy of the old ilk. The kind whose underlying data model comes from a time when some people on this list weren't even born yet (me being a mere 38a old as well). And yet I can't with good conscience say even the relational model has somehow gotten its head around mutable state. Nor has the functional programming crowd, notwithstanding the idea of monads and whatnot.
> 
> Time and the mutable state which goes along with it does eventually have to be dealt with. But that exercise is far from trivial. There's an entire literature of different kinds of temporal logics out there, trying to settle that very question, and then in various ways each of them failing spectacularly. So it just is *not* a question of putting in some "delete" "instruction"; not by a *long* shot.
> 
>> In general, operations on RDF graphs are not RDF properties.
> 
> Of course perhaps they could be. Even should be. But my god the structure which would have to go into them and even their normalization in basic linear logic... Jesus H.!

Actually I don’t think it is that hard to do, technically, but coming to an agreement on it is just about impossible. But the point is, this is all about what some future RDF might be like. RIght now, RDF has a semantics, which is part of its normative specification, so has to be respected by any conforming RDF application. And that semantics is quite clear about what properties are and (more to the present pint) are not. 

> 
>> Properties simply record facts, they do not ‘do’ anything.
> 
> Properties such as the ones relating entire states of relational databases before and after an update, can be interpreted to 'do' stuff. They can to a degree be factored into clauses in a suitable update language, related to the query language, and, say, a set (sequence? in which order?) delete and insert clauses. There are tabular calculi and whatnot, with neat equivalences to fragments of higher order logic in descriptive complexity theory. Whathaveyou.

But see above. They exist, but tthey are not part of the (to repeat) *normative* RDF specifications.

> Much of what we'd think is necessary here has already been formalized...but not all. By a long shot.
> 
>> Think of the properties as simply being a record of what changes were made, and then there is no ambiguity: restoring a message that was previously deleted, and deleting the record of its first deletion, are different and quite distinct changes (indeed, changes to different graphs, in one design) and should each be recorded separately and unambiguously.
> 
> Indeed, and the many disparate attempts at introducing time into the relational model and its query semantics prove as much. Every one of the serious ones for instance introduces a calculus of one sort of timestamp or another, which you can't then reify within the rest of the calculus without introducing anomalies.

Indeed. 

Pat

> -- 
> Sampo Syreeni, aka decoy - decoy@iki.fi, http://decoy.iki.fi/front
> +358-40-3255353, 025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2

Received on Saturday, 8 July 2017 16:55:56 UTC