RE: [rdf] Re: URIs

Hi All,

Just to add a quick 2c to what Bill and others have to say about
practical use cases.

Since we at Rosetta Biosoftware develop applications for end users we
are rather neutral to how we can get annotation, we're happy with just
about anything.  The key for us is that our users want the
annotation--then we figure out how to get it, that includes the sequence
annotation from the public sources using whatever parsers we find that
can read their one-off formats, GO, where we have a custom import
because we didn't know enough to deal directly with ontologies, and so
on.

The great part of this effort is to regularize how that annotation can
be obtained, regardless of the type of annotation.  Once there is a
systematic way to get to the whatever annotation, when our users want a
new source of annotation, we can stop worrying about how to get it and
simply tell them to point our application at the annotation using the
(now or future) standard access tools.

cheers,
Michael

Michael Miller
Lead Software Developer
Rosetta Biosoftware Business Unit
www.rosettabio.com

> -----Original Message-----
> From: public-semweb-lifesci-request@w3.org 
> [mailto:public-semweb-lifesci-request@w3.org] On Behalf Of William Bug
> Sent: Monday, June 19, 2006 8:20 AM
> To: John Madden
> Cc: Alan Ruttenberg; w3c semweb hcls
> Subject: Re: [rdf] Re: URIs
> 
> 
> 
> I think this is an excellent reference to work from, when dealing  
> with the issue of URIs in RDF generation & processing.
> 
> As I have always seen it (this is admittedly a the view of an RDF  
> naif), DOIs and LSIDs both seek to fulfill the role one would expect  
> to be played by URIs in the STM literature and biomedical object  
> domains, respectively.
> 
> For those who had the chance to read the paper, I would specifically  
> point to the discussion of the CrossRef & OpenURL projects.  Both  
> relate to how you resolve a DOI tied to very practical Use Cases.   
> One is very much focussed on the commercial issue of dis-ambiguating  
> which journals a given library system has a subscription to.  The  
> goal for this (OpenURL - http://www.exlibrisgroup.com/ 
> sfx_openurl.htm) was to create an infrastructure for publishers (and  
> aggregators) to resolve this issue in a way that is transparent for  
> the user as they click on a link to an article (HTML or PDF).  The  
> SFX system many may be familiar with seeing in the search engines  
> hosted by their library systems.
> 
> CrossRef (http://www.crossref.org/) is more designed to address the  
> core issue on the article of how you both maintain stable 
> pointers to  
> inherently unstable online resources, and also providing a URI-like  
> generic resource pointer which can be resolved to the actual 
> resource  
> the moment a reader clicks on the reference in a bibliography.   
> CrossRef is much more focussed on dealing with the many different  
> scenarios related to the latter task and coming up with a way that -  
> again - from the user's point transparently gets them to the correct  
> resource.  CrossRef the organization seems to pitch 
> themselves as the  
> service designed to de-reference DOIs - which obviously makes the  
> work they've done very relevant to this conversation.
> 
> Clearly, both of these issues are ones the folks from BMC & PLoS can  
> give us some very practical insight into.
> 
> The one major project related to the topic in the article that the  
> author seemed to neglect is the Internet Archive (http:// 
> archive.org).  This is a long standing project (in Internet time,  
> anyway - going back to 1996).  They trawl the entire public net and  
> backup it up as often as possible.  They have massive, 
> robotics-based  
> tape drive systems working round the clock.  The original archive  
> took almost a year to crawl the entire "public" net (it still takes  
> about 2 months to cover everything, though there is a lot of effort  
> they've put into to categorizing the rate at which contents 
> changes -  
> with content having a more rapid turnover getting more frequent  
> observation).  After the end of the 1996 presidential campaign -  
> within weeks, the only source for historians to analyze use of the  
> web in the election was the Internet Archive.  This has continued to  
> be the case for many research projects focussed on the use or and  
> evolution of web content.  The IA has set up to donate 
> periodic dumps  
> to the Library of Congress.  They're technology has greatly improved  
> over the years (they now have PetaByte storage racks and much a much  
> more mature software layer).  Though IA doesn't solve the issue of  
> the "hidden"/dynamic web all that much better than the other search  
> engines (which is the space in which most if not all scientific  
> literature lives), they clearly provide a great utility to difficult  
> to manage mess the HTML web often devolves into.  IA is also  
> intimately involved in the discussions in the library science  
> community on this issue of digital reference resolution and  
> archiving, as well as the critical issue of FIXING IP law - 
> very much  
> aligned with the efforts of the Creative Commons.  Some CC folks are  
> also directly involved with IA.  IA has set up a specific group to  
> help researchers make better use of IA content (http:// 
> www.archive.org/web/researcher/researcher.php).
> 
> Cheers,
> Bill
> 
> On Jun 18, 2006, at 12:52 PM, John Madden wrote:
> 
> >
> > Alan et al,
> >
> > Wow, great topic. I'll need to get my thoughts together on this.
> >
> > Meanwhile, operationally what a uri "means" is clearly related to  
> > the question of its (non)persistence. I recently found a wonderful  
> > historical review of this topic from the point of view of a 
> library  
> > scientist. The group might enjoy it:
> >
> > 	http://www.aallnet.org/products/pub_llj_v97n04/2005-42.pdf
> >
> > John
> >
> >
> > On Jun 18, 2006, at 1234, Alan Ruttenberg wrote:
> >
> >>
> >> [It was on this list: http://lists.w3.org/Archives/Public/public- 
> >> semweb-lifesci/2006Jun/0149]
> >> -Alan'
> >> On Jun 18, 2006, at 12:20 PM, John Madden wrote:
> >>
> >>>
> >>> I can't locate the beginning of this thread. Did the discussion  
> >>> start on another list?
> >>> Thanks.
> >>> John
> >>>
> >>> On Jun 17, 2006, at 1708, Eric Neumann wrote:
> >>>
> >>>>
> >>>>
> >>>> This is a very useful and important discussion thread, and I  
> >>>> would like to see others on the list to contribute their  
> >>>> thoughts/concerns as well.
> >>>>
> >>>> May I ask all the contributors to include HTML links to any  
> >>>> acronyms they reference (e.g., NAPTR)? This will make it easier  
> >>>> for the rest of us to catch up quickly, and to eventually  
> >>>> collect the approaches out there into a comprehensive list of  
> >>>> viable implementations.
> >>>>
> >>>> thanks,
> >>>> Eric
> >>>>
> >>>>
> >>>> --- Sean Martin <sjmm@us.ibm.com> wrote:
> >>>>
> >>>> > MW>
> >>>> > MW> I believe this SRV-redirection behaviour is part
> >>>> > of the LSID spec, and
> >>>> > MW> we use it for all of the BioMOBY LSIDs...
> >>>> > MW>
> >>>> >
> >>>> > It also uses NAPTR's as described in IETF RFC's
> >>>> > 3401->3405 to traverse the
> >>>> > URN namespace, allowing the dereferencing process to
> >>>> > bridge the gap that
> >>>> > separates authority name strings from service
> >>>> > locations. From what I
> >>>> > recall, the URN specs specifically do not permit
> >>>> > names and locations to be
> >>>> > confounded.
> >>>> >
> >>>> > Kindest regards, Sean
> >>>> >
> >>>> > --
> >>>> > Sean Martin
> >>>> > IBM Corp.
> >>>> >
> >>>> > public-semweb-lifesci-request@w3.org wrote on
> >>>> > 06/16/2006 12:59:12 PM:
> >>>> >
> >>>> > >
> >>>> > > On Fri, 2006-06-16 at 10:41 -0400, Alan Ruttenberg
> >>>> > wrote:
> >>>> > >
> >>>> > > > something, but as far as I can see, the only
> >>>> > authority related to
> >>>> > > > namespaces in URLs is the DNS, and while there
> >>>> > is the SRV field which
> >>>> > > > might be used to direct someone to information
> >>>> > about the namespace, I
> >>>> > > > don't know whether anyone does.
> >>>> > >
> >>>> > >
> >>>> > > I believe this SRV-redirection behaviour is part
> >>>> > of the LSID spec, and
> >>>> > > we use it for all of the BioMOBY LSIDs...
> >>>> > >
> >>>> > > M
> >>>> > >
> >>>> > >
> >>>> > >
> >>>> > > --
> >>>> > >
> >>>> > > --
> >>>> > > Mark Wilkinson
> >>>> > > Asst. Professor, Dept. of Medical Genetics
> >>>> > > University of British Columbia
> >>>> > > PI in Bioinformatics, iCAPTURE Centre
> >>>> > > St. Paul's Hospital, Rm. 166, 1081 Burrard St.
> >>>> > > Vancouver, BC, V6Z 1Y6
> >>>> > > tel: 604 682 2344 x62129
> >>>> > > fax: 604 806 9274
> >>>> > >
> >>>> > > "For most of this century we have viewed
> >>>> > communications as a conduit,
> >>>> > >        a pipe between physical locations on the
> >>>> > planet.
> >>>> > > What's happened now is that the conduit has become
> >>>> > so big and
> >>>> > interesting
> >>>> > >       that communication has become more than a
> >>>> > conduit,
> >>>> > >        it has become a destination in its own
> >>>> > right..."
> >>>> > >
> >>>> > >                 Paul Saffo - Director, Institute
> >>>> > for the Future
> >>>> > >
> >>>> > >
> >>>> >
> >>>>
> >>>> Eric Neumann, PhD
> >>>> co-chair, W3C Healthcare and Life Sciences,
> >>>> and Senior Director Product Strategy
> >>>> Teranode Corporation
> >>>> 83 South King Street, Suite 800
> >>>> Seattle, WA 98104
> >>>> +1 (781)856-9132
> >>>> www.teranode.com
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>
> >>
> >
> >
> 
> Bill Bug
> Senior Analyst/Ontological Engineer
> 
> Laboratory for Bioimaging  & Anatomical Informatics
> www.neuroterrain.org
> Department of Neurobiology & Anatomy
> Drexel University College of Medicine
> 2900 Queen Lane
> Philadelphia, PA    19129
> 215 991 8430 (ph)
> 610 457 0443 (mobile)
> 215 843 9367 (fax)
> 
> 
> Please Note: I now have a new email - William.Bug@DrexelMed.edu
> 
> 
> 
> 
> 
> 
> 
> This email and any accompanying attachments are confidential. 
> This information is intended solely for the use of the individual 
> to whom it is addressed. Any review, disclosure, copying, 
> distribution, or use of this email communication by others is 
> strictly 
> prohibited. If you are not the intended recipient please notify us 
> immediately by returning this message to the sender and delete 
> all copies. Thank you for your cooperation.
> 
> 
>

Received on Monday, 19 June 2006 15:32:06 UTC