http://fak3r.com/2009/04/29/resolving-lsids-wit-url-resolvers-and-couchdb/ look out honey, 'cause I'm using technology Sat, 11 Feb 2012 04:52:00 +0000 hourly 1 http://fak3r.com/2009/04/29/resolving-lsids-wit-url-resolvers-and-couchdb/#comment-1383 fak3r Wed, 29 Apr 2009 23:48:31 +0000 http://www.fak3r.com/?p=1616#comment-1383 JonathanThe post is here in the mailing list: <a href="http://lists.tdwg.org/pipermail/tdwg-tag/2009-April/000506.html" rel="nofollow">http://lists.tdwg.org/pipermail/tdwg-tag/2009-A...</a> and it was provoked after this thread from Nicky: <a href="http://lists.tdwg.org/pipermail/tdwg-tag/2009-April/000494.html" rel="nofollow">http://lists.tdwg.org/pipermail/tdwg-tag/2009-A...</a> showing the convoluted way things have been working. To me it doesn't sound sustainable, at least not something I'd want to try and sustain. JonathanThe post is here in the mailing list: http://lists.tdwg.org/pipermail/tdwg-tag/2009-A… and it was provoked after this thread from Nicky: http://lists.tdwg.org/pipermail/tdwg-tag/2009-A… showing the convoluted way things have been working. To me it doesn't sound sustainable, at least not something I'd want to try and sustain.

]]> http://fak3r.com/2009/04/29/resolving-lsids-wit-url-resolvers-and-couchdb/#comment-1382 Rod Page Wed, 29 Apr 2009 23:35:05 +0000 http://www.fak3r.com/?p=1616#comment-1382 There's some (perhaps too much) history here, but I guess the arguments have been that DOIs cost money (and we have potentially 100's of millions of things to assign identifiers to ), and PURLs are a bit too close to URLs (i.e., we're used to URLs breaking, even though this is bad). LSIDs also dragged our field kicking and screaming away from XML schema (gack) and towards RDF. The reality is we will need to handle DOIs, LSIDs, and URLs. There's some (perhaps too much) history here, but I guess the arguments have been that DOIs cost money (and we have potentially 100's of millions of things to assign identifiers to ), and PURLs are a bit too close to URLs (i.e., we're used to URLs breaking, even though this is bad). LSIDs also dragged our field kicking and screaming away from XML schema (gack) and towards RDF. The reality is we will need to handle DOIs, LSIDs, and URLs.

]]> http://fak3r.com/2009/04/29/resolving-lsids-wit-url-resolvers-and-couchdb/#comment-1380 Rod Page Wed, 29 Apr 2009 23:31:30 +0000 http://www.fak3r.com/?p=1616#comment-1380 I like this approach. I'm playing with a smaller scale version of this, where the approach is to aggregate RSS feeds, storing associated metadata, and trying to flesh it out (e.g., if the feed contains LSIDs, DOIs, or URLs that lead to machine-readable metadata, these are extracted and metadata added to a central store). I guess the advantage of the kind of approach you're discussing is that in providing robust identifier resolution, we also get a big store of metadata that we can do inference on (and hence yield new connections between disparate facts), which may help make concrete the case for the utility of shared identifiers and vocabularies in the first place. I like this approach. I'm playing with a smaller scale version of this, where the approach is to aggregate RSS feeds, storing associated metadata, and trying to flesh it out (e.g., if the feed contains LSIDs, DOIs, or URLs that lead to machine-readable metadata, these are extracted and metadata added to a central store). I guess the advantage of the kind of approach you're discussing is that in providing robust identifier resolution, we also get a big store of metadata that we can do inference on (and hence yield new connections between disparate facts), which may help make concrete the case for the utility of shared identifiers and vocabularies in the first place.

]]> http://fak3r.com/2009/04/29/resolving-lsids-wit-url-resolvers-and-couchdb/#comment-1381 Jonathan Rochkind Wed, 29 Apr 2009 20:38:36 +0000 http://www.fak3r.com/?p=1616#comment-1381 I don't know the context or history of LSID, but the naive question is, why not use one of the existing identifier schemes? If not DOI itself, why not purl.org? What are your requirements that these things won't do for you? I don't know the context or history of LSID, but the naive question is, why not use one of the existing identifier schemes? If not DOI itself, why not purl.org? What are your requirements that these things won't do for you?

]]> http://fak3r.com/2009/04/29/resolving-lsids-wit-url-resolvers-and-couchdb/#comment-1379 fak3r Wed, 29 Apr 2009 18:48:31 +0000 http://www.fak3r.com/?p=1616#comment-1379 JonathanThe post is here in the mailing list:http://lists.tdwg.org/pipermail/tdwg-tag/2009-April/000506.html and it was provoked after this thread from Nicky: <a href="http://lists.tdwg.org/pipermail/tdwg-tag/2009-April/000494.html" rel="nofollow">http://lists.tdwg.org/pipermail/tdwg-tag/2009-A...</a> showing the convoluted way things have been working. To me it doesn't sound sustainable, at least not something I'd want to try and sustain. JonathanThe post is here in the mailing list:http://lists.tdwg.org/pipermail/tdwg-tag/2009-April/000506.html and it was provoked after this thread from Nicky: http://lists.tdwg.org/pipermail/tdwg-tag/2009-A… showing the convoluted way things have been working. To me it doesn't sound sustainable, at least not something I'd want to try and sustain.

]]> http://fak3r.com/2009/04/29/resolving-lsids-wit-url-resolvers-and-couchdb/#comment-1624 fak3r Wed, 29 Apr 2009 18:48:00 +0000 http://www.fak3r.com/?p=1616#comment-1624 Jonathan The post is here in the mailing list: http://lists.tdwg.org/pipermail/tdwg-tag/2009-April/000506.html and it was provoked after this thread from Nicky: http://lists.tdwg.org/pipermail/tdwg-tag/2009-April/000494.html showing the convoluted way things have been working. To me it doesn't sound sustainable, at least not something I'd want to try and sustain. Jonathan
The post is here in the mailing list: http://lists.tdwg.org/pipermail/tdwg-tag/2009-April/000506.html and it was provoked after this thread from Nicky: http://lists.tdwg.org/pipermail/tdwg-tag/2009-April/000494.html showing the convoluted way things have been working. To me it doesn’t sound sustainable, at least not something I’d want to try and sustain.

]]> http://fak3r.com/2009/04/29/resolving-lsids-wit-url-resolvers-and-couchdb/#comment-1378 Rod Page Wed, 29 Apr 2009 18:35:05 +0000 http://www.fak3r.com/?p=1616#comment-1378 There's some (perhaps too much) history here, but I guess the arguments have been that DOIs cost money (and we have potentially 100's of millions of things to assign identifiers to ), and PURLs are a bit too close to URLs (i.e., we're used to URLs breaking, even though this is bad). LSIDs also dragged our field kicking and screaming away from XML schema (gack) and towards RDF. The reality is we will need to handle DOIs, LSIDs, and URLs. There's some (perhaps too much) history here, but I guess the arguments have been that DOIs cost money (and we have potentially 100's of millions of things to assign identifiers to ), and PURLs are a bit too close to URLs (i.e., we're used to URLs breaking, even though this is bad). LSIDs also dragged our field kicking and screaming away from XML schema (gack) and towards RDF. The reality is we will need to handle DOIs, LSIDs, and URLs.

]]> http://fak3r.com/2009/04/29/resolving-lsids-wit-url-resolvers-and-couchdb/#comment-1623 Rod Page Wed, 29 Apr 2009 18:35:00 +0000 http://www.fak3r.com/?p=1616#comment-1623 There's some (perhaps too much) history here, but I guess the arguments have been that DOIs cost money (and we have potentially 100's of millions of things to assign identifiers to ), and PURLs are a bit too close to URLs (i.e., we're used to URLs breaking, even though this is bad). LSIDs also dragged our field kicking and screaming away from XML schema (gack) and towards RDF. The reality is we will need to handle DOIs, LSIDs, and URLs. There’s some (perhaps too much) history here, but I guess the arguments have been that DOIs cost money (and we have potentially 100′s of millions of things to assign identifiers to ), and PURLs are a bit too close to URLs (i.e., we’re used to URLs breaking, even though this is bad). LSIDs also dragged our field kicking and screaming away from XML schema (gack) and towards RDF. The reality is we will need to handle DOIs, LSIDs, and URLs.

]]> http://fak3r.com/2009/04/29/resolving-lsids-wit-url-resolvers-and-couchdb/#comment-1377 Rod Page Wed, 29 Apr 2009 18:31:30 +0000 http://www.fak3r.com/?p=1616#comment-1377 I like this approach. I'm playing with a smaller scale version of this, where the approach is to aggregate RSS feeds, storing associated metadata, and trying to flesh it out (e.g., if the feed contains LSIDs, DOIs, or URLs that lead to machine-readable metadata, these are extracted and metadata added to a central store). I guess the advantage of the kind of approach you're discussing is that in providing robust identifier resolution, we also get a big store of metadata that we can do inference on (and hence yield new connections between disparate facts), which may help make concrete the case for the utility of shared identifiers and vocabularies in the first place. I like this approach. I'm playing with a smaller scale version of this, where the approach is to aggregate RSS feeds, storing associated metadata, and trying to flesh it out (e.g., if the feed contains LSIDs, DOIs, or URLs that lead to machine-readable metadata, these are extracted and metadata added to a central store). I guess the advantage of the kind of approach you're discussing is that in providing robust identifier resolution, we also get a big store of metadata that we can do inference on (and hence yield new connections between disparate facts), which may help make concrete the case for the utility of shared identifiers and vocabularies in the first place.

]]> http://fak3r.com/2009/04/29/resolving-lsids-wit-url-resolvers-and-couchdb/#comment-1622 Rod Page Wed, 29 Apr 2009 18:31:00 +0000 http://www.fak3r.com/?p=1616#comment-1622 I like this approach. I'm playing with a smaller scale version of this, where the approach is to aggregate RSS feeds, storing associated metadata, and trying to flesh it out (e.g., if the feed contains LSIDs, DOIs, or URLs that lead to machine-readable metadata, these are extracted and metadata added to a central store). I guess the advantage of the kind of approach you're discussing is that in providing robust identifier resolution, we also get a big store of metadata that we can do inference on (and hence yield new connections between disparate facts), which may help make concrete the case for the utility of shared identifiers and vocabularies in the first place. I like this approach. I’m playing with a smaller scale version of this, where the approach is to aggregate RSS feeds, storing associated metadata, and trying to flesh it out (e.g., if the feed contains LSIDs, DOIs, or URLs that lead to machine-readable metadata, these are extracted and metadata added to a central store). I guess the advantage of the kind of approach you’re discussing is that in providing robust identifier resolution, we also get a big store of metadata that we can do inference on (and hence yield new connections between disparate facts), which may help make concrete the case for the utility of shared identifiers and vocabularies in the first place.

]]>