[Open-access] NISO Recommendations on Open Access Metadata

Daniel Mietchen daniel.mietchen at googlemail.com
Tue Jan 7 10:33:03 UTC 2014


Such a registry of licenses (with provisions for versioning) would
also be useful to prevent non-standard licenses from being changed
over night.
--
http://www.naturkundemuseum-berlin.de/en/institution/mitarbeiter/mietchen-daniel/
https://en.wikipedia.org/wiki/User:Daniel_Mietchen/Publications
http://okfn.org
http://wikimedia.org


On Tue, Jan 7, 2014 at 11:29 AM, Mike Taylor <mike at indexdata.com> wrote:
> The thing that could save this would be a registry of licence URLs, so
> that a CC By document ALWAYS uses (say)
>         http://creativecommons.org/licenses/by/
> (even though that resolves to a "not found page") rather than
>         https://creativecommons.org/licenses/by/
>         http://creativecommons.org/licenses/by/1.0/
>         http://creativecommons.org/licenses/by/3.0/us/
>         http://creativecommons.org/licenses/by/4.0/
>         http://creativecommons.org/licenses/by/4.0/legalcode
> Or any of the other many other credible candidate URLs
>
> Software needs to be able to do something very simple:
>         if (!strcmp(licenceURL, "http://creativecommons.org/licenses/by/") ...
> otherwise people are surely going to implement swathes of error-prone
> and mutually incompatible heuristics.
>
> -- Mike.
>
>
>
>
> On 7 January 2014 10:22, Cameron Neylon <cn at cameronneylon.net> wrote:
>>
>>>> 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 acknowledge this point. However ...
>>>
>>> Without this, the specification is essentially useless. It's not
>>> machine-readable metadata in any but the thinnest, most legalistic
>>> sense. The specification boils down to "here's a URL to a licence
>>> text, get your lawyer to download it and look it over". I can't do
>>> anything with that.
>>
>> No I disagree. I accept its less useful for non-standard and proprietary licenses but having gone over this I don't think it is either legally, or possibly even theoretically, possible to build a general machine readable standard for rights - and the core problem is that those non-standard licences are just less useful anyway, because they're non-standard. In practice the way to do this, as you say is for a single organisation to create a widely used standard that everyone understands. CC have done that - the URL to a CC license is as good as machine readable. And to the extent it isn't then there's CC-REL.
>>
>>> Yes. A huge job that will either never happen, or be ready to use in
>>> ten years, by which point this specification will have been left in
>>> the dust by whatever pragmatic solutions wins out when the standard
>>> turns out not to meet the actual need.
>>
>> And that specification will be CC licenses. For which the recommendation will support better standardised transmission and the adoption by Crossref means we've got a centralised place for collecting those license statements. The place to standardise is the licenses themselves, not the transmission mechanism. I'm more or less convinced that nothing else can work - but am happy to hear arguments to the contrary.
>>
>>> Really? "Not a step back" is the level of our aspirations now?
>>
>> When the risk was allowing certain parties to say "But NISO says that 'free-to-read' means Open Access so how can you argue with that?". Yep, and avoiding that alone was worth the six months that I sunk into it. That we got agreement from a diverse set of stakeholders that they should a) put their licenses at a defined place on the web and b) provide the URL to those terms with core metadata was a bonus. That we've separated metadata elements on reading rights from re-use rights is also good.
>>
>> You have to defend the flanks as well as lead the advance.
>>
>> 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
> _______________________________________________
> 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



More information about the open-access mailing list