During the last year (based on former work done by the UOC fellows) we have been reflecting on "public ID notation".
UOC people proposed to follow a few basic SEO practices to build URLs that "made sense" to google (et al) and suggested a notation that is smart so we also adopted and adapted it a little. The notation could summarized as:
- * Issue: v[volum]-n[number]-[year]
* Article: v[volum]-n[number]-[first_author_surname]-[second_author_surname]...
* Article with more than 3 authors: v[volum]-n[number]-[first_author_surname]-et-al...
* Downloadable resource: pdf | html | whatever...
* Downloadable resource in multilang: [extension]-[3_digit_lang]
Disclaimer: Sorry in advance to publish it summarized and not following a regular grammar.
In OJS 2.3.6 you can configure your system to build nice URLs as follows:
- * Issue: http://mysite/mymagazine/issue/view/v1-n1-2013
* Article1: http://mysite/mymagazine/article/view/v1-n1-bria
* Article2: http://mysite/mymagazine/article/view/v1-n1-bria-smith
* Article2: http://mysite/mymagazine/article/view/v ... smith-chen
* Article3: http://mysite/mymagazine/article/view/v1-n1-bria-et-al
* PDF: http://mysite/mymagazine/article/view/v1-n1-bria/pdf
* PDF in english: http://mysite/mymagazine/article/view/v ... ia/pdf-eng
* HTML: http://mysite/mymagazine/article/view/v1-n1-bria/html
Our magazines rarely publish supplementary files, so we didn't pay much attention to this. Proposals are welcomed.
Why those URLs? Google (et. al.) only distinguish 3 special characters in the URL and those chars are "-", "." and "/" that are used as separators.
And this is why every word is separated by "-" to facilitate the "perfect match".
We also expect to build URLs smaller than 100 chars (that it's also a SEO recommendation).
So for instance, article's URLs will include separate strings with magazine name/tag ("mymagazine"), the basic issue info ("v1" and "n1") and the author's surnames ("bria-smith-chen") and the resources will include the mime-type ("pdf") and the language ("eng")...
I believe this is a good practice and this is why I share... BUT first, I also have some questions-proposals:
- * Why "/" char is wrongly parsed? When you try to include the slash it's translated to %2F that is ok in general to avoid security issues but "/" is also a good element to play with in urls (and also DOIs), isn't it? So my suggestion is not parsing this char and letting the editors add "/" in the "public IDs" if they like.
* Why Galleys names need to be unique? In new OJS versions "Public IDs" are moved as plugins (and this is a really good idea) but now, in this change, "Galleys" tags (and supplementary files) need to be unique and this breaks the former notation. Is there a reason for this? Will downloaded file keep the personalized name? I mean, the article URL need to be unique, but the downloadable resource url will be a combination of the article's url+the resource "public id" so it will include duplicities in the final address (pe: http://mysite/mymagazine/article/view/v ... 1-bria.pdf)
* Why not including a %x variable for DOIs? Would be nice to have a variable to build patterns that generate a "DOI Sufix" including "Custom Identifiers"? It will let us create DOIs as 10.1234/magazines/mymagazine/v1-n1-bria-smith-chen (with a pattern like "magazines/%j/%x"). Once again, slash is "forbidden" here as far as will be translated to %2F.
Thanks for your comments,