Menu
▾
▴
treebase-devel
|
From: Hilmar L. <hl...@ne...> - 2010-01-13 17:47:43
|
I'm not entirely happy with the naming of the property and the getter (getDomainName()). Would every developer who sees this assume it is the TreeBASE domain name, treebase.org? Isn't there a difference between the domain name of a resource, and the PURL domain it may or may not use? We don't want to serve TB off of the PURL domain and masquerading as such, right? And why is the domain treebase.org not stable as a basis? Why not just call it what it is: treebase.purl.domain for example, and getPurlDomain()? -hilmar -- =========================================================== : Hilmar Lapp -:- Durham, NC -:- informatics.nescent.org : =========================================================== |
|
From: Rutger V. <rut...@gm...> - 2010-01-13 18:24:00
|
Sure, that's fine. Note that this isn't operational yet anyway, but I'll be happy to rename to a more intuitive getter and property name. On Wed, Jan 13, 2010 at 5:47 PM, Hilmar Lapp <hl...@ne...> wrote: > I'm not entirely happy with the naming of the property and the getter > (getDomainName()). Would every developer who sees this assume it is > the TreeBASE domain name, treebase.org? > > Isn't there a difference between the domain name of a resource, and > the PURL domain it may or may not use? We don't want to serve TB off > of the PURL domain and masquerading as such, right? And why is the > domain treebase.org not stable as a basis? > > Why not just call it what it is: treebase.purl.domain for example, and > getPurlDomain()? > > -hilmar > -- > =========================================================== > : Hilmar Lapp -:- Durham, NC -:- informatics.nescent.org : > =========================================================== > > > > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > Treebase-devel mailing list > Tre...@li... > https://lists.sourceforge.net/lists/listinfo/treebase-devel > -- Dr. Rutger A. Vos School of Biological Sciences Philip Lyle Building, Level 4 University of Reading Reading RG6 6BX United Kingdom Tel: +44 (0) 118 378 7535 http://www.nexml.org http://rutgervos.blogspot.com |
|
From: William P. <wil...@ya...> - 2010-01-13 19:32:36
|
On Jan 13, 2010, at 12:47 PM, Hilmar Lapp wrote: > Isn't there a difference between the domain name of a resource, and > the PURL domain it may or may not use? We don't want to serve TB off > of the PURL domain and masquerading as such, right? And why is the > domain treebase.org not stable as a basis? Don't know if I quite understand the nuance here between a stable treebase.org and using purls. But my $0.01 thought is that using purls for all phylows URIs is something we, at one point, decided to do. By contrast, all non-phylows URLs can use whatever domain TreeBASE is running off of (and for the deployment build, treebase.org would point to this). So, for example, our dev-build would be built using the global phylows-property parameter "http://treebasedb-dev.nescent.org:8180/treebase-web/", while the deployment build would be built using the global parameter "http://purl.org/phylo/treebase/". That way we can easily test new changes to TreeBASE on the dev server without all of its /phylows/ links rerouting us to the deployment build. I suppose we could view the access-code-phylows as a "special" /phylows/ string that doesn't need domain name stability. So in that case we would not make use of the global phylows-property parameter, and would instead use whatever the domain name happens to be. bp |
|
From: Vladimir G. <vla...@du...> - 2010-01-13 21:53:01
|
On Jan 13, 2010, at 2:32 PM, William Piel wrote: > my $0.01 thought is that using purls for all phylows URIs is > something we, at one point, decided to do. Since I am late to the party, could someone point me to more details on this matter? At the moment, I have trouble seeing why TB should in any way depend on a third-party URL redirection service. The only valid reasons for PURLs that I see mentioned at http://en.wikipedia.org/wiki/PURL apply to poor people without their own domains. As far as I understand the problem, the real stability issues of a URL like http://purl.org/phylows/study/TB2:S1020 lie not in its "http://purl.org/phylows" part but in its "study/ TB2:S1020" part -- and a redirect to http://treebase.org/phylows/study/TB2:S1020 does not help solving these issues at all, while http://treebase.org/phylows is as stable as http://purl.org/phylows. For a context: I am concerned with the matter only as far as considerations like > So, for example, our dev-build would be built using the global > phylows-property parameter "http://treebasedb-dev.nescent.org:8180/treebase-web/ > ", while the deployment build would be built using the global > parameter "http://purl.org/phylo/treebase/". That way we can easily > test new changes to TreeBASE on the dev server without all of its / > phylows/ links rerouting us to the deployment build. lead to complications of builds that could be avoided. --Vladimir |
|
From: Ryan S. <rsc...@ne...> - 2010-01-14 14:36:32
|
On Jan 13, 2010, at 4:52 PM, Vladimir Gapeyev wrote: > At the moment, I have trouble seeing why TB should in any way depend on a third-party URL redirection service. The only valid reasons for PURLs that I see mentioned at http://en.wikipedia.org/wiki/PURL apply to poor people without their own domains. From a technical perspective, this is correct. As long as the organization has a commitment to maintain permanent URLs, any old domain name will do. But domain names can and do change. We have no idea whether treebase.org will still exist in 50 years. A few fun scenarios: * Treebase merges with Dryad (tryad.org) * Treebase is bought out by Google (phylogenetics.google.com) * Treebase takes over all repositories in the world (the-one-uber-repository.com) There are many possible situations in which it would not make sense to continue use of the treebase.org domain. Using a more neutral third party (purl.org) is one way to manage the changes. --- Ryan |
|
From: Vladimir G. <vla...@du...> - 2010-01-14 14:43:41
|
On Jan 14, 2010, at 9:36 AM, Ryan Scherle wrote: > But domain names can and do change. We have no idea whether > treebase.org will still exist in 50 years. A few fun scenarios: > * Treebase merges with Dryad (tryad.org) > * Treebase is bought out by Google (phylogenetics.google.com) > * Treebase takes over all repositories in the world (the-one-uber- > repository.com) Realistically, how any one of these is significantly more likely than * purl.org ceases operations ? --Vladimir |
|
From: Ryan S. <rsc...@ne...> - 2010-01-14 15:04:51
|
> Realistically, how any one of these is significantly more likely than > * purl.org ceases operations Get out your crystal ball. But a number of libraries depend on purl.org, so I expect someone to keep it running for a long time. --- Ryan |
|
From: William P. <wil...@ya...> - 2010-01-14 15:00:00
|
On Jan 14, 2010, at 9:36 AM, Ryan Scherle wrote: > But domain names can and do change. Don't know if this is worth anything, but is there anything "elegant" about an informal policy of putting phylows APIs in a common base domain? eg.: purl.org/phylo/treebase/ purl.org/phylo/ToL_web/ purl.org/phylo/iplant/ purl.org/phylo/phylr/ (etc) bp |
|
From: Hilmar L. <hl...@ne...> - 2010-01-14 16:58:03
|
Looks nice to me, but anyone (i.e., any third party) could do that on top of each resource's individual base PhyloWS URL, couldn't they? I.e., this need not be a responsibility of the data resources per se, no? -hilmar On Jan 14, 2010, at 9:59 AM, William Piel wrote: > > On Jan 14, 2010, at 9:36 AM, Ryan Scherle wrote: > >> But domain names can and do change. > > Don't know if this is worth anything, but is there anything > "elegant" about an informal policy of putting phylows APIs in a > common base domain? > > eg.: > > purl.org/phylo/treebase/ > purl.org/phylo/ToL_web/ > purl.org/phylo/iplant/ > purl.org/phylo/phylr/ > > (etc) > > bp > > > > ------------------------------------------------------------------------------ > Throughout its 18-year history, RSA Conference consistently attracts > the > world's best and brightest in the field, creating opportunities for > Conference > attendees to learn about information security's most important > issues through > interactions with peers, luminaries and emerging and established > companies. > http://p.sf.net/sfu/rsaconf-dev2dev > _______________________________________________ > Treebase-devel mailing list > Tre...@li... > https://lists.sourceforge.net/lists/listinfo/treebase-devel -- =========================================================== : Hilmar Lapp -:- Durham, NC -:- informatics.nescent.org : =========================================================== |
|
From: William P. <wil...@ya...> - 2010-01-14 17:36:31
|
On Jan 14, 2010, at 11:57 AM, Hilmar Lapp wrote: > Looks nice to me, but anyone (i.e., any third party) could do that on > top of each resource's individual base PhyloWS URL, couldn't they? > I.e., this need not be a responsibility of the data resources per se, > no? Yes, although we don't want to proliferate synonymous references, right? On Jan 13, 2010, at 4:52 PM, Vladimir Gapeyev wrote: > As far as I understand the problem, the real stability issues of a URL like http://purl.org/phylows/study/TB2:S1020 lie not in its "http://purl.org/phylows" part but in its "study/TB2:S1020" part I take it that the "gold standard" is now the "linked list" approach in the semantic world: i.e., each RDF, XML, OWL, or whatever, uses fully resolvable and globally unique identifiers. So for TreeBASE study_id "44", they would not use <id>44</id>, nor would they use <id>study/TB2:S1020</id> or even <id>/phylows/study/TB2:S1020</id> -- but rather they would use <id>http://purl.org/phylo/treebase/phylows/study/TB2:S1020</id>. If there exists one, say, GIS document that references a tree like so: <id>http://purl.org/phylo/treebase/phylows/tree/T1020</id> and another, say, CITES document that references the very same tree with <id>http://treebase.org/phylows/tree/T1020</id>, a semantic reasoner might not realize that the referenced trees are the same tree, no? So, my take of the "linked list" approach is that the full URLs matter (not just the "study/TB2:S1020" part), and therefore we should beware of multiple domains that have the effect of creating synonymous URIs. bp |
|
From: Hilmar L. <hl...@ne...> - 2010-01-14 17:41:48
|
On Jan 14, 2010, at 12:36 PM, William Piel wrote: > If there exists one, say, GIS document that references a tree like > so: <id>http://purl.org/phylo/treebase/phylows/tree/T1020</id> and > another, say, CITES document that references the very same tree with > <id>http://treebase.org/phylows/tree/T1020</id>, a semantic reasoner > might not realize that the referenced trees are the same tree, no? I agree that canonical data object URIs are a highly desirable feature, and if TB2 can show them rather than having the user guess that's valuable. It also seems to me that the implementation of that is almost done by Rutger anyway? So, trying to recall what's at issue here I'm not so sure anymore. Looks like we pretty much agree and Rutger is almost there with the property and getter method naming? Or am I under coffee deprivation? -hilmar -- =========================================================== : Hilmar Lapp -:- Durham, NC -:- informatics.nescent.org : =========================================================== |
|
From: Vladimir G. <vla...@du...> - 2010-01-14 18:45:54
|
On Jan 14, 2010, at 12:41 PM, Hilmar Lapp wrote: > So, trying to recall what's at issue here I'm not so sure anymore. > Looks like we pretty much agree and Rutger is almost there with the > property and getter method naming? Or am I under coffee deprivation? Putting aside the relative merits of PURLs vs YOURL-APAYAs (Your Own URLs - As Permanent As You Are), here is the practical matter: Does the property treebase.domain.name hold the value (be it "purl.org/ phylows" or "treebase.org") that will be the same in all three or more TB installations (production, staging, development, ...)? If yes, all is good. [I see it is currently "treebase-dev.nescent.org: 6666", which does not smell good.] If not, can we adjust our needs or the implementation so that it is the case? [This could be doable, while keeping PURLs in.] If not, then this value should be moved outside the WAR (e.g., become a JNDI parameter). --Vladimir |
|
From: Hilmar L. <hl...@ne...> - 2010-01-14 21:38:43
|
On Jan 14, 2010, at 1:45 PM, Vladimir Gapeyev wrote: > Does the property treebase.domain.name I voted strongly for calling this treebase.purl.domain, to make clear what it is. I believe Rutger and most (all?) others were fine with that? > hold the value (be it "purl.org/ phylows" or "treebase.org") that > will be the same in all three or more TB installations (production, > staging, development, ...)? It can't be the same everywhere *and* resolve back to the same instance, since we won't replicate staging and dev URL redirects to purl.org. So either it is the same everywhere and then de-referencing those URIs will always go to production, or it is different to allow resolution to the origin, and then staging and dev need to have their own purl.treebase.org or something URIs, which complicates matters. I don't see a problem if for the time being PURL URIs always go to production regardless of origin. That is not different, for example, for Dryad, where all handle URIs resolve to production, whether they originate from development or production, or if we used DOIs. -hilmar -- =========================================================== : Hilmar Lapp -:- Durham, NC -:- informatics.nescent.org : =========================================================== |
|
From: Vladimir G. <vla...@du...> - 2010-01-15 21:17:32
|
On Jan 14, 2010, at 4:38 PM, Hilmar Lapp wrote: > I don't see a problem if for the time being PURL URIs always go to > production regardless of origin. That is not different, for example, > for Dryad, where all handle URIs resolve to production, whether they > originate from development or production, or if we used DOIs. This would resolve my concerns. (That is, in all instances, treebase.domain.name / treebase.purl.domain always contains the same value, "purl.org" or "treebase.org"). --VG |
|
From: Hilmar L. <hl...@ne...> - 2010-01-15 21:25:45
|
On Jan 15, 2010, at 4:17 PM, Vladimir Gapeyev wrote: > > On Jan 14, 2010, at 4:38 PM, Hilmar Lapp wrote: > >> I don't see a problem if for the time being PURL URIs always go to >> production regardless of origin. That is not different, for example, >> for Dryad, where all handle URIs resolve to production, whether they >> originate from development or production, or if we used DOIs. > > This would resolve my concerns. (That is, in all instances, > treebase.domain.name / treebase.purl.domain always contains the same > value, "purl.org" or "treebase.org"). Right. -hilmar -- =========================================================== : Hilmar Lapp -:- Durham, NC -:- informatics.nescent.org : =========================================================== |
|
From: Rutger V. <rut...@gm...> - 2010-02-15 18:16:15
|
OK, so this is up and running. The property is called "treebase.purl.domain", the method is getPurlDomain(), and the value is "http://purl.org/phylo/treebase/phylows/". This purl subdomain is administered by Hilmar, Bill and myself (since the db interop hackathon, if I recall correctly) and now points to treebase-dev.nescent.org:6666. As a side note, the URL equivalence issue that Bill notes (is a treebase.org URL the same as a purl?) is of course a hairy issue, especially if we also consider other data resources. The consensus from the BioHackathon in Tokyo this week is that one should use URLs as identifiers, that one should be using the *canonical* URLs as recommended by the data resource, that if worst comes to worst (i.e. one has become dependent on non-standard URLs) one should define owl:sameAs so that the resources are collapsed into one. This is supposed to become known as the Tokyo Manifesto, according to the more pompous attendants to the meeting. Rutger On Fri, Jan 15, 2010 at 9:25 PM, Hilmar Lapp <hl...@ne...> wrote: > > On Jan 15, 2010, at 4:17 PM, Vladimir Gapeyev wrote: > >> >> On Jan 14, 2010, at 4:38 PM, Hilmar Lapp wrote: >> >>> I don't see a problem if for the time being PURL URIs always go to >>> production regardless of origin. That is not different, for example, >>> for Dryad, where all handle URIs resolve to production, whether they >>> originate from development or production, or if we used DOIs. >> >> This would resolve my concerns. (That is, in all instances, >> treebase.domain.name / treebase.purl.domain always contains the same >> value, "purl.org" or "treebase.org"). > > Right. > > -hilmar > > > -- > =========================================================== > : Hilmar Lapp -:- Durham, NC -:- informatics.nescent.org : > =========================================================== > > > > > ------------------------------------------------------------------------------ > Throughout its 18-year history, RSA Conference consistently attracts the > world's best and brightest in the field, creating opportunities for Conference > attendees to learn about information security's most important issues through > interactions with peers, luminaries and emerging and established companies. > http://p.sf.net/sfu/rsaconf-dev2dev > _______________________________________________ > Treebase-devel mailing list > Tre...@li... > https://lists.sourceforge.net/lists/listinfo/treebase-devel > -- Dr. Rutger A. Vos School of Biological Sciences Philip Lyle Building, Level 4 University of Reading Reading RG6 6BX United Kingdom Tel: +44 (0) 118 378 7535 http://www.nexml.org http://rutgervos.blogspot.com |
|
From: Jon A. <jon...@du...> - 2010-01-22 18:27:33
|
Production Treebase server has been setup with Tomcat, Apache, and Postgresql. All we need now is a cleaned version of the database. To recap, we now have three instances of the application located at: http://treebase-dev.nescent.org \\ connects to current dev database, contains junk data http://treebase-stage.nescent.org \\ connects to staging database, which is a restore of the database on Dec. 8, 2009. http://treebase-stage.nescent.org \\ currently connects to staging database, but will connect to production once ready We are using the same war file on all instances that Vladimir successfully built on his developer laptop. As I see it, the remaining issues before bringing treebase into live production are: 1) verify that we've got a clean database. * Bill, can you verify that the staging database is clean and/or let us know what we need to do to clean it? 2) settle the matter on persistent url. I saw a lot of discussion about this while I was out, but am not sure if there was a conclusion. 3) along the matter of persistent urls, do we want to redirect treebase.org to the new server? -Jon ------------------------------------------------------- Jon Auman Systems Administrator National Evolutionary Synthesis Center Duke University http:www.nescent.org jon...@ne... ------------------------------------------------------ |
|
From: William P. <wil...@ya...> - 2010-01-22 18:49:30
|
Thanks, Jon. On Jan 22, 2010, at 1:23 PM, Jon Auman wrote: > To recap, we now have three instances of the application located at: > > http://treebase-dev.nescent.org \\ connects to current dev database, contains junk data > http://treebase-stage.nescent.org \\ connects to staging database, which is a restore of the database on Dec. 8, 2009. > http://treebase-stage.nescent.org \\ currently connects to staging database, but will connect to production once ready For the last one, did you mean something like "treebase-production.nescent.org" ? > 1) verify that we've got a clean database. > * Bill, can you verify that the staging database is clean and/or let us know what we need to do to clean it? The data behind http://treebase-stage.nescent.org/treebase-web/ looks the same as the data behind http://treebasedb-dev.nescent.org:6666/treebase-web/ . (e.g. the tb1 account contains a number of auto-generated test records. > 3) along the matter of persistent urls, do we want to redirect treebase.org to the new server? That will happen when we shut down TreeBASE1. bp |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X