[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl-dev] UBL Schema Documentation
I'd even suggest a cool way to do this would be to look for an existing or create afresh a new ontology for paper business document components (Invoice Date, Taxpoint Date, Order Line, Backorder Quantity, etc), semantics and teminology. Then an alignment ontology could be made with the METU / OASIS SET TC ontology, say to align / map the classes, etc. Best regards Steve --- Stephen D Green On 8 February 2010 10:53, Stephen Green <stephengreenubl@gmail.com> wrote: > What is really lacking to date with the UBL standard (as anticipated > all along, I think) is a standard mapping to the paper equivalents of > each of the UBL elements. The same could be (and has been) done > for the EDI equivalents but the semantics for UBL might be closer to > paper equivalent documents (invoices, etc) than to EDI equivalents. > > Best regards > > Steve > --- > Stephen D Green > > > > > On 8 February 2010 10:15, Stephen Green <stephengreenubl@gmail.com> wrote: >> By the way, I don't know if you picked it up from what I just wrote >> but the definitions, CCTS terms and everything necessary, >> apart from an understanding of the CCTS / NRD rules, to read the >> semantics of UBL documents - all this is all found in the standard, >> documented schemas (there are schemas without documentation >> too for runtime use). You don't really need the spreadsheets. But, >> like I say, the element names are in most cases the best guide >> to the semantics once you figure out the order of the qualifiers and >> when you take the parent element names into account too. >> >> Best regards >> >> Steve >> --- >> Stephen D Green >> >> >> >> >> On 8 February 2010 10:05, Stephen Green <stephengreenubl@gmail.com> wrote: >>> It's interesting that the element names are themselves, to >>> a great extent, self-describing. This comes partly from the >>> methodology/algorithm used to determine the names which >>> comes partly from the base standard implemented - 'CCTS' >>> - and partly from the design methodology used to name the >>> CCTS terms and qualifiers and partly from the naming and >>> design rules which turn these term and qualifier names into >>> element names. This ability for names of elements in XML >>> to describe their own semantics could do with more mention >>> when people talk about semantics and XML. It is highlighted >>> by the fact that many of the 'definitions' of element names of >>> UBL elements do little more than turn the components of the >>> name and the name components of the parent element into >>> a simple sentence or partial sentence. >>> >>> e.g. >>> element name: >>> "DespatchAdviceTypeCode" >>> >>> 'definition': >>> "Identifies the type of the Despatch Advice." >>> all this has done is change the word "code" to what semantically >>> amounts to almost a synonym "identifier" (although it would have >>> been more accurate to keep it as "code" which is different in that >>> it has a codelist associated with it) and rearranges the components >>> of the element name into a partial sentence (a predicate in this case). >>> >>> If the 'definition' had been "Codifies the type of the Despatch Advice." >>> or "Code for the type of the Despatch Advice." there would be no more >>> semantics in the definition except to adjust the element name a little >>> for better human readability. One could argue that the element name >>> has more semantic information and is less vague and less ambiguous >>> than the definition in that it's structure obeys rules which add and more >>> clearly express the semantics than does a prose, human readable >>> sentence or predicate. When people create ontologies for the semantics >>> of UBL what they seem to do is use the CCTS components used to >>> make the element name and express those using an ontology then say >>> that they have 'defined' the semantics. They haven't done more than >>> rearrange the element name components according to ontology rules. >>> >>> So in short, reading the 'definitions' may in many cases be no better >>> or even worse than interpreting the element name with reference to >>> how that name is composed and to the name of the parent (or better >>> still the 'dictionary entry name' but that is found together with the >>> 'definition' anyway). So reading the documented schema where all these >>> are found is not necessarily going to tell you a lot more than just 'reading' >>> a UBL instance. In some cases it might confuse as when the 'definition' >>> varies somewhat from the element name (as with the example above). >>> >>> I rant :-) >>> >>> Best regards >>> >>> Steve >>> --- >>> Stephen D Green >>> >>> >>> >>> >>> On 8 February 2010 08:30, Mikkel Hippe Brun <mhb@tradeshift.com> wrote: >>>> Jan - don't know if someone else has answered you. You can find >>>> descriptions in in spreadsheets located in the UBL/mod/common and >>>> UBL/mod/maindoc folders of the download from the OASIS-site. >>>> >>>> Best regards >>>> Mikkel >>>> >>>> 2010/2/8 Šarūnas Jončas <s.joncas@simpleubl.com>: >>>>> In addition to all the official documentation you can try looking at our >>>>> modules API (http://www.simpleubl.com/api/) which describes each UBL 2.0 >>>>> document and it's field. >>>>> >>>>> Best regards, >>>>> >>>>> Sarunas >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Jan Algermissen [mailto:algermissen1971@mac.com] >>>>> Sent: Wednesday, February 03, 2010 12:53 PM >>>>> To: ubl-dev@lists.oasis-open.org >>>>> Subject: [ubl-dev] UBL Schema Documentation >>>>> >>>>> Hi, >>>>> >>>>> sorry if this has come up before, but I am really unable to find what I am >>>>> looking for: >>>>> >>>>> Can anyone point me to the documentation of the UBL XML schemas? What I am >>>>> looking for is a document that explains what each element means. >>>>> >>>>> Jan >>>>> >>>>> >>>>> >>>>> >>>>> ----------------------------------- >>>>> Jan Algermissen, Consultant >>>>> NORD Software Consulting >>>>> >>>>> Mail: algermissen@acm.org >>>>> Blog: http://www.nordsc.com/blog/ >>>>> Work: http://www.nordsc.com/ >>>>> ----------------------------------- >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org >>>>> For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org >>>>> For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org >>>>> >>>>> >>>> >>>> >>>> >>>> -- >>>> Best regards, >>>> Mikkel >>>> >>>> Mikkel Hippe Brun >>>> Chief Technology Officer, Cofounder >>>> >>>> Voice: +45 3118 9102 >>>> Skype: hippebrun >>>> Twitter: @hippebrun @tradeshift >>>> Mail: mhb@tradeshift.com >>>> Web: http://tradeshift.com >>>> >>>> Tradeshift Network Ltd / 37 Friars Avenue / London / N20 0XG / UK >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org >>>> For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org >>>> >>>> >>> >> >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]