W3C home > Mailing lists > Public > public-interledger@w3.org > April 2017

Re: Standards in Smart Contracts

From: Stéphane Canon <stephane.canon@scarlet.be>
Date: Wed, 26 Apr 2017 20:06:24 +0100
Message-Id: <11319085-96E1-482A-BEE1-C92E79F7EB6F@scarlet.be>
Cc: pferris@objectchain.com, Adrian Hope-Bailie <adrian@hopebailie.com>, Michiel de Jong <michiel@ripple.com>, Interledger Community Group <public-interledger@w3.org>
To: Andrew Bransford Brown <andrewbb@gmail.com>


What about starting from the concepts of Obligation / Obligation fulfilment, a contract being a set of both. This version is inspired from ISO20022 with some additional definitions.
A typical “Purchase” contract is composed of a Delivery Obligation and a Payment Obligation. Among the agreed prestation, the Seller must deliver a  Product or Service and produce an Invoice. The Payment Obligation is fulfilled by the Payment… 
One can imagine different synchronisations of events: in a typical trade contract, the payment can be triggered by the validation of the documents by a third party…
Such a model can be refined and enriched to finally become a framework of concepts that multiple parties can use to formalise contracts. This process of standardisation must be open. It is a guaranty of quality and it also facilitates adoption. 

The ISO standardisation process is not an open process. Among other things, I still not understand the value of developing standards in closed user groups and the benefit of charging +_ EUR 200 to access the documentation. The collection of this fee costs probably more than EUR 200 to the ISO Organisation. It would be less expensive to give the standards for free and it would facilitate adoption.

Stephane


  
> On 25 Apr 2017, at 18:10, Andrew Bransford Brown <andrewbb@gmail.com> wrote:
> 
> That's a good place to start.
> 
> What about simple event messages?  Promise, Want, Deliver OR Offer, Terms Deliver.  Then a modifier to those terms can be added:
> 
> Promise
> Promise-Cancel
> Promise-Units
> Promise-DeliverBy
> etc.
> 
> Each is an event so can run code before and after:
> http://34.208.7.206/ContractsPage.aspx <http://34.208.7.206/ContractsPage.aspx>
> 
> It forms its own audit trail.
> 
> On Tue, Apr 25, 2017 at 1:05 PM, Stéphane Canon <stephane.canon@scarlet.be <mailto:stephane.canon@scarlet.be>> wrote:
> Paul,
> 
> After developing ISO20022, I’ve been asked to develop the data model for the PSD2 Payments APIs. I’ve been using the ISO20022 terms and definitions (known as "business components” and “business elements” in ISO20022) and developed the APIs with SWAGGER.
> 
> Before that, I’d looked several times at “ontologies” but always thought it was “a solution more complex than the problem”. I however realised that my PSD2 API data model was very close to RDF triples. 
> I could avoid to copy/paste the terms and definitions from the ISO20022 model if my conceptual model was a RDF or RDF/OWL model and my API was using JSON-LD.
> The fact that properties are real entities would also facilitate their reuse and improve readability.
> ISO20022 is the only finical standard coming with a conceptual model, even if it is not very visible. Other standards are often based on some kind of conceptual model defined in XML (Fpml, XBRL,…). Others are based on complex frameworks (eg. IBM IFW) that make each concept very complex and distant from any business reality (lost in a complex structure of xsi:type…)
> 
> JSON-LD and RDF or RDF/OWL allows avoiding the multiple transformation between the conceptual model, the “messaging” model and the symbols used when coding.
> RDF triples are also quite understandable by business users. This is an essential dimension: knowledge representation techniques must be understood by knowledgeable people, specifically when the technique is used to represent “smart contracts”. RDF/OWL with rules in SWRL is certainly a better choice than UML and OCL. 
> 
> Regards,
> Stephane
> 
> 
> 
>  
>> On 18 Apr 2017, at 17:25, Paul Ferris <pferris@objectchain.com <mailto:pferris@objectchain.com>> wrote:
>> 
>> Hi Stephane
>> As you point out, other specifications and the work involved are way ahead of the brand new TC307  -  which is bad & good.  Bad that a great deal of fundamental work needs to be done for DLT, good that there is much to learn from work done in other contexts.  Certainly, there is the appetite to share and collaborate from the ISO delegates.  A quick description of your learning re: UML - RDF/OWL would be very much appreciated.
>>  
>> Here is a list of liaisons already set up (more are proposed, but may not have been established as yet)
>>  
>> Liaison Committees to ISO/TC 307
>> Reference
>> Title
>> ISO/IEC
>> ISO/IEC JTC 1 <https://www.iso.org/committee/45020.html>	
>> Information technology
>> ISO/IEC
>> ISO/TC 154 <https://www.iso.org/committee/53186.html>	
>> Processes, data elements and documents in commerce, industry and administration
>> ISO
>> ISO/TC 184/SC 4 <https://www.iso.org/committee/54158.html>	
>> Industrial data
>> ISO
>> ISO/TC 262 <https://www.iso.org/committee/629121.html>	
>> Risk management
>> ISO
>> ISO/TC 292 <https://www.iso.org/committee/5259148.html>	
>> Security and resilience
>> ISO
>> Liaison Committees from ISO/TC 307
>> Reference
>> Title
>> ISO/IEC
>> ISO/IEC JTC 1 <https://www.iso.org/committee/45020.html>	
>> Information technology
>> ISO/IEC
>> ISO/IEC JTC 1/SC 27 <https://www.iso.org/committee/45306.html>	
>> IT Security techniques
>> ISO/IEC
>> ISO/TC 262 <https://www.iso.org/committee/629121.html>	
>> Risk management
>> ISO
>>  
>> Hope this helps
>> Best regards
>>  
>> Paul Ferris
>>  
>>  
>> From: stéphane canon [mailto:stephane.canon@scarlet.be <mailto:stephane.canon@scarlet.be>] 
>> Sent: 18 April 2017 16:36
>> To: pferris@objectchain.com <mailto:pferris@objectchain.com>
>> Cc: Adrian Hope-Bailie; Michiel de Jong; Andrew Bransford Brown; Interledger Community Group
>> Subject: Re: Standards in Smart Contracts
>>  
>> Thanks Paul,
>>  
>> I assume one of the discussions must be on the specification approach. I’ve been involved in the development of ISO20022 using UML. For multiple reasons, RDF/OWL would be a better choice than UML.
>> Is the idea to develop a « smart contract » standard or to develop a set of rules and conditions to be met to have valuable « contracts »? To be « trusted », some kind of process would be required to negotiate, approve and store the contract definitions. Existing processes (eg. ISO20022) are very rigid. The nature of BlockChain/DLT is asking for something moe flexible, more open… and free…
>>  
>> Regards,
>> Stephane
>>  
>>  
>>> Le 18 avr. 2017 à 16:09, Paul Ferris <pferris@objectchain.com <mailto:pferris@objectchain.com>> a écrit :
>>>  
>>> Hi All
>>> Sorry to crash into this list, but I have been a good listener for many months and I thought I could contribute a little, especially regarding standards (for what it’s worth).
>>>  
>>> We have just completed the first international meeting of ISO for standards in blockchain and DLT (or in ISO parlance, TC3017).  Discussion among the 70-odd international delegates was informed by pre-work contributed by one of the widest groups of countries that have ever adopted a new standards process for a new technology area.
>>>  
>>> And yet, the discussions in the area of smart contracts hit some very early problems.  Even the term “Smart Contracts” was a specific item of discussion, with some lawyers and others proposing they are neither ‘smart’ (in the legal world) or ‘contracts’ (in either legal or technical worlds).   The meeting resolved to kick off a study group (termed: ISO/TC 307/SG 5) to coordinate development in this area.
>>>  
>>> Of course, I’m not suggesting that standards are only standard when some international body reaches consensus between national delegates; standards are often created by good practice, and perhaps underpinned by W3C for instance.  But even here, I’d say we are some way off reliable standards in this area.  
>>>  
>>> Nevertheless, developing processes and definitions (such as spoken about here) and other aspects of smart contracts so that ‘good practice’ can be assumed, will (in my opinion) require good coordination between a number of specialist areas; certainly technology (coding) and law, but others too.  If this group decided to contribute by establishing a separate mailing list, and if the list became successful, I would be happy to coordinate to establish an official “Organization in liaison” between Interledger and the ISO processes in this area.  There is already coordination between W3C and ISOTC307, even at this early stage.
>>> That way, in or out of scope of Interledger, we could make sure everyone has a voice and help solve problems more rapidly.
>>>  
>>> I hope I haven’t overstepped the mark with my rather lengthy contribution, just happy to help if I can.
>>>  
>>> Paul Ferris
>>>  
>>>  
>>>  
>>> From: Adrian Hope-Bailie [mailto:adrian@hopebailie.com <mailto:adrian@hopebailie.com>] 
>>> Sent: 18 April 2017 13:07
>>> To: Michiel de Jong
>>> Cc: Andrew Bransford Brown; Interledger Community Group
>>> Subject: Re: Promise App
>>>  
>>> > Maybe it's worth creating a separate mailing list that discusses topics more around 'Conversations for Action' (promises, offers, etc.), and keep this mailing list strictly about Interledger?
>>> 
>>> Not a bad idea. I am surprised by the lack of coherence around standards for "smart contracts" and this probably fits in that category. Do any of the other W3C folk on this list know of any CGs addressing this kind of thing?
>>>  
>>> On 18 April 2017 at 10:58, Michiel de Jong <michiel@ripple.com <mailto:michiel@ripple.com>> wrote:
>>> Hi Andrew,
>>>  
>>> Thanks for your post - I totally agree with you that it's important to understand the terminology around 'promise', 'want', 'offer', 'terms', and 'counter' that lead up to a payment.
>>>  
>>> However, this community group was created for discussing Interledger, and its scope is therefore limited to payments, and the ledger transfers involved in making these payments work across ledgers (hence the name "inter"-"ledger").
>>>  
>>> 'Why' a payment occurs, 'how' the two parties agreed on the payment amount, 'what' service or goods the payment is for, and even whether it's an up-front payment (creating a debt) or an afterwards payment (resolving a debt), is out of scope.
>>>  
>>> I recently added a glossary to the RFCs repo, which might be of interest: https://github.com/interledger/rfcs/blob/master/0019-glossary/0019-glossary.md <https://github..com/interledger/rfcs/blob/master/0019-glossary/0019-glossary.md> - as you can see, it only discusses terminology surrounding Interledger payments.
>>>  
>>> Do you think Interledger should describe more than just payments? Personally, I think it would make the scope to broad.
>>>  
>>> Maybe it's worth creating a separate mailing list that discusses topics more around 'Conversations for Action' (promises, offers, etc.), and keep this mailing list strictly about Interledger?
>>>  
>>> What do others think?
>>>  
>>>  
>>> Cheers,
>>> Michiel.
>>>  
>>> On Mon, Apr 17, 2017 at 12:18 AM, Andrew Bransford Brown <andrewbb@gmail.com <mailto:andrewbb@gmail.com>> wrote:
>>> Understanding adversarial contract disputes and resolution:
>>> http://34.208.7.206/ContractsPage.aspx <http://34.208.7.206/ContractsPage.aspx>
> 
Received on Wednesday, 26 April 2017 19:07:06 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 26 April 2017 19:07:06 UTC