RE: Globally Agreed Definitions for Individual Semantics

[sfuger@AIAG.ORG]

Maybe I'm missing the point of this discussion, but are we talking about the
same situation that caused us to add Shipment Identification Number as a
data element in X12 back in , oh, 1982 I believe, to cover the situation
where one company used bill of lading, another used air waybill number,
etc.?

Sally

-----Original Message-----
From: Miller, Robert (GXS) [mailto:Robert.Miller@gxs.ge.com]
Sent: Thursday, April 05, 2001 9:51 AM
To: ebXML Core
Subject: RE: Globally Agreed Definitions for Individual Semantics


John,

There may be several 'identifiers' for a 'Transport Contract'.  Indeed, in
many EDI docuemnts where identifiers appear, the construct used is a
repeatable 'qualifier,identifier' pair.  Of course, if you look at the
qualifier code list, only a few of the codes might be used in the context of
a 'Transport Contract'.  I suggest that 'identifier' includes attribute
'Code', which constrains the identifier to a specific semantic definition.
If folks insist on XML human readability (I don't!), then one might also
support an attribute 'Codename', where there exists a one-to-one mapping of
Codename to Code, and where each 'Code' provides access to some specific
semantic definition.

Your example might then read:
     
<Document name='TransportContract'>
   <identifier CodeName='Air Waybill Number'>here is the transport contract
reference number</identifier>
</Document>

A 'rich' semantic definition at the end of the 'Air Waybill Number' CodeName
might associate this semantic with the more generic EDIFACT Element 1153
Code 'AHI' Transport Contract Reference Number' and might direct that the
(lossy) transformation of the identifier from XML to EDIFACT be <identifier
CodeName='Air Waybill Number'>123456789</identifier>  ==> ...
+123456789+AHI+ ... where the EDIFACT elements in the transformation are
identified by their position in some specific EDIFACT segment.  Note of
course that this transforamtion is not reversible.  That could be a serious
problem.  It might be resolved by retaining the CodeName in a description
element in EDFIACT, such that the EDIFACT transformation became
...+123456789+AHI+Air Waybill Number+ ... This retains all of the semantic
information, and so supports a reversible transformation (though not
necessarily as simple algorithm in the reverse direction).

An important point to recognize is that, while both 'Air Waybill Number' and
'FedEx Tracking Number' might both be 'transport contract reference
numbers', they do not share the same semantic definition.  If FedEx requires
I supply the FedEx tracking number to obtain information on the whereabouts
of my shipment, I'll get no useful information from FedEx if I provide
instead an air waybill number (from another segment of the shipment journey,
perhaps.)

I recommend caution in making irreversible generalizations of semantic
information.  It may be appropriate in some instances to use a more generic
label, but it not appropriate to do so in all instances.
 
Cheers,
         Bob Miller

-----Original Message-----
From: John McClure [mailto:hypergrove@olympus.net]
Sent: Tuesday, April 03, 2001 6:48 PM
To: William J. Kammerer; ebXML Core
Subject: RE: Globally Agreed Definitions for Individual Semantics


Despite your pejorative yet enjoyable characterization, William, an
important issue is raised: what is ebXML's development methodology for the
standards it is producing?

Let's assume for a moment that 'transport contract reference number' is a
compromise across the spectrum of the actual terms of art in use (such as
Sue cited). It is a totally artificial term of art invented so as to favor
noone's back-end system or front-end form, but be globally acceptable. But,
we might all agree that introducing artificial terms into a
dictionary/vocabulary is a highly questionable approach.  I wouldn't expect
this is being done by ebXML, but it would be nice to be reassured that no
artificial terms are being carried over from ebXML's source documents.

Now assume that 'transport contract reference number' is an actual term that
all parties agree would be fine as a compromise. Then it does belong in the
dictionary. However, I wouldn't then say that there is an element called
"TransportContractReferenceNumber" that all must use. Rather, I'd abstract a
little like so:

<Document name='TransportContract'>
   <identifier>here is the transport contract reference number</identifier>
</Document>

In the metadata-dictionary-that-is-a-repository, yes there would be an entry
for "Transport...Nbr" and there would be all the synonyms being suggested by
you and everyone else. But there would NOT be an XML element created for
this globally-agreed-definition. Creating such an element in the canonical
ebXML namespace yields 1000s-of-XML-elements, when all that is needed is a
single element called <identifier> placed as a child of the XML element
representing the document (resource).

In fact, you may appreciate that the "prepositional genitive" is better said
in a data modelling context to be "positionally genitive," with reference to
attributes of resource-types.

Anyway, that's one of the tricks for avoiding creating lots of MXL elements,
thereby avoiding lots of ebXML documentation, lots of programmer training,
lots of software, lots of hassle. Good for the SME.
Regards,
John

> -----Original Message-----
> From: William J. Kammerer [mailto:wkammerer@foresightcorp.com]
> Sent: Tuesday, April 03, 2001 3:58 PM
> To: ebXML Core
> Subject: Globally Agreed Definitions for Individual Semantics
>
>
> Sue Probert said "Depending on the mode of transportation, the country,
> or countries or the terms of delivery etc. this one piece of semantic
> data [bill of lading number ] can be called many different names e.g.
> airwaybill number, CMR number, railway consignment note etc. etc."
>
> Further, "...there will be only one of these reference numbers per
> consignment and the generic semantic definition could be agreed globally
> as something like 'transport contract reference number' ... We want to
> obtain the best generic globally acceptable name and definition for each
> piece of semantic data and then enable the specification of business
> synonyms..."
>
> Dear Sue:
>
> I agree wholeheartedly.  And I would have thought most folks in
> UN/EDIFACT would agree that we need the "best generic globally
> acceptable name" for an item, though I'm somewhat discouraged how
> they're carrying that on.  For example, take a look at D.E. 1153
> (Reference code qualifier). Actually everyone can take a look - even if
> you don't have EDISIM - by going to
> http://www.unece.org/trade/untdid/d01a/tred/tred1153.htm.  Code value
> "AHI" has a name of "Transport contract reference number," defined
> lucidly as "Reference number of a transport contract."
>
> If the intent was that the Transport contract reference number could be
> used to designate any of a bill of lading, air waybill, CMR waybill, or
> railway consignment note number, then I wish UN/EDIFACT had augmented
> the definition with those synonyms, rather than ridiculously
> regurgitating the name with a clumsy prepositional genitive.  If those
> synonyms (which were probably known at the time "Transport contract
> reference number" was conceived) were available for searching, it
> probably would've made everyone's life easier.
>
> "Jeans of Blue," anyone?


------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: ebxml-core-request@lists.ebxml.org

------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: ebxml-core-request@lists.ebxml.org