ATTENDEES: Wendy, Jon, Larry, Oliver, Dan S., Darren, Johan, Carsten (2nd half for URN discussion)
Reviewed changes to agent types, conceptualTextTypes and concepts - spreadsheet should be implemented as listed
Enter these as a set for review, then enter documentation changes to 68 items. Note that 5 items need examples.
Johan - Project Shoc (social sciences and humanities open cloud) to create mapping to other standards and policies for conversion. There is a month and a half to the end of the project. Present to work to TC next week. Contact Flavio who will not be able to attend.
The first choice - is that registering every URN that is created?
Resolving DNS service are just for service resolution an end-point in a port (has been there for a long time)
HTTP service end-points (3 built in web resolution, DDI which is the individual, and set with all related URNs)
No differentiation between global and internal
What services should be operated to support URN resolution
What should be provided by the DDI Alliance
What should be provided by the member agencies
Diagram of URN resolution works (diagram in the SB WG paper)
Need to clarify what is already available
Once you know a URN belongs to DDI you can query DDI Agency Registry
If there is an established resolver used by agency
A service record is only providing an end-point (service and port)
There is nothing saying what type of service is being provided
You'd have to know the common name for the web/URN/verbatim service record and could use the DNS records to look up where those resolves are
Looking of service look-ups is not well supported across the board like by web services
How to come from DDI to the actual object
"N to T" arch id, handles, etc. at California Digital Libraries
This can do "N to T"
Have to know what the
No common resolution but there is a way of figuring out who owns the URN space and linking to the http://registry.ddialliance.org
There is a common system https://registry.ddialiance.org
You need to know the syntax of the DDI URN to proceed to go from ARPA to DDI (the registration in ARPA does that)
Don't want implementers to use that API to resolve everything, but to use that as a means of structuring local tool so that
A load limitation precludes having this available for handling all queries
So what's missing?
Identifier resolution and identifier end point. Individual identifiers can be resolved in terms of a consistent pattern within an agency or sub-agency. Individual variations from the pattern are not supported.
Published content owned by the DDI Alliance (primarily CV's and RDF vocabularies) - Darren and Oliver are completing that
Access to the objects is in the court of the Agency
In the recommendation (1) suggesting that the Alliance would register individual URNs (long paper)?
If a DDI URN is found in the wild the DDI Alliance can direct you to where it is found
That you can get a formal description of service
Individual URNs were not considered an option
There is a template approach (end-point at an agency level) they can provide additional breakdown at the initial endpoint (for example based on knowledge of internal structures)
What the current service does not provide is validation of agency assigned IDs. It is their responsibility to state it is not a valid URN. Even with handle service you have to keep up-to-date with directions
Use case not covered - is the Alliance taking on what is actually the agencies responsibility. The http://registry.ddialliance.org is simply a passthrough.
Is it clear to the agency that this is what they'd have to do.
What about a scenario where someone registers an agency and then deposits it in an archive.
They'd keep their same agency ID and can define their own resolution. You could put the archive as the service for their agency. The resolution service would have to direct it to a differential agencies.
Best Practice around this? If it is a distributed resolution environment and an agency has deposited in several different archives. They need a resolution system to address that.
TC is open to further discussions with Carsten or with the URN Working Group as needed.
My understanding when taking on the lead of the URN TWG of the SB was that only the first step, Consumer<->DNS was working.
I understood our mission to clarify which of the other exchanges in the diagram needed to be implemented by either the Alliance or an Agency.
This is what our discussions on centralised vs decentralised solutions were mostly about.
From Dan's slides from EDDI (https://doi.org/10.5281/zenodo.5747652) I understood as follows:
Slide 8 says that the second step consumer<->registry for SRV records has been available for some time, but I don't know how it works and can't seem to find the documentation.
Slide 11-1&2 allowed me to do the third step consumer<->registry/Agency for the URL of a concrete URN, but Slide 11-3 did only allow me to retrieve the pattern via API, not the specific answer for a given URN.
The final step consumer<->repository is beyond the scope of the URN service.
Did I understand this correctly and where can I find a full documentation of steps two and three to follow end to end?
If I understand correctly, there is no mechanism foreseen to decide whether any URN is valid by the registry, but it would always return a URL that the repository then can't answer. (see screenshot)
I am happy to discuss this also tomorrow afternoon and please do forward this mail to those whom it concerns.