[tdwg-tapir] GUID support in TAPIR (or BioCASe)

Ricardo Scachetti Pereira ricardo at tdwg.org
Tue Jun 6 15:46:23 CEST 2006


    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 at 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 at lists.tdwg.org
>>> [mailto:tdwg-tapir-bounces at lists.tdwg.org] Im Auftrag von
>>> Renato De Giovanni
>>> Gesendet: Dienstag, 30. Mai 2006 21:38
>>> An: tdwg-tapir at lists.tdwg.org
>>> Betreff: Re: [tdwg-tapir] GUID support in TAPIR (or BioCASe)
>>>
>>> Hi Ricardo,
>>>
>>> I'll try to answer your 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?
>>>>         
>>> 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.
>>>
>>>       
>>>> 2) 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.
>>>
>>>       
>>>> 3) 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:
>>>
>>> http://purl.org/provider/123
>>>
>>> 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.
>>>
>>>       
>>>> 4) 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 at lists.tdwg.org
>>> http://lists.tdwg.org/mailman/listinfo/tdwg-tapir_lists.tdwg.org
>>>
>>>       
>> _______________________________________________
>> tdwg-tapir mailing list
>> tdwg-tapir at lists.tdwg.org
>> http://lists.tdwg.org/mailman/listinfo/tdwg-tapir_lists.tdwg.org
>>
>>     
>
> _______________________________________________
> tdwg-tapir mailing list
> tdwg-tapir at lists.tdwg.org
> http://lists.tdwg.org/mailman/listinfo/tdwg-tapir_lists.tdwg.org
>
>   





More information about the tdwg-tag mailing list