[od-discuss] Open Definition category created on Discuss.

Sun Aug 9 02:53:38 UTC 2015

Hello,

I’ve created a category for the Open Definition on the Open Knowledge Discussion Forum,  https://discuss.okfn.org/c/OpenDefinition <https://discuss.okfn.org/c/OpenDefinition>

I find the email discussion forum difficult to follow and I hope you consider moving the conversation over like many other Open Knowledge working groups have.

I will send some people invitations to the forum but don’t let that slow you down. You can sign up yourself and after having a look around and reading some posts your user privileges automatically increase. 

You may like to start by introducing yourself on the New Members topic https://discuss.okfn.org/t/new-member-introductions/73 <https://discuss.okfn.org/t/new-member-introductions/73> 

Stephen Gates

> On 5 Aug 2015, at 10:00 pm, od-discuss-request at lists.okfn.org wrote:
> 
> Send od-discuss mailing list submissions to
> 	od-discuss at lists.okfn.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://lists.okfn.org/mailman/listinfo/od-discuss
> or, via email, send a message with subject or body 'help' to
> 	od-discuss-request at lists.okfn.org
> 
> You can reach the person managing the list at
> 	od-discuss-owner at lists.okfn.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of od-discuss digest..."
> Today's Topics:
> 
>   1. Re: Machine readability in v2.1 (Rufus Pollock)
> 
> From: Rufus Pollock <rufus.pollock at okfn.org>
> Subject: Re: [od-discuss] Machine readability in v2.1
> Date: 5 August 2015 4:12:52 am AEST
> To: Aaron Wolf <wolftune at riseup.net>
> Cc: "od-discuss at lists.okfn.org" <od-discuss at lists.okfn.org>, Unname <b.ooghe at gmail.com>
> 
> 
> 
> 
> On 3 August 2015 at 00:16, Aaron Wolf <wolftune at riseup.net <mailto:wolftune at riseup.net>> wrote:
> 
> 
> On 08/02/2015 04:08 PM, Benjamin Ooghe-Tabanou wrote:
> > Hello everyone, and thanks to Rufus, Aaron, Peter, Stephen and both
> > Andrews for your contributions. I feel like we're progressing here !
> > :)
> >
> > Although I liked Rufus' proposal completed with Andrew's suggestion, I
> > think I prefer Aaron's latest version.
> >
> > It really reduces the 1.3 to what it really concerns and the phrasing
> > of 1.4 seems stronger to me :
> > - as expressed by many, "machine readable" and "fully processed" were
> > still blurry and could be badly interpreted. With
> > "machine-processable" and "working with and/or modifying the
> > individual
> > data or content elements" i feel like this adresses most cases
> > - using MUST instead of SHOULD sounds necessary to me and was my issue
> > with Rufus' version. This version places a MUST whereas it restricts
> > it to specific works that are data, which feels stronger
> > - always in favor of referring to FLOS and open formats
> >
> > I'm just not completely sure about the "although best " and "readily
> > available upon request" parts: if it exists in such form, i guess it
> > must be provided as such, so why not reverse it as something like
> > this:
> >
> > 1.4 Machine Processable Form Available
> > « When the **work** is fitted for working with and/or modifying its
> > individual data or content elements, it *must* at least be provided in
> > a "machine-processable" open format that permits such process. »
> >
> > Best,
> > Benjamin
> >
> > PS: Just missing the be in "work must BE provided" of Aaron's 1.3
> >
> 
> 
> The problems with the "must be provided as such" approach:
> 
> If I make a music recording and put it online under CC-BY-SA, are we
> going to say it is "non-open" because I didn't directly *include* all
> the source files (different tracks and such) in the exact same download
> / web page with the final mix? Furthermore, say I *do* make the source
> files available, but someone else shares the song with their friends and
> doesn't include all the source files. Is their distribution "non-open"?
> 
> This is a subtle area. A distinction that is useful from the Database world is useful here: the concept of "produced work". For example, a map tile rendered from underlying geodata is a "produced work". Similarly, one would say a "chart" or a "paper" are a produced work for some underlying data.
> 
> Right now, should we focus on the "openness" of the object itself, or, if it is a produced work also require the openness of the underlying material.
> 
> Consider a chart: it is a produced work if rendered from data. I think the purpose matters here: if the chart is provided *as* the data (and the raw data is not provided) then it is not open. If the chart is produced as an image for visual consumption then maybe it is.
> 
> For data I don't think this is such a big issue since its clear you have to provide it in processable form. For content: music, pictures etc it may be a little more blurry.
> 
> Overall I think it is reasonably clear.
> 
> Rufus
>  
> Same issues for data even… say I create a new analysis of data from a
> government. Do I *have* to include all the data itself directly hosted /
> downloaded alongside the article I publish? Is it not enough to just
> include in my article a link to where I got the data?
> 
> I'm not settled on these things, I think there could be arguments for
> both yes and no for those questions. My inclination was to have a
> *should* / encouragement for actually including all the source files
> directly but a requirement to provide the source (directly or
> indirectly, as long as effectively) upon request…
> 
> I really don't want anyone to answer these questions *without*
> considering the case of *redistribution*. It appears that some people
> are thinking about how required this should be and considering only
> primary sources distributing and not questions of further dissemination.
> 
> Otherwise, I think my wording might be strong enough to open as a pull
> request but potentially edit from there…
> 
> Cheers,
> Aaron
> 
> >
> > On Wed, Jul 29, 2015 at 3:40 PM, Aaron Wolf <wolftune at riseup.net <mailto:wolftune at riseup.net>> wrote:
> >>
> >>
> >> On 07/29/2015 08:14 AM, Rufus Pollock wrote:
> >>> Good suggested amendment Andrew. To summarize:
> >>>
> >>> 1.4 Machine Readability____
> >>>
> >>> __ __
> >>>
> >>> The work should be provided in "machine-readable" form, that is one in
> >>> which the content can easily be accessed and processed by a computer,
> >>> and which is in form in which modifications to individual data/content
> >>> elements can easily be performed.
> >>>
> >>>
> >>> Rufus
> >>>
> >>>
> >>
> >> My suggested variations:
> >>
> >> 1.3 Open Format
> >>
> >> "The **work** *must* provided in an open format. An open format is one
> >> which places no restrictions, monetary or otherwise, upon its use and
> >> can be fully read by at least one free/libre/open-source software tool."
> >>
> >> 1.4 Machine Processable Form Available
> >>
> >> "Although best when included by default, the **work** *must* at least be
> >> readily available upon request in a "machine-processable" open format
> >> that is appropriate for working with and/or modifying the individual
> >> data or content elements."
> >>
> >> A lot of details are incorporated here in my specific wording which aims
> >> to capture many different concerns (I went through several edits to get
> >> to this point).
> >>
> >> The gist here is:
> >>
> >> * split 1.3 into two sections: 1.3 now emphaiszes a minimal open format
> >> for distribution (e.g. non-DRM'ed PDF is okay for normal distribution,
> >> proprietary formats are not) while 1.4 specifies the *availability* of
> >> machine-processable data. Like with software, this says that binaries,
> >> i.e. human-readable renderings are still "open" if they include
> >> information about how to access the machine-processable data.
> >>
> >> * Instead of just "computer" I think both issues need to emphasize FLO
> >> software, and rather than too much redundancy, mentioning "open format"
> >> in 1.4 seems functional.
> >>
> >> * I added wording that better generalized the issues: "working with and
> >> modifying" (analyzing data isn't about modifying it).
> >>
> >> * This changes "should" into "must" for at least the *availability* of
> >> the preferred source form for working-with/modifying. The only "should"
> >> or "preferable" that is left is the inclusion of the source files by
> >> default (as opposed to by request). Thus, this is a stronger requirement
> >> for "machine readable data" but does not make the plain distribution of
> >> rendered, human-readable forms automatically "non-open".
> >>
> >> My wording may not be final, but the gist of these changes conceptually
> >> make sense and should go forward. We could add something vague like "the
> >> data or content elements vary based on the type of work". We could also
> >> specify more about what "readily available upon request" entails if
> >> necessary.
> >>
> >> Best,
> >> Aaron
> >>
> >> _______________________________________________
> >> od-discuss mailing list
> >> od-discuss at lists.okfn.org <mailto:od-discuss at lists.okfn.org>
> >> https://lists.okfn.org/mailman/listinfo/od-discuss <https://lists.okfn.org/mailman/listinfo/od-discuss>
> >> Unsubscribe: https://lists.okfn.org/mailman/options/od-discuss <https://lists.okfn.org/mailman/options/od-discuss>
> 
> --
> Aaron Wolf
> co-founder, Snowdrift.coop
> music teacher, wolftune.com <http://wolftune.com/>
> _______________________________________________
> od-discuss mailing list
> od-discuss at lists.okfn.org <mailto:od-discuss at lists.okfn.org>
> https://lists.okfn.org/mailman/listinfo/od-discuss <https://lists.okfn.org/mailman/listinfo/od-discuss>
> Unsubscribe: https://lists.okfn.org/mailman/options/od-discuss <https://lists.okfn.org/mailman/options/od-discuss>
> 
> 
> 
> -- 
> Rufus Pollock
> Founder and President  |  skype: rufuspollock  |  @rufuspollock <https://twitter.com/rufuspollock>
> Open Knowledge <http://okfn.org/> - see how data can change the world
> http://okfn.org/ <http://okfn.org/>  |  @okfn <http://twitter.com/OKFN>  |  Open Knowledge on Facebook <https://www.facebook.com/OKFNetwork>  |  Blog <http://blog.okfn.org/>
> 
> _______________________________________________
> od-discuss mailing list
> od-discuss at lists.okfn.org
> https://lists.okfn.org/mailman/listinfo/od-discuss
> Unsubscribe: https://lists.okfn.org/mailman/options/od-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/od-discuss/attachments/20150809/6698acde/attachment-0002.html>