[Open-access] NISO Recommendations on Open Access Metadata
cn at cameronneylon.net
Tue Jan 7 09:53:21 UTC 2014
> But it seems terribly weak not to encode the specific bits of the CC
> licences, which are nearly always what people want to express and
> search for, even when an actual CC licence is not used. This
> specification really needs elements like...
We went around the loop on this a lot.
The reason for not doing this is two-fold.
The first was that any such element could easily be inconsistent with the actual license. So if the license_ref link is to CC BY but someone encodes non-derivative in metadata which do you believe? And inconsistency is already a problem as Daniel repeatedly tweaks us about (with good cause!). So avoiding the risk of adding to that is important.
I also think encoding those legal terms in metadata is unhelpful. At the end of the day, the user is going to maintain a white-list of licenses that they know allow them to do what they want to do. On the small scale, you and I will look at say "Is it CC BY, OGL, ccZero? If so good". On a large scale people are going to have check with internal legal support - and legal won't care about metadata elements, they'll want to check each license. In an early draft there was a list of possible "rights" that included things like photocopying, emailing, extracting, using images...the list of specific rights/restrictions rapidly got so complicated as to be unworkable. And while there may in our community be agreement that NC/ND/SA are the important restrictions thats not necessarily the case more widely.
The way we did suggest to deal with it in follow on work is a set of best practice recommendations that licenses for scholarly work should handle a specific set of issues - that is there are a set of standard-ish rights that all licenses should deal with. Then in the longer term we could build a registry that would map licenses to standardised rights sets. But this is a huge job because it requires all stakeholders agreeing on what "commercial" use means and what a "derivative" is.
The other reason something like this wouldn't fly was the purely political one. Some organisations don't like CC licenses and anything that looks like "privileging" them was never going to work. My feeling was that in the end people will use work with CC licenses and simply won't use work with non-standard licenses because its too hard to figure out.
The basic point was to find something that could both be agreed and be useful. I'm certainly not saying it solves all the problems and it doesn't simplify some things as much as it might but its a step forward - and just as importantly it isn't a step back, which it could have been.
On 7 Jan 2014, at 09:36, Mike Taylor <mike at indexdata.com> wrote:
> This looks pretty good, and I particularly endorse not using the term
> "open access" in light of the confusion that has been engineered
> surrounding that term.
> To make it useful.
> -- Mike.
> On 7 January 2014 09:29, Cameron Neylon <cn at cameronneylon.net> wrote:
>> Dear All
>> I've been involved in a NISO working group looking at standards for
>> expressing licensing and readership rights in published literature. We have
>> generated a set of recommendations for metadata to be transmitted with
>> articles and/or made available in appropriate repositories. The
>> recommendations are now available for a comment:
>> OAMI public workroom page (http://www.niso.org/workrooms/oami/)
>> Public landing page for the draft and online comments form -
>> The recommendations are actually very minimal in form but they represent an
>> agreed view from a very wide range of stakeholders which is valuable. Their
>> adoption could significantly reduce the confusion around re-use rights and
>> reading rights. You will notice that there is a complete avoidance of the
>> term "open access" in the metadata elements. This is quite deliberate as a
>> means of avoiding disagreements over what "counts" as open access while
>> focussing on making information that is hopefully reasonably objective
>> There are also things we decided not to tackle, including the actual
>> location of copies (this is covered by existing Crossref elements and may in
>> fact be undefined if the metadata is being transmitted with a copy) and
>> visual identifiers. The fact that we didn't include that in this doesn't of
>> course mean that others couldn't expand this set of elements by local
>> agreement for their own purposes.
>> open-access mailing list
>> open-access at lists.okfn.org
>> Unsubscribe: https://lists.okfn.org/mailman/options/open-access
More information about the open-access