ebxml-regrep message


OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

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
> 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC