RDF based messaging, negotiating, and dataset semantics

Hi,

Consider a communication channel between two agents who exchange 
messages in the form of named RDF Graphs. The channel allows for adding 
new messages but not for removing any data. The history of the channel 
is unambiguous and always accessible to both agents. This construct can 
be seen as an RDF dataset that both agents have read/write but no 
replace or delete access to. Its use is that of a negotiation device 
that allows for setting up terms of a contract.

The way the system is built, the messages consist of any number of 
'content' RDF graphs (the message's payload), 'envlope' graphs with 
address information (sender, recipient etc),  and graphs containing 
cryptographic signatures.

What's needed is an approach that allows these agents to make assertions 
about earlier messages (their content graphs) in the conversation 
dataset so as to modify the meaning of the dataset.

The simplest example I can think of is that one agent might realize they 
made a typing error in an earlier message and want to correct the 
information by sending a message stating that the earlier graph should 
be disregarded and another message containing the corrected information.

Similar situations occur when negotiating aspects of the agreement, e.g. 
price.

For both agents, at any point in the conversation, the meaning of the 
conversation dataset must always be unambiguous and equal, and it must 
be clear to both agents if they agree (both hold the same graphs true) 
or if there is a conflict.

I am contemplating defining a vocabulary that allows for making such 
statements and defining dataset semantics that take these statements 
into account, unless I find a suitable existing approach. I found the 
SWP (Semantic Web Publishing) vocabulary, which is intended to do 
something similar, but does not seem to have a negative property for 
rejecting a graph, so I'm not convinced. Any Ideas, pointers, or 
followup discussions are greatly appreciated!

Thanks,
Florian




--

Received on Monday, 3 July 2017 14:18:01 UTC