RE: External ID draft

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

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
>