Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 5.3

...

Panel

Even though PURLs offer re-direction (even when NCBI finally publishes its own RDF), the URI would remain as purl.org/../ncbi/entrez-23111. Some of us find this troubling, since most users of such data would expect the URI to state clearly it comes from http://ncbi.nlm.nih.govImage Removed or http://ebi.ac.uk/Image Removed . Some of you know this has been a long (and difficult) discussion, and we still have no clear proposal of how to do this. And here is where we have lost momentum-- no clear path forward that most of us would be happy with...

Enter Active Purls: In Eric Miller's SemTech session on "PURLZ", he described a new model for PURLs coming out this summer called Active PURLs. These PURLS are associated with services that are defined the source. I asked him about one specific service: if one starts with a PURL URI to Entrez data converted to RDF by (let's say) the HCLS community, can one include a service to say that if NCBI now has created its own RDF Entrez version with URI, that the PURL should be permanently re-directed to the NCBI location? In other words, can one ask a bunch of PURLs "what are your direct, and permanent URIs to the authoritative source?" Eric's reply seems to suggest this is quite easy to set up..

SO what is gained? Well if you have a large KB with lots of purl.org//ncbi/... records, there would be now a mechanism to replace all these wholesale to the new NCBI URIs. In other words, a global replace of older initial PURLs to proper URIs from authoritative spaces. This seems to make a lot of life science folks asking how to begin working with SW and URIs happy-- a clean and basic transition model can be offered to the community for getting started with SW via Active PURLS.

...

Bill asked whether the group had ruled out consideration of the Handle System at a previous meeting; while we have been moving to think of the resolution service without a set of richer accompanying metadata and services, the Handle service has worked well for eCommons and LSDI.
Bill has wanted to host a mirror of the local Handle server and Mann would be a logical place to do so. He will talk to Chris Manly from DLIT to see when it might be possible for Chris to work with Bill Klinko and John Cline at Mann to do a second installation for redundant resolution of Cornell handles.
A simple Handle record (vanilla configuration, no extra metadata) uses around 100 bytes. Our current Handle server contains 43 thousand Handles. To evaluate the Handle System further it would be helpful to know the memory footprint of a Handle record (Bill?) and to create a test suite to load ~1 million records and conduct load tests on resolution performance.

...