Re: [clr-dev] Philosophy behind the CVA contracts

[ericdes <eric@vcardprocessor.com>]

Ken,

You reply definitely makes sense. You've brought some new ideas I'll 
implement in our software. Thank you for your insights.

Eric.

On 2/9/2011 10:38 AM, G. Ken Holman wrote:
> At 2011-02-08 22:24 -0600, ericdes wrote:
>> Yes, I'm sure I need to word it a bit differently...
>
> Well, I'm pretty sure I know what you are asking for and I'm pretty 
> sure it is magic if my earlier answer didn't help you.
>
>> What I asked previously was:
>>
>> - if I use ES as the country code for Spain, a program will 
>> eventually find from the ISO list that it is 'SPAIN'.
>> - But using a CVA contract with a partner, the same program will find 
>> that the code SP is for e.g. 'Spain'.
>>
>> Now the question is how this program might find that 'Spain' is the 
>> same entity as 'SPAIN'.
>
> Right.  And there is no magic available.  The program has to have some 
> information to say that "Spain" and "SPAIN" represent the same concept.
>
>> Here you'll notice that I didn't use the same cases to differentiate 
>> both entities. You replied that ISO is now providing a number to 
>> identify countries and I thought that if such a universal primary key 
>> exists then it's a matter of simply mapping the codes to the keys, or 
>> better yet don't use the codes at all, and use directly the primary 
>> keys (why would we need an overhead?).
>
> Because of brevity, mnemonic, accuracy and convenience.  Using the 
> payment means code "51" is more accurate, concise and convenient than 
> trying to type "FR, norme 6 97-Telereglement CFONB (French 
> Organisation for Banking Standards) - Option A" correctly every time.  
> Using the country code "US" is more mnemonic than using the numeric 
> "840".
>
>> But I should take another example where I guess no universal primary 
>> key will apply, e.g. 'MBPS' for 'Megabits per seconds' (in a CVA 
>> contract #1) vs. 'Mb/s' for 'Mbits / seconds' (in a CVA contract #2).
>
> Actually, "E20" represents a "megabit per second" in the international 
> code list for units of measure:
>
> http://docs.oasis-open.org/ubl/prd1-UBL-2.1/cva/UBL-DefaultDTQ-2.1.html#d27e1 
>
>
> ... but I know what you are getting at is you are trying to find 
> something for which a key doesn't exist.
>
>> Now we have to find a way for the same program to understand that a 
>> value of e.g. 512 MBPS is the same as 512 Mb/s.
>>
>> I think that declaring the meaning of those notions would ideally 
>> take place in the Genericodes.
>
> Sure ... and a PSI URI would be a way to do that in the genericode.
>
>> And this could be done like this:
>>
>> In Codelist #1 used in CVA contract #1, we state that the meaning of 
>> 'MBPS' is linked to e.g. this definition: 
>> http://en.wikipedia.org/wiki/Megabit_per_second#Megabit_per_second
>>
>> In Codelist #2 used in CVA contract #2, we state that the meaning of 
>> 'Mb/s' is linked to e.g. this definition: 
>> http://searchnetworking.techtarget.com/definition/Mbps. But we could 
>> also add that we're also using another definition for the same notion 
>> with 
>> http://en.wikipedia.org/wiki/Megabit_per_second#Megabit_per_second as 
>> well.
>>
>> I wouldn't see the definition as a primary key. The definition should 
>> link to a human readable text that unambiguously says what the entity 
>> is (I think this is missing from the ISO lists),
>
> Sure!  That is a nice thing about a PSI, is that it can point to 
> anything and the more descriptive of what it points to, the easier it 
> is for a *human* to understand what it is.  But to a program it is 
> just a string.
>
> If the PSI is found in the middle of a topic map, and the program 
> knows how to infer relationships in a topic map, then perhaps the 
> program can do a fair-to-middlin attempt at guessing what the concept 
> is.  The more relationships it has to work with, the better.  But the 
> program has to know the semantics of what your semantic is related to.
>
>> or better yet a pool of servers publishing a web service that would 
>> serve the definition in a way that computers would understand 
>> (ontology?). In this specific case we could also envision that those 
>> web services would return some formulas to convert to other units.
>
> Sounds like an ISO 13250 Topic Map to me.
>
>> How would the program handle this?
>
> By inferring the relationships between concepts expressed in a 
> bidirectional graph represented by a topic map.
>
> But not in a simple taxonomy of a genericode file.
>
>> Well, it could parse the data retrieved from the URI and try to learn 
>> what it means, probably with the help of a person.
>
> You've articulated the objective of Topic Maps ... relate information 
> to other information so that programs can infer indirect relationships 
> to better help understand the concept being referenced.
>
>> The goal is
>> - to not to have to modify the program each time we get a new CVA 
>> contract with new code lists,
>> - and also have programs work the same way as humans do with code 
>> lists, i.e. look up in a reference document.
>
> And that is why bodies like ISO come up with country code lists, 
> currency code lists, payment means lists, units of measure lists, etc.
>
>> Now it's very possible that genericodes as they are allow to do this. 
>> It was my question if there was something in CVA / Genericode that 
>> would help a program make the link between 2 different codes having 
>> the same meaning.
>
> In a simple collection of value-level metadata fields associated with 
> codes, probably only if there is a "primary key" (as you called it) 
> valued field.
>
> "Semantic discovery" cannot be undertaken lightly.  Entire computing 
> fields of study are devoted to this concept.  I subscribe to the Topic 
> Maps way of expressing the relationships between concepts (from which 
> one can infer the semantics).  There happens to be an XML 
> serialization of a Topic Map (and I was on the original committee for 
> this).  If I have two genericode files and there is a column of 
> value-level metadata with a PSI in it and the two PSIs are the same, I 
> could assume the values represent the same semantic.  If the two PSIs 
> are not the same URI, then I need something like a Topic Map to tell 
> me the two different PSI's represent the same concept.
>
> It can't be magic.
>
> And I'm not trying to be flippant, I'm just saying that genericode is 
> a simple serialization of a conceptual sparse-table model.  You could, 
> perhaps, have one genericode file point to the URI of another 
> genericode file and try to infer relationships of some kind by making 
> a graph of genericode files, but I think that is going too far.
>
> I don't think this means genericode is faulty!  Genericode simply 
> meets the need of associating metadata with a list of codes and 
> associating metadata with individual codes in that list.  Full stop.  
> What the metadata is for the codes is up to you.  What that metadata 
> content means is up to you.  When you adopt interpretations that are 
> internationally standardized, then you will have interoperability with 
> other parties that made that same adoption of the international values.
>
> When dealing in a realm where there are no such international values, 
> then you have to come up with a way of identifying the semantics.  A 
> PSI to a human description makes sense to me.  Using that PSI in a 
> Topic Map and relating the concept to other concepts could help a 
> program identify the role of the concept without a human being 
> involved.  But that is a much bigger topic than genericode and CVA.
>
> Have you heard of RDDL?  Resource Directory Description Language:   
> http://rddl.org  I subscribe to using RDDL to encode machine readable 
> information in XHTML human readable documents.  You might find using 
> RDDL in the XHTML document at the URI of your PSI may give your 
> program more information to work with without going all the way to 
> using Topic Maps.
>
> I hope this helps.  Please continue to ask questions if I haven't made 
> myself clear.
>
> . . . . . . . . . . . . . Ken
>
> -- 
> Contact us for world-wide XML consulting & instructor-led training
> Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/c/
> G. Ken Holman                 mailto:gkholman@CraneSoftwrights.com
> Legal business disclaimers:  http://www.CraneSoftwrights.com/legal
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: clr-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: clr-dev-help@lists.oasis-open.org
>
>