Re: RDF based messaging, negotiating, and dataset semantics

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

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