RE: Globally Agreed Definitions for Individual Semantics

[John McClure <hypergrove@olympus.net>]

Bob,
You are right, and the DCN accommodates three scenarios relating to the
facility you speak of.

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

The 'keyword' facet (a facet being an attribute on a resource-attribute
element) is a qualified-name (qname) that points to a less ambiguous
specification of the information represented by the identifier element. In
this case, the 'AirWaybillNumber' is defined in the datastream's default
dictionary, i.e., that is where the "rich metadata definition" you mentioned
is located. Should a publisher have their own dictionary and or their own
(expanded) definition for the term, then the name can be qualified by a
namespace prefix previously mapped to a URI for their own custom dictionary.

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

The third version uses the 'identifier' facet on the <identifier> element.
This facet allows a publisher to map the element to a column in their
database, for instance.

<Document name='TransportContract'>
    <identifier keyword='AirWaybillNumber' identifier='my:billnbr'>
	here is the transport contract reference number
    </identifier>
</Document>

While not semantically as rich as the other approach, it does provide the
capability for TPA-defined information to be passed in its appropriate
contexts. I also must add that it is certainly ok to have multiple
identifiers associated with the resource!

Hope that helps, and thanks for noting that generalizations can be useless
if inappropriately applied to a solution. I would add that generalizations
fail splendidly if and only if no allowance is made for the specification of
more precise information. The DCN is architected throughout to provide for
more specialized terms than those in the base set of resource-types. That's
the nature of OO design, and one of the reasons I chose RDF Schemas for
representation of metadata information.

John
> -----Original Message-----
> From: Miller, Robert (GXS) [mailto:Robert.Miller@gxs.ge.com]
> Sent: Thursday, April 05, 2001 6: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
>