RE: Registry object persistence; are BPs owned?

["Hayes, Brian" <Brian.Hayes@Commerceone.com>]

Business Process Ownership:
     I believe the Business Process Identifier Naming Scheme (BPINS),
"supports" aspects of what Jamie has described below.  The naming scheme is
described at
http://lists.ebxml.org/archives/ebxml-regrep/200101/msg00125.html.  Briefly,
the format is:
bpid:<agency>:<agency-id>:<business-process-name>$<major-version-number>.<mi
nor-version-number>
where the <agency>:<agency-id> part identifies the owner of the business
process.
     Of course, using this naming scheme assumes that everyone plays by the
rules -- that is no user can save/change a business process in the business
process registries (more than one!) using an improper <agency>:<agency-id>.

Access Control:
     I believe that a registry/repository should have a certain amount of
access control for a) accessing the registry and b) accessing content.  For
example, I would hope that a company like Commerce One would support a
business process registry at its GlobalTradingWeb.net.  This registry would
allow public access; but, would not allow the general public to see
"private" business processes that are stored in its repositories.

Futures:
     I believe overtime that there will be few private business processes
that don't have a public version (cooked up by someone else -- after all,
there are only so many reasonable ways of doing business).  The exception to
that might be copyrighted or patented processes (is it possible to patent a
collaborative business process?).

/Brian

> -----Original Message-----
> From: James Bryce Clark [mailto:jbc@lawyer.com]
> Sent: Sunday, March 04, 2001 5:58 PM
> To: ebxml-ccbp-analysis@lists.ebxml.org
> Subject: Registry object persistence; are BPs owned?
> 
> 
> [Resending to ccbp-analysis:  it got rejected, I think I botched the
> listserv address.]
> 
> 
> The TP discussion about XML-DSIG hashing into specific 
> business process
> artifacts, and how the transaction breaks if a referenced BP 
> changes or its
> URI dies, is worth mentioning here for other reasons.  
> 
> >> From: Moberg, Dale <Dale_Moberg@stercomm.com>
> >> Sent: Thursday, March 01, 2001 5:51 PM
> >> * * *
> >> That means that never removing process specifications from
> >> from registries has definite CPA lifetime management advantages, 
> >> as well as always pointing to a stable registry provider! And just 
> >> think of how much storage vendors will like this opportunity for 
> >> keeping process specifications forever!
> 
> Hmm.   Archetypal logical business processes should be incapable of
> copyright.   However, implementation guides probably are not 
> -- somebody
> did the sanding to join all those rough inter-implementation 
> edges.  It is
> possible that entities will offer access to proprietary BP patterns or
> components, in a proprietary registry.     
> 
> Here is where we are going, I think:  
> 
> (1)  Owners of BPs incorporated by a URI reference can, by removing or
> changing them at the source location, functionally "turn them off".  
> (2)  Users of BPs are sensitized to their need to either 
>     (a)  use open source BPs and make sure they're backed up,
>     (b)  use BPs they own or can control themselves, or 
>     (c)   rent 'em, so to speak, and understand that their run-time
> validity exists at the sufferance of their modelling "landlord."
> 
> It's a bit jarring to think about a shifting, changing base 
> of IPR-limited
> objects up in the registries.  But in my view this is the natural
> free-market result of the RA and TA saying that ebXML 
> registries MAY, but
> are NOT REQUIRED to, share contents.   
> 
> I'm OK with that, I just want to get it out in the open for 
> discussion.
> The  result is that there will be no permanence or 
> consistency requirements
> imposed (by the standard) on any registry donations,  
> o t h e r  t h a n  the "common business process/core component" seeds
> being cooked up in CC).   Sounds like a different world view 
> than Dale's.
> Everyone OK with this?  
> 
> Jamie
> 
> James Bryce Clark
> Spolin Silverman & Cohen LLP 
> 310 586 2404    jbc@lawyer.com    
> 
>