...
VIVO 1.6 release code freeze is now projected for the week after the Conference
- A An open release planning meeting will be held Monday, August 12, at noon EDT.
See the VIVO 1.6 release planning or VIVO 1.6 JIRA issues and please comment
...
- I'm reading the wiki at https://wiki.duraspace.org/display/VIVO/Getting+VIVO+Attributes+from+RDF+Using+R and it says " If you issue this URI to an appropriate function, a chunk of RDF is returned." Does anyone know the method that is called once that .rdf link is clicked? (I understand the purpose of that particular wiki page is to introduce a "simpler way to do this." But I'm also interested in how vivo is handling it right now.)
- The control is in IndividualController, which uses IndividualRequestAnalyzer to redirect to the URL you cite. The actual RDF is assembled by IndividualRdfAssembler
"An error occurred on your VIVO site at ..." (Giuseppe)
I've started receiving a number of these e-mails from our VIVO install and I was wondering how to work out what's causing it.
Restricting user access to data from named graphs (Eliza)
...
URL structure and human readable URLs (Mark)
The question
- I am interested in getting some feedback on some approaches to producing human readable URLs that mirror the information hierarchy of a vivo site. The nature of vivo tends to a very flat URL structure - just a giant bag of URLs at the level of http://sitename/individual/idWith griffith research-hub, we provide a degree of structure for the site with our search engine - linking to a category of results as part of the core navigation, eg: http://research-hub.griffith.edu.au/researchers etc. but subsequent links follow the standard uri pattern. To get around this we provide breadcrumbs on the page - but this contextual information is not part of the URL and is therefore lost when users copy and past URLs into emails etc.
- The goal for both usability and search engine optimisation would be to replace a standard URL like:
- We would still keep the original url as the uri of the subject, but standard site links would point to the human readable version. We have systems in place that would ensure that these human readable URLs would not collide due to similar names (based off our email address naming rules). An immediate issue with this strategy is that we would have essentially duplicate content - which is strongly penalised in google. But we could handle this via either a 301 redirect or rel=canonical strategy (see http://moz.com/blog/canonical-url-tag-the-most-important-advancement-in-seo-practices-since-sitemaps)
- The bigger problem is how to implement the URL in the first place. Any suggestions on what you think the most generic best practice approach would be? Are there any concerns with the basic goal? Any thoughts would be appreciated.
A thought from Jim
- Maybe this shouldn't be done in VIVO at all. If you are running VIVO behind an Apache server, perhaps the Apache server could rewrite the URLS.I know that Apache modules exist that will interpret URLs on input, and also rewrite them on output. So for example, if your page contains a link to http://slashdot.org, Apache will revise the outgoing HTTP stream and rewrite it so the link appears in the user's browser as http://my.stats.server/?url=http%3A%2F%2Fslashdot.org This allows your installation to track "click-throughs" without your content authors having to know about the stats server.How far is it from there, to having a module that can rewrite
Call-in Information
Date: Every Thursday, no end date
...