Re: RDF based messaging, negotiating, and dataset semantics

On 3 July 2017 at 18:31, Florian Kleedorfer <florian.kleedorfer@austria.fm>
wrote:

> Thanks for the hint! webid.im is clearly related!
>
> However, from http://webid.im/paper/ I don't see how you would formulate
> a message that would select or deselect earlier messages in a conversation
> such that one could compute the set of selected triples in the conversation
> dataset or determine if the conversation participants agree.. is that
> something you were working on?
>
> (sorry if I am not getting it)
>

My design was a little bit different, just trying to model a chat system.
So it was not immutable, but you could make statements about other
messages, such as 'liking' a message.

In my design, I just put that in the same file as the message, but it could
have perhaps gone onto the end of the list of messages.

Solid / Linked Data Platform was used to store a number of messages in a
directory (aka container), one container for each days worth of messages.

It would however have been possible to extend to having statements about
messages, each having a UUID.  That part wasnt fully sketched out.  Longer
term aim was to add fun things like payments and unusual chat workflows
that could influence other parts of the semantic web in realtime.

Never quite got that far tho, I will hopefully have some time to pick this
up again, when there are more working Solid servers available.


>
> Best
>
> Florian
>
>
> Am 03.07.2017 um 17:35 schrieb Melvin Carvalho:
>
>
>>
>> On 3 July 2017 at 16:17, Florian Kleedorfer <
>> florian.kleedorfer@austria.fm <mailto:florian.kleedorfer@austria.fm>>
>> wrote:
>>
>>     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!
>>
>>
>> I had a go at this a while back.
>>
>> http://webid.im/paper/
>>
>> Unfortunately I had to put the project on hold for a bit due to time
>> constraints (particularly as angular 1.0 experienced breaking changes), and
>> a shortage of servers to test on.
>>
>> But it was a largely working implementation, except for the cryptographic
>> signatures.  Instead of graphs n3/trig style I took a simpler approach, to
>> start with, of putting one message (SIOC vocab) per file.
>>
>>
>>     Thanks,
>>     Florian
>>
>>
>>
>>
>>     --
>>
>>
>