Re: Standards in Smart Contracts

Obligation is what happens AFTER the contract is created.
Fulfillment is delivery upon the contract.

We could add Obligation/Fulfillment as an alternative to Promise/Deliver or
Offer&Terms/Deliver, but would require words to describe contract formation
(negotiation).

Interestingly, the structure remains the same:
http://34.208.7.206/ContractsPage.aspx



On Wed, Apr 26, 2017 at 3:06 PM, Stéphane Canon <stephane.canon@scarlet.be>
wrote:

>
>
> 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
>
> It forms its own audit trail.
>
> On Tue, Apr 25, 2017 at 1:05 PM, Stéphane Canon <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> 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
>> <stephane.canon@scarlet.be>]
>> *Sent:* 18 April 2017 16:36
>> *To:* 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> 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
>> <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> 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/00
>> 19-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> wrote:
>> Understanding adversarial contract disputes and resolution:
>> http://34.208.7.206/ContractsPage.aspx
>>
>>
>>
>
>
>