Just a few comments with respect to naming distributed things. If you look at the problem outside of any current addressing scheme and first address referential integrity of the distributed set, you can think of the following: If you would like to distribute or make copies of the same thing to multiple places, and make it both relevant and irrelevant as to copy you are working with, each distributed "object" needs a unique id to identify itself from other copies in the distributed set, and each copy needs to contain the same unique id representing the distributed set from which it belongs. Then the action of a discovery or addressing service to find one of the objects needs to account for methods to: 1.) find the "best [nearest, cleanest, best performing, most complete, most in sync, etc.]" object by distributed set, or 2.) find a particular object copy/replica/cache by unique object id. Pete -----Original Message----- From: owner-ogsa-d-wg@ggf.org [mailto:owner-ogsa-d-wg@ggf.org] On Behalf Of Michael Behrens Sent: Wednesday, December 14, 2005 10:25 PM To: Stephen Davey Cc: ogsa-d-wg@ggf.org Subject: Re: [ogsa-d-wg] what needs naming in the Data Architecture I find this helpful....especially when considering caches as mentioned below ( cacheing came up in the other telecon tonight too). I presume that binding needs to be done by something other than the user of the named thing, so that cached values can be used. Is the basic goal to be able to name anything, stick it in the virtual grid ethernet storage container, and ask for it later using that name from anyplace and get it (perhaps from a cache, perhaps not)? Meaning is the name might also usable as a static reference? Stephen Davey wrote:
Hi everyone, As part of the RNS & GFS discussion today I wonder if it would be useful to think of all the things in the data architecture that might need naming, and then to check that these would be covered by the 2 specs. Below is my list of all things vaguely data related that I could think of.
Is it planned to also discuss the Naming section (3.2) of the Data Architecture document?
Cheers, Stephen.
caches containers (of resources) data bytes data streams database tables databases defaults digital libraries endpoint references (EPRs) file directories file locations files identities languages locales metadata namespaces naming schemes networks people policies properties queries query result row sets references registries replicas repositories resource locations resources roles schema schema mappings services storage (space) transactions transformations transport protocols user defined entities vocabularies workflows
--------------------------------------------------------- Stephen Davey, NextGrid Software Architect, National e-Science Centre, 15 South College St., Edinburgh, EH8 9AA, UK Tel: +44 131 6 509820
-- Michael Behrens, R2AD, LLC