[DDI-SRG] URN Resolution Service at Expert Committee Meeting

[Joachim Wackerow]

Arofan,

I copy to TIC, so others can follow.

I see DDI URN resolution as a crucial part of distributed DDI 
applications. Without that nothing will be possible.

Ideally URN resolution should be started with a simple XML OASIS catalog 
file (URN to URL) going to a full blown distributed resolution service 
like DNS. In other words a solution should be scalable, and it can be 
started in a smaller scale.

Local and remote XML catalogs can be used in a way that one is 
delegating some resolution to other catalogs.

Norman Walsh's resolver Java class is a very good start to begin with. 
There is the stable in the Apache distribution (for a long time 
available), and now there is a new version available with a caching 
feature. I think this is pretty much what we need in the current state.

This caching feature can be used locally in an application, but it could 
also be used by a URN resolution service which can be remotely accessed.

I think it is really important that the DDI Alliance is willing to 
provide some kind of URN resolution service, even it is in beta state. I 
see three benefits:
- the service can be used by institutions, which are not able to set up 
a similar service
- the chosen approach can be used elsewhere by another institution
- it is a sign to the community, that the base of distributed DDI 
applications is started

The DDI Alliance should decide to provide some kind of DDI URN 
resolution service. It is not necessary in this state to head for a full 
blown scenario like you described below or like the structure of DNS. As 
I mentioned above I think in the first place a simple server with the 
caching feature of Norman's new resolver would be a sufficient start.

But the important thing is that then the DDI Alliance discussed and 
decided this already. It would be not only a decision that some program 
is written, but that the service is run by the DDI Alliance.

BTW just a thought:
SDMX is used mainly by banks, right? I think in social science with the 
current state of DDI 3.0 we don't need a resolution service which has 
the stability of a service which banks require.

Other thoughts?

Achim

Links:

Norman's article on the "old" resolver:
http://xml.apache.org/commons/components/resolver/resolver-article.html

"old" resolver:
http://xml.apache.org/commons/components/resolver/

Norman's description of the new resolver:
http://norman.walsh.name/2007/02/06/xmlresolver
http://norman.walsh.name/2007/02/09/resolvers
http://norman.walsh.name/2007/02/14/resolvers

new resolver:
https://xmlresolver.dev.java.net/

XML Catalogs
http://www.oasis-open.org/committees/download.php/14809/xml-catalogs.html

OASIS Entity Resolution TC
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=entity



A. Gregory wrote:
> Achim:
> 
> I am a bit confused. What exactly do we see this service doing?
> 
> Is it a Java component which is part of the Foundation Tools? If so, I think
> it is already part of our planning.
> 
> Is it a hosted service, to resolve URNs? If so, then it is more than a
> simple matter of hosting the component: it is in essence the creation and
> operation of a registry, for which our planned component will be only a
> small part. (As you can understand, it is not simply resolving a URN, but
> collecting and storing the locations of the metadata referred to by the
> URNs, which involves registration as well as querying capabilities, and has
> to be managed and maintained over time. For example, information about how
> long a particular resource will reside at a particular URL needs to be
> handled - in essence a contract between a registree and the registry
> operator/owner. These are all familiar issues from SDMX, but they are not
> things we have dicussed in detail within DDI up to now.) And then we have
> service-level agreements between those populating the registry, and those
> who maintain it, to guarantee that it is not full of garbage and to avoid
> legal liability.
> 
> This is a fairly serious piece of software to implement and run (as we know
> from experience) and although I like the idea of doing it, it is an
> operational task which may be difficult to arrange without sufficient
> resources.
> 
> I don't want to make too big a deal out of it, but I just want to make sure
> we are clear on the two very different types of tasks.
> 
> Cheers,
> 
> Arofan
> 
> -----Original Message-----
> From: ddi-srg-bounces at icpsr.umich.edu
> [mailto:ddi-srg-bounces at icpsr.umich.edu] On Behalf Of Joachim Wackerow
> Sent: Wednesday, May 07, 2008 8:21 AM
> To: DDI Technical Implementation Committee
> Subject: [DDI-SRG] URN Resolution Service at Expert Committee Meeting
> 
> The URN resolution service should be discussed at the expert committee 
> meeting.
> 
> We discussed earlier the idea that the DDI Alliance can provide a DDI 
> URN resolution service for institutions which are not able to set up on 
> own service.
> 
> This issue should be discussed and formally decided at the meeting.
> 
> I mentioned this already to Mary. She thinks it can go to the tools topic.
> 
> Pascal:
> You should reserve some time for the URN resolution service at the tools 
> topic. Do you have already ideas how the service can set up and which 
> resources would be necessary, that the DDI Alliance is able to do this?
> 
> Achim
> _______________________________________________
> DDI-SRG mailing list
> DDI-SRG at icpsr.umich.edu
> http://www.icpsr.umich.edu/mailman/listinfo/ddi-srg
>