Date of publication

[katefoneill]

Posting on behalf of a UK Corr member

There is only one field for date of publication. We need date of online publication and final publication to be included

[ThomBlakeLib]

In the profile the description for the rioxxterms:publication_date element says "in the form in which it would be cited", which is a different thing again. Would we need all three?

The description says that this is the "publication date of the resource". Just for the avoidance of doubt should this be publication date of the version of record of the resource?

[jesusbagpuss]

This has a relation to #6.

My reading of the current RIOXX2 profile is that the publication_date is more of a bibliographic element than a reporting/compliance one.

The existing publication_date could be left as-is (in it's free-text form), and a new repeatable 'dates' element (conforming to W3CDTF or ISO8601?) could be added which would assist machine-processing. The new 'dates' element would need attributes/sub-elements to declare what the date is - published/published_online/accepted/... (from a controlled list).

PS Nice to see a happenchance WR coalescence!

[geo-mac]

On a more general note - and picking up the element refinement approach suggested by @jesusbagpuss - publication_date, as a concept, does not exist for many of the outputs produced at those institutions producing non-standard scholarly outputs. Nor does dcterms:dateAccepted. When is an art exhibition ‘published? To be useful to art/design or creative institutions, it probably needs to be possible to capture alternative dates. Again, this could be best captured via element refinement and addressed in tandem with the alternative publications states typifying standard scholarly publications.

[ThomBlakeLib]

It doesn't look like this got resolved yet in v.3.0 beta. If this is the citation date ('publication_date' is possibly slightly confusing terminology here) then trying to make it conform to ISO8601/W3CDTF seems wrong. It's certainly true that these are free-text makes them imprecise and not standardised and that makes them diffecult to work with, but that is how it is. Forcing them to comply with a stardard just means they will also be inaccurately represented (while still being imprecise and not standardised).

[geo-mac]

It doesn't look like this got resolved yet in v.3.0 beta.

I recall a lot of discussion around about it, although I would need to dig into the minutes to recall exactly what was said! :-) Yes, the concept of 'citation date' and 'publication date' could do with some revisitation to ensure conceptual consistency.

A few comments about the capturing of dates: There is nothing in the beta profile to prevent an alternative encoding of publication_date, so anything complying with ISO8601/W3CDTF would be acceptable, e.g. 2021-07-23, or 2021-07, or even simply 2021 (although not especially useful). I reckon the wording in the profile could be tightened up here to make it a recommendation that a full date be used.

Forcing them to comply with a stardard just means they will also be inaccurately represented (while still being imprecise and not standardised).

The mapping between seasons and dates was derived from other communities of practice such as the UK REF2021, since greater specificity in publication dates was required here too. But seasonal values could always be inferred from the mapping if necessary anyway, e.g. via a look-up...?

[ThomBlakeLib]

I think it comes back to what we need this date to do. Let's say you have an article that was actually made publicly available on 23rd July 2021 but was allocated to the Autumn 2021 issue of the journal. If what we want is the actual publication date then it would make sense to have it as 2021-07-23 and to encourage the full date being used (this totally makes snse to me as the way to go). But what the profile calls for at the moment is the date "in the form in which it would be cited". In this case the form in which it would usually be cited - for better or worse - is the form that the publisher gave it "Autumn 2021". In this context, citing it as "2021-10" seems incorrect to me.

[geo-mac]

But what the profile calls for at the moment is the date "in the form in which it would be cited".

Ahhhhh, I missed your allusion to this in the previous comments. This particular provision could be a hangover from v2.0 (and an oversight in the latest version), as I'm sure we discussed changing this. Something that needs looking at, definitely.

[ThomBlakeLib]

Sorry, I wasn't being very clear. I think if this becomes the actual date of first publication rather than the date as it would be cited then it all makes perfect sense.

[paulwalk]

superseded by launch of Rioxx version 3.0 - closing this issue