Re: [tdwg-tapir] GUID support in TAPIR (or BioCASe)
Ricardo, I agree to Renatos explanations. Just wanted to add that a basic LSID resolving service shouldnt be hard to add to PyWrapper. From what I understand from LSIDs its just an additional WSDL pointing to the http-get based URL resolution eplained by renato below. But providers would have to take care of creating and storing LSID within their existing databases.
And conversion of named parameters into positional ones will be added to pywrapper easily and for sure - just because they look nicer.
-- Markus
-----Ursprüngliche Nachricht----- Von: tdwg-tapir-bounces@lists.tdwg.org [mailto:tdwg-tapir-bounces@lists.tdwg.org] Im Auftrag von Renato De Giovanni Gesendet: Dienstag, 30. Mai 2006 21:38 An: tdwg-tapir@lists.tdwg.org Betreff: Re: [tdwg-tapir] GUID support in TAPIR (or BioCASe)
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
tdwg-tapir mailing list tdwg-tapir@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tapir_lists.tdwg.org
And I would like to add something more:
In PyWrapper you will be able to generate GUIDs based on local IDs. Let me explain...
If you have in our database just a number as your primary key for your specimens you will be able to do this mapping to, for example ABCD UnitGUID:
ABCDunitGUID -> Literal="http://purl.gbif.org/MNCN/specimen/" + myTable.SpecimenID
Therefore the user will be generating GUID without having to modify the local IDs he is using... And that means something realistic that every provider can do.
PyWrapper will accept queries on the ABCDunitGUID, for example, and will handle the decomposition to be able to perform a search using only the ID.
I think this will be a very powerful mechanism for GUID adopters...
Javier.
On 5/31/06, "Döring, Markus" m.doering@bgbm.org wrote:
Ricardo, I agree to Renatos explanations. Just wanted to add that a basic LSID resolving service shouldnt be hard to add to PyWrapper. From what I understand from LSIDs its just an additional WSDL pointing to the http-get based URL resolution eplained by renato below. But providers would have to take care of creating and storing LSID within their existing databases.
And conversion of named parameters into positional ones will be added to pywrapper easily and for sure - just because they look nicer.
-- Markus
-----Ursprüngliche Nachricht----- Von: tdwg-tapir-bounces@lists.tdwg.org [mailto:tdwg-tapir-bounces@lists.tdwg.org] Im Auftrag von Renato De Giovanni Gesendet: Dienstag, 30. Mai 2006 21:38 An: tdwg-tapir@lists.tdwg.org Betreff: Re: [tdwg-tapir] GUID support in TAPIR (or BioCASe)
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
tdwg-tapir mailing list tdwg-tapir@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tapir_lists.tdwg.org
tdwg-tapir mailing list tdwg-tapir@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tapir_lists.tdwg.org
Renato, Markus and Javier,
Thanks so much for all the information. That was exactly what I was looking for!
I'll digest these into my report and will post the results here. That should happen early next week.
Cheers,
Ricardo
Javier de la Torre wrote:
And I would like to add something more:
In PyWrapper you will be able to generate GUIDs based on local IDs. Let me explain...
If you have in our database just a number as your primary key for your specimens you will be able to do this mapping to, for example ABCD UnitGUID:
ABCDunitGUID -> Literal="http://purl.gbif.org/MNCN/specimen/" + myTable.SpecimenID
Therefore the user will be generating GUID without having to modify the local IDs he is using... And that means something realistic that every provider can do.
PyWrapper will accept queries on the ABCDunitGUID, for example, and will handle the decomposition to be able to perform a search using only the ID.
I think this will be a very powerful mechanism for GUID adopters...
Javier.
On 5/31/06, "Döring, Markus" m.doering@bgbm.org wrote:
Ricardo, I agree to Renatos explanations. Just wanted to add that a basic LSID resolving service shouldnt be hard to add to PyWrapper. From what I understand from LSIDs its just an additional WSDL pointing to the http-get based URL resolution eplained by renato below. But providers would have to take care of creating and storing LSID within their existing databases.
And conversion of named parameters into positional ones will be added to pywrapper easily and for sure - just because they look nicer.
-- Markus
-----Ursprüngliche Nachricht----- Von: tdwg-tapir-bounces@lists.tdwg.org [mailto:tdwg-tapir-bounces@lists.tdwg.org] Im Auftrag von Renato De Giovanni Gesendet: Dienstag, 30. Mai 2006 21:38 An: tdwg-tapir@lists.tdwg.org Betreff: Re: [tdwg-tapir] GUID support in TAPIR (or BioCASe)
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
tdwg-tapir mailing list tdwg-tapir@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tapir_lists.tdwg.org
tdwg-tapir mailing list tdwg-tapir@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tapir_lists.tdwg.org
tdwg-tapir mailing list tdwg-tapir@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tapir_lists.tdwg.org
participants (3)
-
"Döring, Markus" -
Javier de la Torre -
Ricardo Scachetti Pereira