Re: Standards in Smart Contracts

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/
> 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> wrote:
> Understanding adversarial contract disputes and resolution:
> http://34.208.7.206/ContractsPage.aspx
>
>
>