[tdwg-tapir] GUID support in TAPIR (or BioCASe)
Hi folks,
I am preparing an analysis of how existing provider software handle globally unique identifiers. I would like to ask if anyone on the list could give me more details about whether and how TAPIR handles GUIDs. I am also interested in details about how specific implementations of the protocol handle GUIDs (such as the PyWrapper or others).
More specifically, I am looking to answers to the following questions:
1) Does the protocol or the implementation explicitly handle any form Globally Unique Identifiers? Does it adopt a specific technology (DOI, Handle, POI, LSID), or does it provide support for any GUID technology. If so, what are the requirements for using a new technology?
2) Are there any required fields/concepts on the application profiles (ABCD for example) that are specifically designed to accommodate GUIDs?
3) Does the protocol provide any specific resolution mechanism (i.e., returning a single object based on an ID passed on the request)?
4) Any other aspects of the protocol or implementation regarding GUIDs.
I intend to write a white paper on the topic and also give a talk about it during the Second Workshop on Globally Unique Identifiers (GUID-2) next month in Edinburgh. I will post links to the documents once they are published.
Any help is greatly appreciated.
Have a great weekend.
Regards,
Ricardo
PS. Note that did not mention DiGIR, DiGIR2 and Darwin Core on my request above because I am a bit more familiar with them (though information about them is appreciated, too).
Hi Ricardo,
I'll try to answer your questions...
- Does the protocol or the implementation explicitly handle any form
Globally Unique Identifiers? Does it adopt a specific technology (DOI, Handle, POI, LSID), or does it provide support for any GUID technology. If so, what are the requirements for using a new technology?
No, TAPIR doesn't handle those technologies in terms of having any sort of implicit resolution mechanisms or any other specific behaviour. TAPIR can "serve" GUIDs if they are part of a conceptual schema and if providers store the corresponding values in their local databases. However, they will be treated just as simple strings, both in filters and output models.
- Are there any required fields/concepts on the application profiles
(ABCD for example) that are specifically designed to accommodate GUIDs?
As far as I know ABCD has "UnitGUID", "DatasetGUID" and URLs for MultimediaObjects. The new version of DarwinCore has a GlobalUniqueIdentifier concept.
- Does the protocol provide any specific resolution mechanism (i.e.,
returning a single object based on an ID passed on the request)?
TAPIR could work very nicely with PURLs just by making use of standard Web technologies. For instance, ABCD and DarwinCore providers could define a custom search template that would require the catalog number as a parameter and would return an RDF output model for the respective object. In this case, a request could look like:
http://example.net/provider.cgi?op=view&template=someuri&cnum=123
Which could be easily wrapped as a PURL:
So the representation of that object could be retrieved from any browser or from any script using standard HTTP libraries.
Providers would obviously be free to decide about the output model for their objects (an RDF representation, or ABCD, or plain DarwinCore...), and if the template should take an additional parameter for versioning (or maybe the response could just include a changelog), and if it would be desirable to have two different search templates (for data and metadata) and so on.
Resolution of any other kind of GUIDs would require additional software considering only a pure TAPIR implementation. Unless the implementation decides to offer additional services as part of the package.
- Any other aspects of the protocol or implementation regarding GUIDs.
Only minor things like recommending GUIDs to identify "relatedEntities" in TAPIR metadata responses. I guess we will probably recommend PURLs for templates, output models, concepts and conceptual schemas.
Hope this helps...
Best Regards, -- Renato
participants (2)
-
Renato De Giovanni -
Ricardo Scachetti Pereira