Re: RDF based messaging, negotiating, and dataset semantics

Thanks for the explanation! Bit of a tangent here, but have been thinking about integrating payment information too, to get to a kind of smart contract engine, if you will, that can trigger actions (messages or state changes in other linked data resources) based on payments made.

What were you going to do with payment info integrated in a chat?

Am 3. Juli 2017 18:38:50 MESZ schrieb Melvin Carvalho <melvincarvalho@gmail.com>:
>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
>>>
>>>
>>>
>>>
>>>     --
>>>
>>>
>>