Re: [Treebase-devel] Some results of testing with a user

[Hilmar L. <hl...@ne...>]

The PURLs need to be thought of as the canonical, globally unique, and  
resolvable (yes!) identifier for data items in TreeBASE. The way to  
look at them I think should be as if they were DOIs, or Handles, or  
LSIDs.

We are dispensing GUIDs for data items in TreeBASE, and rather than  
DOIs or Handles they happen to be HTTP URIs that resolve. This is the  
Right Thing (tm) from a SemWeb and Linked Data perspective.

A GUID for a data item should resolve to one and only one location, so  
that they resolve to production is also the Right Thing, and in line  
with the behavior of DOIs. Publishers cannot test their article DOIs  
solely on development systems either: DOIs always resolve to their  
production sites. Dryad faces the same problem.

What's important here is not to use canonical GUIDs frivolously. They  
must be advertised to the user in appropriate locations, and they must  
be used consistently in output that we emit to be consumed by machines.

The question is less clear whether they should be used throughout by  
the application wherever it hyperlinks within the UI to a  
representation (in HTML, NeXML, or RDF) of a data item. A machine will  
not benefit from this, and I'm not sure how the human user would.  
Publishers don't link to article downloads through the DOI. Dryad does  
link through the DOI or Handle to data files that are part of a data  
package. However, that's primarily because the UI for this is just an  
HTML rendering of the data package's metadata, and the IDs of the  
constituent data files are their Handles (or DOIs).

Bottom line from my perspective: 1) we shouldn't confuse data object  
GUID HTTP URIs with URLs that the application uses to allow a human  
user to navigate the web-app; 2) regardless we need to be able to test  
our HTTP URIs that serve as GUIDs.

Re: #1, even if currently we overuse canonical GUIDs in the UI, I  
don't think we need to address this before release. Re: #2, we already  
have a configuration parameter to control the base URL for the GUIDs.  
Eventually I would like us to have our own PURL server at http://purl.treebase.org 
, but we're not going to accomplish that today or shortly. So instead  
I created the following alternative base URLs, with obvious redirection:

http://purl.org/phylo/treebase/dev/phylows/
http://purl.org/phylo/treebase/stage/phylows/

	-hilmar

On Mar 19, 2010, at 3:47 AM, Rutger Vos wrote:

>> (3) Havoc from purls.  Since sometime recently, *some* links that  
>> are crucial for the functionality of the application contain purls  
>> instead of urls pointing to the current application instance.  Due  
>> to the current resolution of the purls, this makes all instances to  
>> eventually drift to the treebase.nescent.org instance.
>> For example, in search results > Matrices tab:     the columns ID,  
>> Download NeXML, Download RDF, and Download Reconstructed, and  
>> Matrix Row List contain purl links  (Wrong!),     while the columns  
>> Taxa and Download Original have links to the current instance  
>> (Right!) Interestingly, in the Trees tab all the similarly  
>> appearing links point to the current instance. (Right!)
>
> I implemented this. Since the re-configuration of tomcat to run
> multiple instances of the webapp some links had been pointing to
> localhost. After discussion on this list it was decided that it would
> be OK to have these links be purls instead, and I personally believe
> this is not just OK but actually important, especially if these
> download links point to RDF. So not "Wrong!", but just not to your
> liking. You're welcome to reopen the relevant ticket (2960909),
> restart the discussion (I believe agreement was reached roughly here:
> https://sourceforge.net/mailarchive/message.php?msg_name=04E...@ne...)
> and wait for me to fix the issue again, this time to your
> specification.
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Treebase-devel mailing list
> Tre...@li...
> https://lists.sourceforge.net/lists/listinfo/treebase-devel

-- 
===========================================================
: Hilmar Lapp  -:- Durham, NC -:- informatics.nescent.org :
===========================================================