Re: [ubl-pre-award] Minutes of UBL Pre-award SC call 27. May 2016 16.00 CEST

["G. Ken Holman" <gkholman@CraneSoftwrights.com>]

At 2016-05-27 15:44 +0000, Ole Ellerbæk Madsen wrote:
> Minutes of UBL Pre-award SC call 27. May 2016  16.00 CEST
> ...
> We will handle Ontology as UBL Extension.

For the record, the following email is the
supporting material behind the decision noted in
the minutes of the above Pre-award meeting
regarding accommodating the W3C Ontology.

. . . . . . . Ken

Date: Wed, 25 May 2016 13:23:06 -0400
To: Ole Ellerbæk Madsen <olema@digst.dk>
From: "G. Ken Holman" <gkholman@CraneSoftwrights.com>
Subject: Organization identification as an extension
Cc: Oriol Bausà <oriol@invinet.org>

Hi, Ole.  I promised to write up a summary of
Kees's important suggestion regarding using the extension point.

If we consider section 5.10 on page 18 of this
PDF you cited, the legal entities must follow various models found at:

  https://www.w3.org/TR/vocab-org/#overview-of-ontology

The partial example given in section 1.1 of that
ontology document regarding the UK Cabinet Office
is expressed using RDF 1.1 Turtle syntax:

  <http://reference.data.gov.uk/id/department/co>
    rdf:type org:Organization , central-government:Department;
    skos:prefLabel "Cabinet Office" ;
    org:hasUnit
<http://reference.data.gov.uk/id/department/co/unit/cabinet-office-communications>
.

The complete version of that example can be found
on the web in XML syntax at this URI:

  http://reference.data.gov.uk/id/department/co/post/246.xml

No doubt some people will find such a level of
detail useful, and it appears that the European
Commission has decided that they need this to be
in the document information we want to put into a
UBL document.  No doubt there will be many for whom such detail is not needed.

UBL was never meant to solve every detail for
every user.  Rather, we wanted to accommodate
every user by standardizing the bits likely
useful to all users and providing a place for the
bits some users would find necessary for their
specific and unique needs.  That place is the
extension point, whose scaffolding is
standardized for every UBL document, but whose
contents is wholly up to users to agree to use.

Thus, we can meet the requirement for 5.10 by
suggesting the use of UBL standardized bits for
describing a Party to a satisfactory level of
detail needed to distinguish parties for the UBL
semantics, and the use of the extension point to
associate the W3C level of detail of an
organizational description with the UBL Party.

Consider the attached example (which is schema
valid) that is not to be considered definitive,
rather, it is simply illustrative of an approach
that might be built upon to create a complete solution.

<?xml version="1.0" encoding="UTF-8"?>
<Tender
xmlns="urn:oasis:names:specification:ubl:schema:xsd:Tender-2"
xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2"
xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2"
xmlns:ext="urn:oasis:names:specification:ubl:schema:xsd:CommonExtensionComponents-2">
  <ext:UBLExtensions>
   <ext:UBLExtension>
     <ext:ExtensionContent>
       <eco:Organization xmlns:eco="urn:X-EC-Organization">
<result format="linked-data-api" version="0.2"
  href="http://reference.data.gov.uk/2011-09-30/doc/department/co/post/246.xml";>
  <primaryTopic href="http://reference.data.gov.uk/id/department/co/post/246";>
    <reportsTo>
      <item href="http://reference.data.gov.uk/id/department/co/post/38";>
        <reportsTo>
        ...
        </reportsTo>
        ...
      </item>
    </reportsTo>
    ...
  </primaryTopic>
  <extendedMetadataVersion
    href="http://reference.data.gov.uk/2011-09-30/doc/department/co/post/246.xml?_metadata=all%2Cviews%2Cformats%2Cexecution%2Cbindings"/>
  <definition href="http://organogram.data.gov.uk/api#postInDepartment"/>
</result>
       </eco:Organization>
     </ext:ExtensionContent>
   </ext:UBLExtension>
  </ext:UBLExtensions>
  <cbc:ID>abc</cbc:ID>
  <cbc:ContractFolderID>123</cbc:ContractFolderID>
  <cbc:IssueDate>2016-05-25</cbc:IssueDate>
  <cac:TendererParty>
    <cac:PartyIdentification>
      <cbc:ID schemeName="GLN">123456789</cbc:ID>
    </cac:PartyIdentification>
    <cac:PartyIdentification>
      <cbc:ID
schemeName="linked-data-api-result-href">http://reference.data.gov.uk/2011-09-30/doc/department/co/post/246.xml</cbc:ID>
    </cac:PartyIdentification>
  </cac:TendererParty>
  <cac:TenderedProject>
    <cbc:TenderEnvelopeID>789</cbc:TenderEnvelopeID>
  </cac:TenderedProject>
</Tender>

Using this approach, the organization description
can be as simple or as detailed as the user
wishes, without impacting on the UBL essence of a
Party.  In my example I've associated the
extension with the party by identifying the href
attribute of the linked data API result
instance.  It would be unique.  In fact, it could
also be directly dereferenced, but I wouldn't
recommend it for legacy purposes, as you would
want a copy in the instance to be what the
details were when the instance was created.  If
an auditor was asked to always dereference the
URI then he wouldn't know if the contents at the
URI were different when the document was issued.

Not only are we saving the effort of trying to
keep up in UBL with any changes the W3C might
make to its ontology over time, we are keeping it
simple for the vast number of other UBL users who
have no interest in the W3C ontology.

Thanks, again, to Kees for his insights.

. . . . . . . . Ken


--
Check our site for free XML, XSLT, XSL-FO and UBL developer resources |
Streaming hands-on XSLT/XPath 2 training @US$45: http://goo.gl/Dd9qBK |
Crane Softwrights Ltd. _ _ _ _ _ _ http://www.CraneSoftwrights.com/o/ |
G Ken Holman _ _ _ _ _ _ _ _ _ _ mailto:gkholman@CraneSoftwrights.com |
Google+ blog _ _ _ _ _ http://plus.google.com/+GKenHolman-Crane/posts |
Legal business disclaimers: _ _ http://www.CraneSoftwrights.com/legal |


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus