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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-dev message

[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]