[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]
Powered by eList eXpress LLC