Re: [ubl-comment] Question about the BusinessCard object

["Gerard Clancy" <Ger.Clancy@ie.ibm.com>]

Hi All, 

After meeting with Ken this week in
Barcelona, I wanted to point out the work that Philip and I have done over
the past 3 years in scoping and delivering the PEPPOL Directory Business
Card, which is now live at the address below...
Currently PEPPOL Directory is only supported
by the following SMPs UK NHS (Invinet), BRZ, IBM, but we have committments
that Difi will be connecting ELMA in the short, term as well as the Italian
Intercenter SMP.
With the 150k French Endpoints soon
to arrive to the PEPPOL SML, we hope they will soon adopt PEPPOL Directory,
and we've also had positive discussions with Australia about boarding their
data.
         
It may still be some time before I get
full member access on Oasis, so I hope this meas of adding comments is
ok in the meantime

Cheers
Ger

directory.peppol.eu.

https://www.ibm.com/blogs/peppol-by-ibm/peppol-directory-deployment-approved/

with kind regards

Ger Clancy
Offering Manager eInvoicing & PEPPOL
IBM Watson Customer Engagement

Mobile:+353 86 859 6872 E-mail: Ger.Clancy@ie.ibm.com My IBM Homepage: ibm.biz/GerClancy Chat:ger.clancy72 Find me on:

IBM Ireland Limited
Registered in Ireland with no.: 16226
Registered Office: IBM House, Shelbourne Road, Ballsbridge, Dublin 4, Ireland

From:      
 David Goodenough <david.goodenough@broadwellmanor.co.uk>
To:      
 ubl-comment@lists.oasis-open.org
Date:      
 11/10/2017 18:04
Subject:    
   Re: [ubl-comment]
Question about the BusinessCard object

---

Comments inline, not sure how readable this will be, if
you can not tell what I have added please let me know. My mail client handles
text embedded conversations well, but rich text ones (like this one) seem
badly handled.
 
David
 
On Tuesday, 10 October 2017 19:57:04 BST JAVEST by Roberto
Cisternino wrote:
Il 10/10/2017 11:09, David Goodenough ha scritto:
Roberto, 
Thank you for your reply. But I still do not understand.
You say that the Business Card is intended as the electronic
version of the 
paper equivalent, but then later you say that the recipient
is required. 
You have a basic bootstrap problem here. How do you get
the receipient 
Party data? Surely if the Business Card followed its paper
equivalent 
then it would be destination agnostic. And removing the
recipient in no 
way stops it being forwarded. You already have the separation
between the 
sender and the business parties. 
I understand your point, but the UBL-BusinessCard is not
only a card, it is primarly a message.
 
If it primarily a message, what the receiver do with it,
and how would they reply?

I think any UBL business document has a sender and a recipient, as we are
supporting business processes and collaborations so the minimum number
of parties involved is 2, do you agree ?
 
Why exclude the concept (as defined in its purpose description)
of a broadcast object which can be sent to anyone without tailoring. Such
broadcast objects have a real use in such cases as starting the whole communications
system.

Most UBL documents are requiring both the sender and the recipient parties,
not all... but this is when we must give more freedom to implementers.
If you think that we must give such freedom I could agree, but this means
you think implementers may use the UBL-BusinessCard for storage and not
*only* for exchanging its information.
 
I see to need to include the recipient data in a broadcast
object.

I like this idea, after all XML databases are a reality, so it could be
that modern portals, yellow pages or business directories will adopt the
UBL-BusinessCard as a direct storage unit on the file system or in a database
blob.

The recipient will be added on the last stage before sending it to other
parties.
 
How can the recipient be added when downloading it from
a web site or from a QR code printed in a physical directory? Or are you
saying that I would have to fill in all my Party data in order to download
the BusinessCard froma web site? This would an error prone process and
rather defeats one of the driving features of UBL which is to eliminate
duplicate typing. I could not upload my pre-populated BusinessCard because
it would not have a receipient Party in it.
You say "The recipient is mandatory ... because it
is intended to be 
exchanged". Yes quite often when you hand out business
cards you get 
one back, but not always and the cards that are handed
over are not marked 
for the recipient in any way. The same goes for directories,
they do not 
contain (or at least they do not have to contain) the
recipient's 
Party data. 
When it comes to the digital collaboration object, these
are absolutely 
fundamental to UBL and saying that the DigitalCapabilities
object is the way 
to exchange this misses the point. How can you send the
DigitalCapabilities 
object to someone when you do not know where to send it?
It is a recursive 
unresolvable problem. 
First of all I fix the name that is singular "UBL-DigitalCapability",
my mistake on the previous mail.

There has to be a way to start the communications, and
traditionally that is 
what the business card or directory entry do and they
are broadcast objects 
not directed to a particular recipient. 
To my eyes the text in section 2.3.8.2 is exactly correct,
and it is the 
implementation of the BusinessCard object that is wrong.
And it as you 
suggest the second paragraph of section 2.3.8.2 should
not be in the 
description of the BusinessCard but rather in the DigitalCapabilities
section, why is it there? 
BusinessCard should not be mixed with the DigitalCollaboration,
the second one is strictly for configuring EDI systems.
 
Perhaps not, but it is needed as part of the process of
introducing two businesses to each other, at at least it could be used
to good effect if it were a broadcast object.

I agree the folowing is wrong and needs to be revised asap:

>2.3.8.2 Business Card
>The Business Card allows a standardized
way of presenting digital trading capability information in a form that
can be published or >exchanged with trading partners.
>The data structures have been derived
from the work of ebXML CPPP, OpenPEPPOL and other directory services initiatives.
It should be:

"The Business Card allows a standardized way of presenting general
trading capability information as well as main company's communication
channels and presentations such as flyers and brochures."
____
The DigitalAgreement part is ok but there is a missing paragraph for the
DigitalCapability document.
Please review this:
2.3.8.3 Digital Capability
The Digital Capability allows a standardized
way of presenting digital trading capability information in a form that
can be published or exchanged with trading partners.  The digital
capabilities of business partners are the source for building a Digital
Agreement.
2.3.8.4 Digital Agreement  (...I
JUST RENUMBERED THIS...)
Bi-lateral and multi-lateral trading partner
agreements can make use of the standardized Digital Agreement document
used to support business parties agreeing on a set of digital processes,
terms and conditions. 
If the BusinessCard object is not designed to start the
communications, 
then what is and why is it not part of UBL? If the BusinessCard
object 
is not there as a broadcast object to start the process,
what is its 
purpose? From your description the process starts at the
DigitalCapabilities 
object, the BusinessCard is useless and thus should be
removed from the 
standard. 
It is true that in the specification there is a missing
graph overview for the BusinessCard document, while the graph for the Digital
Agreement and Digital Capability is correct.

The BusinessCard is more generic and related to the common practice of
exchanging business information in different domains:
- Marketing and communication (Web sites, social channels, ...)
- Financial Information (e.g. When I want communicate my new Banking account
to my partners)
- General information (Address, Tax IDs, so on...)
- Trading capabilities (What the company do in textual form)

Of course it is intended also to introduce a company to another, but it
is not specific for digital processes.

The DigitalCapability is specific for service providers, EDI partners,
and of course for building digital agreements.
The communication can be started with a plain BusinessCard or directly
using a DigitalCapability if the purpose is to start a digital collaboration.
 
Not at all sure this makes sense. The whole point of UBL
is to make as many parts of business interaction digital, it is the definition
of how that digital interaction should occur and how the dataflows should
be structured. Why is UBL defining a non-digital object? The useful thing
to do is to use the Business Card concept and extend it into the digital
world and the concept is to broadcast information. 
 
David
David 
On Tuesday, 10 October 2017 00:11:21 BST JAVEST by Roberto
Cisternino wrote: 
Hello David, sorry for waiting so long before providing
an answer, I was unable to work fro a while... please find below my answers:
Il 29/09/2017 16:26, David Goodenough ha scritto: 
The business card (as in a piece of card printed with
contact details) 
is generally a mass produced object, handed out to whoever
wants one 
with no tailoring to the receiver. It is entirely one-sided,
i.e. it 
only contains the details of one business/person/organization.
Other 
sources of similar information would be the headed note
paper and 
trade or postal directories. 
Correct, this reason the UBL BusinessCard is not intended
for instructing EDI / B2B systems. Inside it you can provide Business capabilities
in general but not Digital capabilities. The Business Card is intended
as a standard electronic version of the paper one, that can be also used
for exchanging data between business directories or simple yellow pages
systems, accounting or banking systems. 
In order to start a UBL conversation it is necessary for
the initiating 
party to obtain the Party details of the receiving party,
but there seems 
to be no high level object that can be send just describing
one Party. 
These might be printed as QR codes on real business cards
or headed 
notepaper, or made available for download on a web site.
Once you have the partner Party details then the DigitalCapabilities
and DigitalAgreement conversation can happen, and these
can also be 
used to update Party information should the need arise.
The UBL DigitalCapabilities are the document you need,
this is exactly designed to exchange digital capabilities such as plain
old EDI or new XML capabilities. 
So my question is why the BusinessCard has a mandatory
ReceiverParty 
in it, and why it does not have a DigitalCollaboration
object? I 
am here looking for a rational or definition objectives.
It was 
presumably added for a good reason/purpose, is that documented
anywhere? 
The Recipient is mandatory because of course the UBL BusinessCard
is intended to be exchanged (e.g. to a provider, bank, partner, ...) In
case the Recipient acts on behalf of another party you can use the BusinessParty
information accordingly. 
The UBL 2.2 Draft says:- 
>>> 
2.3.8.2 Business Card 
The Business Card allows a standardized way of presenting
digital trading 
capability information in a form that can be published
or exchanged with 
trading partners. 
Yes, this seems to be uncorrect, I would remove the term
"digital" in the beginning. The only way to describe digital
trading capabilities within the UBL BusinessCard is by using textual description.
The data structures have been derived from the work of
ebXML CPPP, OpenPEPPOL 
and other directory services initiatives. 
>>> 
Correct, but this should be correlated to the UBL DigitalCapabilities
document. 
It seems to me that is fails on two counts given this
definition, firstly 
the lack of DigitalCollaboration object which would enable
the presentation 
of digital trading capabilities, and secondly that it
can not be published 
to the world, it can only be exchanged with a trading
partner, which should 
not be necessary as if they are already UBL trading partners
both sides must 
already have the Party details for the other and the BusinessCard
object 
makes no provision for update, DigitalCapabilities/DigitalAgreement
does. 
Digital trading capabilities are described in terms of
processes, collaborations and transactions. You must traverse the DigitalProcess
information aggregate. 
Or to put it another way, what is the high level object
that is 
used by a Party to broadcast connection information so
that others 
may request communications with it? I am rather hoping
that this 
is not a piece of paper! 
David 
Let me know if you need further support. Best regards
Roberto Cisternino UBL ITLSC chair