[Open-access] NISO Recommendations on Open Access Metadata

[Cameron Neylon]

Hi Andrea

Yes, the questions you raise have come up in several of the comments to the
consultation (and feel free to add your own of course). The issue of
implementation and name spaces has come up in several comments and we will
look at this as we refine the recommendations. The elements will be
implemented by Crossref rapidly. It would be great to include them in a
revision of OAI-PMH and DC but the question does arise of whether to create
a separate name space. We also need to consider how to combine with the
relevant JATS tag.

Anyway, short answer, hopefully we will have some more precise
recommendations after the consultation closes, probably in mid-February or
early March.

Cheers

Cameron


From:  Andrea Zanni <aubreymcfato at gmail.com>
Date:  Tuesday, 28 January 2014 09:37
To:  Cameron Neylon <cn at cameronneylon.net>
Cc:  Graham Triggs <grahamtriggs at gmail.com>, Mike Taylor
<mike at indexdata.com>, "open-access at lists.okfn.org"
<open-access at lists.okfn.org>
Subject:  Re: [Open-access] NISO Recommendations on Open Access Metadata

> Hi all, 
> I've just read the "Open Access Metadata and Indicators" document,
> and I find it very useful.
> A URL for the license and a Y/N free-to-read tag can go a long way in
> conveying the information we want to.
> For what is worth, I find it a clever, low profile approach that could be very
> effective (and don't scare publishers).
> 
> Now, how should I implement it?
> I see that the document recommends to put the tags in the HTML META tags for
> the moment, 
> and hopes for standards (ONIX, OAI-PMH, RDF, DC, ..) to incorporate the new
> elements.
> So, we have to wait them to accept the new tags?
> 
> Cheers
> 
> Andrea Zanni
> Wikimedia Italia
> 
> 
> On Tue, Jan 7, 2014 at 1:07 PM, Cameron Neylon <cn at cameronneylon.net> wrote:
>> 
>> On 7 Jan 2014, at 10:42, Graham Triggs <grahamtriggs at gmail.com> wrote:
>>> > I'm only following this on the periphery at the moment, so forgive me if I
>>> misstep a bit here. But I don't see why there is a theoretical problem to
>>> machine readable standard for rights - create a model for the rights that
>>> you wish to be able to check for, then the licenses can be expressed in
>>> those terms.
>> 
>> Sorry you're right. Rhetorical over-reach. The "theoretical" issue is that
>> metadata is an assertion, whereas licensing is an offer of terms for
>> acceptance. My sense having gone over this is that the two are effectively
>> incompatible or at least not equivalent in their underlying logic of
>> responsibilities and guarantees. When you use a license you are bound by an
>> agreement. When you use metadata there is no such binding. The set of
>> responsibilities and who holds them are different. That said, I have not done
>> a rigorous philosophical analysis, just a proof by exhaustion :-)
>> 
>> You can agree a subset of rights that are expressed through metadata, but
>> then the metadata elements must in effect refer to defined underlying legal
>> language, which means that they are effectively a license, just one expressed
>> in a way which isn't obvious. And you still have to agree that subset of
>> rights and what they mean...which is as we've said not really feasible.
>> 
>> In terms of a registry - I realise where Mike was coming from now. You're
>> absolutely right that a whitelist of defined URLs would be better but this
>> wasn't politically tractable. What was tractable was a requirement that the
>> URL resolve, and that the publisher agree they are bound by the terms at that
>> URL (ie the URL must resolve to an actual license). My assumption is that
>> those requirements make it clear that in those cases where a CC license is
>> used you would choose to point at the CC URL. I guess in principle someone
>> could put a copy of a CC license on their own server but why would you
>> bother?
>> 
>> What we can do is two-fold. Firstly work on best practice guidelines for
>> linking to licenses and license expression to drive consistency (part of my
>> work for this year) and secondly use existing registries eg the OKFN license
>> server to build up that list of URLs in the wild and some subset of rights
>> that matter to us. But my acceptance that this sits outside the
>> recommendation was driven in large part by the same issue as Mike's concerns.
>> A standards process will get bogged down whereas our community can just get
>> on and build those tools up which will in the end be used by default.
>> 
>> Cheers
>> 
>> Cameron
>> _______________________________________________
>> open-access mailing list
>> open-access at lists.okfn.org
>> https://lists.okfn.org/mailman/listinfo/open-access
>> Unsubscribe: https://lists.okfn.org/mailman/options/open-access
> 
> 
> 
> -- 
> http://aubreymcfato.wordpress.com <http://aubreymcfato.wordpress.com>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/open-access/attachments/20140130/507e9779/attachment-0002.html>