info:sid/localhost:CollectionWikiPages:DistributedRegistries info:sid/localhost:CollectionWikiPages CollectionWikiPages http://alcme.oclc.org:80/wikid/search/WikiDb.localhost DistributedRegistries display Wiki Pages userAssigned mailto:jyoung@oclc.org no info:sid/localhost:CollectionSimpleSchemas:wiki info:sid/localhost:CollectionExternalSchemas:xhtml info:sid/localhost:CollectionExternalSchemas:xhtml 1.1 1 ktv3xr 300 http://www.oclc.org/schemas/WikiRepository xml http://alcme.oclc.org:80/wikid/docs/WikiRepository info:sid/localhost:CollectionWikiPages:DistributedRegistries SomeBody CollectionWikiPages 2005/07/21/12 inf_3asid_2flocalhost_3aCollectionWikiPages_3aDistributedRegistries_5f20050721123444255 text/xml CollectionWikiPages:DistributedRegistries 2005-07-21 2005-07-21 1 1.1 repos.hasDate = "hasdate" and oai.identifier exact "info:sid/localhost:CollectionWikiPages:DistributedRegistries" cql.any = huh? 1 1 xml default 2005-07-21 http://alcme.oclc.org:80/wikid/docs/WikiRepository/2005/07/21/12/inf_3asid_2flocalhost_3aCollectionWikiPages_3aDistributedRegistries_5f20050721123444255 Here are my nebulous thoughts and recollections on the recent Distributed Registries Workshop in Warwick (http://www.ukoln.ac.uk/events/dsr-workshop-2005/''''''). BTW, I'm not trying to claim these ideas as my own. This is just a place for me to try to wrap my mind around the problem. ---- Jeremy Frumkin named these as the three roles of a registry: * Discovery * Resolver * Interface info = Discovery = It seems to me that SRU with XSL stylesheet references is ideal for both human and automated discovery. SRW could be appended for die-hard SOAP enthusiasts. We could support Z39.50, if we must. SRW/U allows us to remain agnostic on the question of multiple collections/schemas for describing services. It's not clear to me, though, if discovery is required between nodes in the registry network, or only between a node and its connected applications (e.g. Greasemonkey). If it's the latter only, then registry node implementations could feel free to implement their own discovery protocol using information that gets shared across nodes. OTOH, agreement on a single protocol would allow for maximum client generalization. = Resolver = This is where I think OpenURL 1.0 comes in. The concept of resolution seems very abstract within the domain of registries, and OpenURL 1.0 allows us to fully accommodate that abstraction. Resolution services could be implemented ad hoc, with registry nodes delegating resolver requests they are unfamiliar with. OpenURL 1.0 is built around the concept of context-sensitive services, which also allows us to accommodate the (uncertain) need for authentication between nodes in the distributed registry network. Data sharing between nodes could be achieved via OAI-PMH, which could be coordinated as yet another context-sensitive OpenURL 1.0 service. Nodes could be related via a DNS-type mechanism integrated into the OpenURL 1.0 component. = Interface info = This appears to be a metadata issue and thus independent of the architecture of the network. I don't know anything about UDDI, but I'm guessing this is where the appeal is for it. My impression is that UDDI is a heavyweight solution, so I would like to know more about lightweight alternatives. = Summary = In general, I would like to see a distributed services registry specified in terms of protocols (e.g. OpenURL, SRW/U, and OAI) and schemas rather than tools. There is confusion, in my mind at least, about where we draw the line between the registry and applications and I'd rather not lay on a Procrustean bed, if I don't have to. I need to take a closer look at OCKHAM to see what they're up to. I think WikiD is general-purpose enough that it should be able to serve as one or more nodes in a distributed registry. If OCKHAM is serious about building such a network based on standards, I believe I should be able to configure WikiD to transparently participate into their model of a network as a full-fledged peer. I also see WikiD as a dynamically-configurable client of those same services. As a client, I want the registry to be simple and easy to use. If I can't configure WikiD to act as a node in the registry, I will be inclined to think the model is too complex and difficult. Here are my nebulous thoughts and recollections on the recent Distributed Registries Workshop in Warwick (http://www.ukoln.ac.uk/events/dsr-workshop-2005/).

BTW, I'm not trying to claim these ideas as my own. This is just a place for me to try to wrap my mind around the problem.
Jeremy Frumkin named these as the three roles of a registry:

Discovery

It seems to me that SRU with XSL stylesheet references is ideal for both human and automated discovery. SRW could be appended for die-hard SOAP enthusiasts. We could support Z39.50, if we must. SRW/U allows us to remain agnostic on the question of multiple collections/schemas for describing services. It's not clear to me, though, if discovery is required between nodes in the registry network, or only between a node and its connected applications (e.g. Greasemonkey). If it's the latter only, then registry node implementations could feel free to implement their own discovery protocol using information that gets shared across nodes. OTOH, agreement on a single protocol would allow for maximum client generalization.

Resolver

This is where I think OpenURL 1.0 comes in. The concept of resolution seems very abstract within the domain of registries, and OpenURL 1.0 allows us to fully accommodate that abstraction. Resolution services could be implemented ad hoc, with registry nodes delegating resolver requests they are unfamiliar with. OpenURL 1.0 is built around the concept of context-sensitive services, which also allows us to accommodate the (uncertain) need for authentication between nodes in the distributed registry network. Data sharing between nodes could be achieved via OAI-PMH, which could be coordinated as yet another context-sensitive OpenURL 1.0 service. Nodes could be related via a DNS-type mechanism integrated into the OpenURL 1.0 component.

Interface info

This appears to be a metadata issue and thus independent of the architecture of the network. I don't know anything about UDDI, but I'm guessing this is where the appeal is for it. My impression is that UDDI is a heavyweight solution, so I would like to know more about lightweight alternatives.

Summary

In general, I would like to see a distributed services registry specified in terms of protocols (e.g. OpenURL, SRW/U, and OAI) and schemas rather than tools. There is confusion, in my mind at least, about where we draw the line between the registry and applications and I'd rather not lay on a Procrustean bed, if I don't have to.

I need to take a closer look at OCKHAM to see what they're up to. I think WikiD is general-purpose enough that it should be able to serve as one or more nodes in a distributed registry. If OCKHAM is serious about building such a network based on standards, I believe I should be able to configure WikiD to transparently participate into their model of a network as a full-fledged peer.

I also see WikiD as a dynamically-configurable client of those same services. As a client, I want the registry to be simple and easy to use. If I can't configure WikiD to act as a node in the registry, I will be inclined to think the model is too complex and difficult.