Re: RDF based messaging, negotiating, and dataset semantics

Currently, I'm happy if at any point in time (time being defined by the 
last message sent) a set of triples can unambiguously be collected from 
the conversation (taking deletion, and maybe restoring into account) and 
we can evaluate SHACL constraints and execute SPARQL queries on them. 
The validity of the reults is bound to the state of the conversation, 
which is fine with me.

Which problems do you see us running into, specifically?


Am 06.07.2017 um 21:24 schrieb Sampo Syreeni:
> 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.

Received on Friday, 7 July 2017 10:31:28 UTC