As the developers of Open Journal Systems, Open Conference Systems, Open Harvester Systems, and Open Monograph Press, the PKP team are experts in helping journal managers and conference organizers make the most of their online publishing projects. PKP Publishing Services offers support for:

As a customer of PKP Publishing Services, you will not only receive direct, personalized support from the PKP Development Team, but will be contributing to the ongoing development of the PKP applications. All funds raised by PKP Publishing Services go directly toward enhancing our free, open source software. For more information, please contact us.

Forum rules
This forum is meant for general questions about the usability of OJS from an everyday user's perspective: journal managers, authors, and editors are welcome to post questions here, as are librarians and other support staff. We welcome general questions about the role of OJS and how the workflow works, as well as specific function- or user-related questions.

What to do if you have general, workflow or usability questions about OJS:

1. Read the documentation. We've written documentation to cover from OJS basics to system administration and code development, and we encourage you to read it.

2. take a look at the tutorials. We will continue to add tutorials covering OJS basics as time goes on.

3. Post a question. Questions are always welcome here, but if it's a technical question you should probably post to the OJS Technical Support subforum; if you have a development question, try the OJS Development subforum.

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:

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.

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.

I'm assuming you mean "/" characters placed in custom identifiers. This is a reflection of the way OJS URLs are parsed and handled; given two of the examples above:

The galley custom identifiers have to be unique now in order for galley DOIs using custom identifiers as suffix to be unique. Earlier, there were no possibility to assign a DOI to a galley so this wasn't important, I suppose, but now...

Marc: 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.

Alec: I'm assuming you mean "/" characters placed in custom identifiers...how would OJS know whether we were referring to a PDF belonging to article "v1-n1-bria", or an article landing page with "v1-n1-bria/pdf" as the public identifier?

Humm... I understand know. I don't see an easy solution then. I was just wondering (and wishing )

Alec: There may be implications related to the relevant PID standards; I'll check with the developer who was most recently working on those.

Bozana: The galley custom identifiers have to be unique now in order for galley DOIs using custom identifiers as suffix to be unique. Earlier, there were no possibility to assign a DOI to a galley so this wasn't important, I suppose, but now...

I didn't know you were talking about Bozana.

I don't claim about DOIs (we are introducing DOIs right now, so I can't talk much about it), my real concern is about URLs.

Right now, the magazines were able to assign to galleys a NON unique public ID (in OJS 2.3.x or lower, it means same public ID for DOI&URL).As far as OJS don't warns, I suspect that a lot of magazines apply a syntax like:

http://mysite/mymagazine/article/view/article-public-ID/doc-type

If now, the galley-public-ID need to be unique, we will break the backward compatibility.

More than this... if the URL is build in the same way was built in former versions, the result will be URLs with duplicates as:

Hmmm... I am not sure how to solve this problem best. At the moment I think the following solutions are possible:1. Remove the uniqueness constraint for the galley custom identifiers as well as the possibility to use those custom identifiers for DOI suffixes (there will still be a possibility to use custom DOI suffixes),2. Remove the uniqueness constraint for the galley custom identifiers and automatically add the article best identifier to galley DOI suffix (when the custom identifiers are used for it), for example:article custom identifier = v1-n1-bria,galley custom identifier = pdf,DOI suffix = v1-n1-bria_pdfAnd, of course, explain it to the users.3. To leave it as it is, although I think this way of naming that Marc mentions makes lots of sense for the URLs.

I think the procedure is the same for the supplementary files, but it's maybe OK so i.e. could be left as it is, because supp files are something different than galleys.

There is 1) the possibility to use the object custom identifier for the DOI suffix and 2) the possibility to use a custom DOI suffix. If #1 is chosen, then the object custom identifier (as it is) is used for the suffix (DOI suffix = custom identifier) and the DOI = DOI prefix + suffix i.e. DOI = DOI prefix + custom identifier. There is no possibility here to change/edit it. Thus there is no uniqueness check for the DOI in this case, because it wouldn't bring anything, I think. For example:DOI prefix = 10.12345DOIs should be assigned to galleysThere is article 1 galley named 'pdf' and article 2 galley named 'pdf'Then the two DOIs, for the both galleys, would be the same: 10.12345/pdf. Checking this without the possibility to edit it wouldn't bring anything, right?

If the #2 is chosen (that has nothing to do with the custom identifiers from #1) then there is the DOI uniqueness check.

7) ...DOI Plugin is able to use "custom Identifier" (see point 4.) as a suffix. Then DOI=DOI prefix + "custom-id".

8) ...DOI Plugin is able to use individual item's PIDs as a suffix that is independent from the custom-id (in other words, URLs).

Am I right? Please, correct any of the former sentences if something is wrong.

IMHO, the point here is how the DOI and the URL is checked: If I'm following you, right now we are checking the ID against the DB, instead of checking the full path (see point 0.)

If we all agree that URLs like "http://mysite/mymagazine/article/view/n1-v2-bozana/pdf" are a good idea, we need to check the full URL and not only "custom-id" (in this case "pdf") to be sure are unique.

If we check the full path and we include the "custom-id" as a variable for suffix patterns, I think we will have the best of both worlds.

What do you think?

Cheers,m.

PD: BTW, congratulations Bozana if DOI&URN plugins are yours. You did an incredible work.

7) ...DOI Plugin is able to use "custom Identifier" (see point 4.) as a suffix. Then DOI=DOI prefix + "custom-id".

True. It is the 3. option for DOI suffix in the DOI plug-in settings.

mbria wrote:

8) ...DOI Plugin is able to use individual item's PIDs as a suffix that is independent from the custom-id (in other words, URLs).

Hmmm... What do you mean with 'individual item's PIDs'? Somehow the 'custom' and 'public' identifier are the same for me here -- 'custom identifier' is used in the UI (setup 4) and 'public identifier' in the code (I think).Do you maybe mean: Since OJS 2.4.0 there is also a possibility to create and use a custom DOI suffix (independent from the object/item custom/public identifier above)? This is true.

mbria wrote:Am I right? Please, correct any of the former sentences if something is wrong.

Done

mbria wrote:IMHO, the point here is how the DOI and the URL is checked: If I'm following you, right now we are checking the ID against the DB, instead of checking the full path (see point 0.)

If we all agree that URLs like "http://mysite/mymagazine/article/view/n1-v2-bozana/pdf" are a good idea, we need to check the full URL and not only "custom-id" (in this case "pdf") to be sure are unique.

Yes you are right for the URLs, but for DOIs:If 'Galleys' is chosen for the journal content in the DOI plug-in settings andif the 3. option is chosen for the DOI suffix in the DOI plug-in settingsthenall galley DOIs, for all galleys, will be constructed like this: DOI prefix + custom identifier (= DOI prefix + 'pdf') which will make all DOIs be the same i.e. be not unique.

mbria wrote:If we check the full path and we include the "custom-id" as a variable for suffix patterns, I think we will have the best of both worlds.

True. If we introduce the custom/public identifier as a variable for the DOI suffix and then construct a pattern for galleys (in the 1. option for the DOI suffix in the DOI plug-in settings) using this variable but also something else (only this varialbe wouldn't be enough -- it would be the same as the problem we are talking now) everything will be fine.The problem is this 3. option for DOI suffix in the DOI plug-in settings.

mbria wrote:What do you think?

I suppose still that we have those 3 solutions I mentioned earlier

mbria wrote:Cheers,m.

PD: BTW, congratulations Bozana if DOI&URN plugins are yours. You did an incredible work.

Thanks a lot! It wasn't just me -- there was also Florian Grandel working on this, so I will tell him -- he will surely be, just as me, very glad to hear it

mbria wrote:If we check the full path and we include the "custom-id" as a variable for suffix patterns, I think we will have the best of both worlds.

Bozana: True. If we introduce the custom/public identifier as a variable for the DOI suffix and then construct a pattern for galleys (in the 1. option for the DOI suffix in the DOI plug-in settings) using this variable but also something else (only this varialbe wouldn't be enough -- it would be the same as the problem we are talking now) everything will be fine. The problem is this 3. option for DOI suffix in the DOI plug-in settings (option 3 at settings).

So if it's ok for you let's "divide&conquer": we can close first DOI for galleys before we talk about supplementary files and URLs.

For DOI galleys you pointed the following solutions:

1. No custom-id, just doi-id: Remove the uniqueness constraint for the galley custom identifiers as well as the possibility to use those custom identifiers for DOI suffixes (there will still be a possibility to use custom DOI suffixes),2. "Auto doi" based on article&galley: Remove the uniqueness constraint for the galley custom identifiers and automatically add the article best identifier to galley DOI suffix (when the custom identifiers are used for it), for example: article custom-id = v1-n1-bria, galley custom-id = pdf ---> DOI suffix = v1-n1-bria_pdf3. "Do nothing": To leave it as it is, although I think this way of naming that Marc mentions makes lots of sense for the URLs.

I'm not sure witch one of the former solutions it's the one that allows %x (custom-id variable), but I will vote for it. BTW, you point that a suffix that it's "only this variable wouldn't be enough -- it would be the same as the problem we are talking now".I agree: A simple pattern as "%x" will be the same as "option 3 at settings", but it won't be a problem for some editors that like this syntax.

Finally, about solution 3 I think isn't really an option.It's not only about making URLs look nicer or SEO friendly... my concern is the backward compatibility.

the first solution:"Remove the uniqueness constraint for the galley custom identifiers as well as the possibility to use those custom identifiers for DOI suffixes (there will still be a possibility to use custom DOI suffixes)"

means:The galleys custom identifiers will not have to be unique. I.e. the pattern you were describing (using always 'pdf' for each PDF galley) will be possible.The problematic 3. option for DOI suffix should be removed, because this could lead to not unique DOIs. For example above they would always look like DOI prefix + 'pdf'. This is what I've meant with "the possibility to use those custom identifiers for DOI suffixes".If a journal is manually controlling the uniqueness of their galley custom ids and would like to have DOI suffixes to be the same as the custom identifiers, then there is still the currently existing possibility to use custom DOI suffixes (4. option for DOI suffix) and to enter the appropriate custom identifier for a DOI manually. Also, there will be better/easier way -- to use %x -- when this is implemented. /* I just didn't wanted to mention it above, because it is still not there. */