[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl-dev] UBL Schema Documentation
Good point. This helps align EDI with paper. Aligning UBL, etc with UN Layout key (maybe via a UN Layout Key ontology) would help. Still we probably could do with an ontology for all those other paper- based document terms, etc not covered by UN Layout Key. Plus an ontology for UN Layout Key too perhaps. Best regards Steve --- Stephen D Green On 8 February 2010 12:56, Crawford, Mark <mark.crawford@sap.com> wrote: > UN layout key for documents > > Mark Crawford > Standards Architect > GEPG Standards Management and Strategy > SAP Labs > Mobile: (703) 485-5232 > > ----- Original Message ----- > From: Stephen Green <stephengreenubl@gmail.com> > To: ubl-dev@lists.oasis-open.org <ubl-dev@lists.oasis-open.org> > Sent: Mon Feb 08 05:57:48 2010 > 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 >>>>> >>>>> >>>> >>> >> > > --------------------------------------------------------------------- > 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]