RE: External ID draft

["Miller, Robert (GXS)" <Robert.Miller@gxs.ge.com>]

Sandy,

I support your position, but ... 

I don't expect that will make the May ebXML specifications.  And I have
concern regarding many of the ebXML specifications that will likely be
approved in May.  Unresolved issues and requirement shortfalls may be swept
under the rug as the documents are almost unanimously approved.  Will the
work proceed on to a version 2 that addresses these issues and shortcomings?
Unless the specifications prove totally useless or unworkable, I doubt it.
Of course, implementors of ebXML services might view the shortfalls as
opportunities to provide added value to their product suites, albeit in a
proprietary fashion.

Cheers,
         Bob Miller

-----Original Message-----
From: Sandy Klausner [mailto:klausner@coretalk.net]
Sent: Monday, March 12, 2001 12:35 PM
To: Miller, Robert (GXS); ebxml-regrep@lists.ebxml.org
Subject: Re: External ID draft


Bob:
Sad, but true, but the least common denominator rule has been applied to the
ebXML specifications to date. What I am advocating is a robust ontological
architecture based upon general systems modeling technology that would
enable extensible service offerings capable of growing organically. Without
such advanced technology adoption, ebXML will only achieve a fraction of the
potential and usefulness to the global community.
Sandy

> From: "Miller, Robert (GXS)" <Robert.Miller@gxs.ge.com>
> Date: Mon, 12 Mar 2001 13:04:32 -0500
> To: ebxml-regrep@lists.ebxml.org
> Subject: RE: External ID draft
> 
> Sandy,
> 
> I'm not sure I understand how your comments relate to my own.
> 
> Nor do I understand your comments regarding the separation of registry and
> repository functions.  Perhaps that's because I haven't been following R&R
> as closely as I had been.  In the early days of R&R, I argued very clearly
> for the separation of Registry and Repository.  In fact, I suggested that
a
> Repository was approximately the network equivalent to a logical file
system
> on a typical computer.  In computing systems, there is typically a single
> logical file system, dispersed across a set of (pseudo-) devices (E.g.,
UNIX
> Network File System (NFS)) The logical file system doesn't know much about
> what is stored within it  It provides create/read/write/delete services
via
> a logical identifier, and may restrict these services by accessor.  In the
> internet equivalent, I suggested that a restricted 'read-only' accessor
> might simply be provided a URI to the stored information.
> 
> I agree that the syntax and semantics of data stored in a Repository must
be
> made available.  This is 'metadata' related to the data stored in the
> Repository, and so would properly reside in the Registry. For Core
> Components, that means the Registry would need to store such things as
> Ownership, Version, Pointer to XML Schema (or to whatever is used to
define
> the syntax and semantics of the stored data, and other sundry information
> like dates, status, access constraints, etc.  Whether a set of Core
> Components is stroed as one Repository entry or as several Repository
> entriies should not be of particular interest to the Registry.  A
> Registration Submitter may find it desirable to request some sort of index
> to the data stored in the Repository (an Ontology).  To do so, it needs to
> know what information is to be extracted/derived from the data as it is
> stored, and how to extract/derive it.  That could be provided in a generic
> fashion by providing both pointers to both an Ontology Schema and a Data
> Schema, plus any supplemental derivation rules, or it could be provided in
> specific fashion by providing a fixed set of ontologies and derivations.
My
> understanding is that R&R has chosen the latter approach, but has provided
> some minimal form of extension capability to address content such as Core
> Components, which to date have not provided a well defined representation
> structure for the metadata to be stored in the Repository.
> 
> And again, though I am behind on my reading of R&R specifications, it was
my
> understanding that the Query discussions were targeted at least at the
> pre-selected ontologies, and possibly extended to (more expensive) queries
> on the stored data itself.
> 
> Cheers,
> Bob
> 
> -----Original Message-----
> From: Sandy Klausner [mailto:klausner@coretalk.net]
> Sent: Monday, March 12, 2001 10:59 AM
> To: sfuger@AIAG.ORG; Robert.Miller@gxs.ge.com; najmi@east.sun.com;
> Gnosis_@compuserve.com
> Cc: Farrukh.Najmi@Sun.COM; Yutaka.Yoshida@eng.sun.com;
> ebxml-regrep@lists.ebxml.org
> Subject: Re: External ID draft
> 
> 
> Bob, this is too simplistic of a view of the emerging space requirements.
> 
> Users will need to navigate through distributed domain registries to
locate
> specific party and service entries. A domain registry will have to be
> automatically updated from participating party and community repositories.
A
> community is created by parties that maintain services based upon a
> consensus-driven standard for interchange. The ebXML specifications that I
> have reviewed to date are void as to specifying the dimensions of such
> community repository space that is a prerequisite for a truly scalable
> global system. A service is specified as a resource set of well-developed
> meta-data representations. These representations must provide a way of
> perceiving cognitively, and responding to, complex business relationships
> and may become very complex. Not separating the registry from the
repository
> functions is a grave mistake. A domain registry would provide a summary
from
> a set of community repositories for initial discovery purpose. A party
must
> be able to reference a set of community repository resources and offer
these
> as a set of services. Service discovery should be based either on general
> community availability or cross referenced as specific party offerings.
> Alternately, service discovery should be conducted on underlying resource
> ontology. Ontology enables a community to define basic terminology and
model
> shared relationships within a particular domain of discourse and need to
be
> machine interpreted. Ontology search would provide the means to discover
> services based upon navigation of community resource repositories. This
rich
> functionality is too much burden to place on a registry notion alone.
> 
> Sandy
> 
>> From: sfuger@AIAG.ORG
>> Date: Mon, 12 Mar 2001 11:23:10 -0500
>> To: Robert.Miller@gxs.ge.com, najmi@east.sun.com, Gnosis_@compuserve.com
>> Cc: Farrukh.Najmi@Sun.COM, Yutaka.Yoshida@eng.sun.com,
>> ebxml-regrep@lists.ebxml.org
>> Subject: RE: External ID draft
>> 
>> Thank you for this insight, Bob. It is nice to have more light than heat
>> directed upon this subject.
>> 
>> Sally
>> 
>> -----Original Message-----
>> From: Miller, Robert (GXS) [mailto:Robert.Miller@gxs.ge.com]
>> Sent: Monday, March 12, 2001 10:56 AM
>> To: Farrukh Najmi; David RR Webber
>> Cc: Farrukh Najmi; Yutaka Yoshida; ebxml-regrep@lists.ebxml.org
>> Subject: RE: External ID draft
>> 
>> 
>> Good People,
>> 
>> As some folks have keenly observed, the Repository is where the 'data' is
>> stored.  The Registry is where the metadata about the data is stored.
But
>> in this thread, no one has observed that the 'data' may be metadata (in
>> which case the metadata is meta-metadata.)
>> 
>> Now if a Core Component is stored in the Registry as metadata, what's
left
>> to store in the Repository?  'Nothing' comes to my mind.  And if
'nothing'
>> is stored in the Repository, and the Registry is storing the metadata
> about
>> the data in the Repository, we have "Much Ado About Nothing".  While this
>> might please the theater going crowd, it doesn't please the system
>> architect.
>> 
>> Cheers,
>> Bob Miller
>> 
>> ------------------------------------------------------------------
>> To unsubscribe from this elist send a message with the single word
>> "unsubscribe" in the body to: ebxml-regrep-request@lists.ebxml.org
>> 
>> ------------------------------------------------------------------
>> To unsubscribe from this elist send a message with the single word
>> "unsubscribe" in the body to: ebxml-regrep-request@lists.ebxml.org
>> 
> 
> 
> 
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-regrep-request@lists.ebxml.org
>