OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-core message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: ebXML Entity Classes - Resend


Bob,
Perhaps vocabulary is the wrong word, although we are talking about
semantics.  In statistics we use classifications, including a classification
of concepts or "terms".  It means that instead of the tags giving the
semantic meaning,  this is held in a metadata database used by the
application (you have to hold the semantic somewhere).  And, oh yes, we also
have ways of exchnaging these semantics.  It's a well trodden road in the
statistical domain.  Anyway, I wasn't proposing that this should be adopted
as the solution to all problems, merely commenting that if that is what you
want, then it has been/is being done.

Regards,
Chris
----- Original Message -----
From: "Miller, Robert (GXS)" <Robert.Miller@gxs.ge.com>
To: "Chris Nelson" <chris@cnelson.demon.co.uk>; <ebxml-core@lists.ebxml.org>
Sent: Monday, March 05, 2001 11:23 PM
Subject: RE: ebXML Entity Classes - Resend


> Chris,
>
> <sentence>
>   <subject/>
>   <verb>thank</verb>
>   <object>you</object>
> </sentence>
>
> Or put another way, <thank/><you/>
>
> I prefer the second XML representation of 'thank you' to the first, though
I
> do appreciate the flexibility inherit in the first representation.  Each
> form has advantages and disadvantages, which lead to the selection of one
> over another in certain applications.
>
> I do not envision so compressed a vocabulary as you provide in your
> statistics example.  I have observed that some early attempts to use XML
to
> convey business documents tried the limited vocabulary approach only to
> abandon it in later attempts.  RosettaNet is one such example. It came to
me
> as no surprise that the restricted vocabulary approach was abandoned.  In
my
> EDI application experience, the scales are tilted to a rich vocabulary as
> the more workable choice.
>
> Most programming languages implement a compressed vocabulary.  They
> generally address a broad range of needs which emanate from a few general
> requirements.
>
> Business transactions tend to address very specific needs across a broad
> range of end user and context requirements.
>
> I believe I prefer "<thank/><you/>" to the other construct because
> conversation addresses specific needs across a wide context range.  Of
> course, it could just be that I'm not fond of typing!
>
>
> Cheers,
>         Bob
>
>
> -----Original Message-----
> From: Chris Nelson [mailto:chris@cnelson.demon.co.uk]
> Sent: Monday, March 05, 2001 12:04 PM
> To: ebxml-core@lists.ebxml.org
> Subject: Re: ebXML Entity Classes - Resend
>
>
> JohnMcClure or Robert Miller (Ican't work out who) wrote
>
> <I envision a future where the X12 and UN/CEFACT dictionaries give way to
a
> single global encyclopedia of information objects, defined not in teram of
> some given syntax, but rather in terms of their semantic meaning,
> interrelationships, and defining processes supporting those
> interrelationships. I know that dream is a long way from fulfillment.  Yet
I
> also know our understanding of business processes and the data which drive
> and control them has advanced remarkably in the short period of time
> represented as the computer generation.  I certainly believe my dream will
> be fulfilled in this century, and really expect it to happen within the
> first half of this century.  That's still a long time, and well exceeds my
> life expectancy.  But it is absolutely a dream that is within reach of
those
> now entering the profession./>
>
> The statistical domain are working on this right now (and for
> multi-dimesional data they solved it 6 years ago).  Consider that we have
to
> collect data about almost everything and be able to validate it.  We do
> this, not with thousands of XML elements, but with a model which has
classes
> such a "Concept", "Variable", "CodeList" "Structure" etc.  With this, you
> can describe most (perhaps all) "documents".  Of course, the domain has to
> agree on a vocabulary, so you don't get away without any hard work in the
> harmonisation world.  But you do avoid developing a DTD for every document
> (or, in statistics case, every questionnaire or multi-dimensional
dataset).
>
> Anyway, back to ebXML, and I think you will find that there will be a core
> set of comonents types, which will be re-used, extended, and renamed as
they
> become specific elements in a document.  This is what the core compoent
> model says.
>
> Chris Nelson
> Dimension EDI



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC