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 >
Powered by
eList eXpress LLC