[open-bibliography] Wikipedia project: bibliographic-archival data base

[David Weinberger]

"A piece of content or data is open if anyone is free to use, reuse,
and redistribute it — subject only, at most, to the requirement to
attribute and share-alike"

That describes any data you can get via LibraryCloud's API.

I know that's not exactly what you want the stated definition to mean,
but it is what the definition says.

As for the attempt to enforce a particular and precise definition of a
term already in common (and thus usefully sloppy) use: There's value
in the attempt, so long as it's understood that the precise definition
will only be enforceable and understood within particular contexts.
This list is one of the those contexts for "open."

David W.

On Tue, Sep 13, 2011 at 1:41 PM, Peter Murray-Rust <pm286 at cam.ac.uk> wrote:
>
>
> On Tue, Sep 13, 2011 at 6:03 PM, Roy Tennant <tennantr at oclc.org> wrote:
>>
>> On 9/13/11 9/13/11 € 9:20 AM, "Jim Pitman" <pitman at stat.Berkeley.EDU>
>> wrote:
>>
>> > Either data is open, and it is possible to get hold of the entire
>> > dataset with a clear open license for what you can so with it. Or it is
>> > not
>> > open.
>>
>> Rather than sit back and allow David to be hoisted on his own petard, I
>> feel
>> it necessary to point out a few things. This list does not own the term
>> "open" and neither does it get to declare when the use of it is
>> appropriate.
>> You DO get to declare a set of terms around a specific use of it, such as
>> "open as defined by the Working Group on Open Bibliographic Data" but
>> that's
>> about it.
>
> The OKF has defined "Open Knowledge" in the Open Definition
>
>> The Open Knowledge Definition (OKD) sets out principles to define
>> ‘openness’ in knowledge – that’s any kind of content or data ‘from sonnets
>> to statistics, genes to geodata’. The definition can be summed up in the
>> statement that “A piece of content or data is open if anyone is free to use,
>> reuse, and redistribute it — subject only, at most, to the requirement to
>> attribute and share-alike.”.
>
> It is generally accepted on lists run by the OKF that "Open" refers to this
> definition.
>
> When using this concept elsewhere  I either capitalize it ("Open") or use
> "OKD-compliant" to make it clear that there is a formal definition.
>
> The lax use of "open" adds no value. If the word can be defined to mean
> whatever the author likes, then it is redundant (unless specifically
> defined). Thus there is no difference between:
>
> "the data are openly available"
> and
> "the data are available"
>
> There is great importance in defining what is meant by "open". The Open
> Source community has put great effort into this through the Open Source
> Initiative (http://www.opensource.org/ ). It has now been able to reach the
> stage where "Open Source" is universally understood as "OSI-compliant".
>
> By contrast the Open Access movement has taken a decade to converge on a
> practical definition of Open Access. This matters; if an author has to pay
> 3000 USD to have a paper regarded as Open Access it is important that we
> know what it means (and in many cases we still don't, precisely).
>>
>> This is also why the kind of discussion that might reveal the nuances of
>> "open" cannot happen here due to religious-style zealotry. If something
>> isn't "open" according to your strict standards it isn't open at all. This
>> completely misses the fact that "open" as in the Harvard API may be
>> completely fine and useful for nearly all real world purposes.
>
> This is not religious; it's practical. If we are going to use "open" as a
> useful label then it has to be defined. If people are going to pay money, or
> change their business model, then it should be crystal clear.
>
> "open" as in "the Harvard API" adds no information. Instead call it "the
> Harvard conditions" and point us at the place where they are PRECISELY
> defined. And precise definitions matter. If we do something that is not
> allowed we may end up being sued. If we don't know what is allowed then we
> either break the rules or are too afraid to do anything.
>
> The advantage of the OKD is that it is universal and almost always trivial
> to understand and implement. There may be cases where it isn't appropriate -
> fine - but in that case you should describe precsiely what you want and what
> you don't want. And that has to be explainable to everyone involved. The OSI
> found that writing your own licence was very complex and dangerous - so most
> people use an OSI-compliant licence
>
>>
>> If I can accomplish useful work with Harvard's API (and I likely can,
>> although I haven't yet tested it out), then great. Whether I can download
>> the entire dataset may be completely immaterial (and usually is) to
>> getting
>> that useful work accomplished. But then practicality isn't what this group
>> is about, it's about religion. Now I will go back to lurking, where I
>> expect
>> to take my lumps like a man. Wake me up again when you're ready to have
>> that
>> nuanced discussion.
>
> The OKF welcomes everyone - it is not relligious and very practical. Its
> definition is being adopted by publishers, funders, governments beacuse
> *they* need precise guidelines. For example it took two years' work to
> create the Panton Principles for Open Science data
> http://pantonprinciples.org/ and Open Access publishers such as Biomed
> Central are now adopting them because they are *useful*. The Open
> Bibliography principles follow the same philosophy. We believe they are
> useful in the same way.
>
> Please stay with us
>
> P.
>
> _______________________________________________
> open-bibliography mailing list
> open-bibliography at lists.okfn.org
> http://lists.okfn.org/mailman/listinfo/open-bibliography
>
>
>
> --
> Peter Murray-Rust
> Reader in Molecular Informatics
> Unilever Centre, Dep. Of Chemistry
> University of Cambridge
> CB2 1EW, UK
> +44-1223-763069
>
> _______________________________________________
> open-bibliography mailing list
> open-bibliography at lists.okfn.org
> http://lists.okfn.org/mailman/listinfo/open-bibliography
>
>