Re: RDF based messaging, negotiating, and dataset semantics

Hi Tobias!

In order to migrate to nanopub, it would actually also have to work in 
javascript for our application. As always and for everyone, our 
resources are limited and I am not at all sure that we'd be able to 
migrate even if both implementations (jena, javascript) were already 
available.

Having said that, I have worked with jena as well as sesame and I think 
I might be able to help doing a jena port. For a javascript 
implementation, I am much less sure of the support I could give.

For the record, here is another advantage of nanopub for our use case: 
The way our system currently works is that the sender of a message mints 
a new URI for the message in the URI space of the server it is using to 
send it. The obvious problem with this approach is that URI collisions 
may occur. Clients have to expect this and be prepared to recreate the 
message with a new URI. The fact that choice of URI is free opens an 
attack vector for a denial of service attack for an attacker that is 
able to spy on the network, obtain the URI and send a message with that 
same URI that is for some reason received first by the server. There are 
ways to circumvent that, but with nanopub, there is no need to. The 
attack is vitually impossible because the attacker would have to find an 
actual hash collision.

Best
Florian

Am 2017-07-05 07:06, schrieb Tobias Kuhn:
> Hi Florian,
> 
> I assume that such a Jena port would be quite straightforward but
> still quite some work. But as I don't have any experience with Jena, I
> don't know how similar or different the underlying models are.
> 
> If there is broader interest in such a Jena-based nanopub library, I
> could look into it.
> 
> Regards,
> Tobias
> 
> 
> On 04.07.2017 10:10, Florian Kleedorfer wrote:
>> Hi Tobias!
>> 
>> Thanks for your suggestion! I really like the concept - it solves the 
>> problem of self-references that kept me from using the document hash 
>> as part of the URI.
>> 
>> Since thinking about this, I gave up on strict immutability of 
>> documents, but the idea may be worth revisiting, maybe using the 
>> memento framework for managing versions.
>> 
>> I see your java implementation is using Sesame. Do you think it would 
>> be much work to port it to jena?
>> 
>> Best
>> 
>> Florian
>> 
>> Am 03.07.2017 um 20:22 schrieb Tobias Kuhn:
>>> Hi Florian,
>>> 
>>> Though not complete solution to your problem, nanopublications 
>>> (http://nanopub.org/wordpress/) with Trusty URIs 
>>> (http://trustyuri.net/) could be the basis for the system you 
>>> describe. They allow you to create immutable RDF snippets with 
>>> metadata and to refer to these snippets in a verifiable manner.
>>> 
>>> Regards,
>>> Tobias
>>> 
>>> 
>>> On 03.07.2017 16:17, Florian Kleedorfer 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!
>>>> 
>>>> Thanks,
>>>> Florian
>>>> 
>>>> 
>>>> 
>>>> 
>>

Received on Wednesday, 5 July 2017 06:40:32 UTC