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

["G. Ken Holman" <gkholman@CraneSoftwrights.com>]

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