[od-discuss] Machine readability in v2.1

Tue Aug 4 18:12:52 UTC 2015

On 3 August 2015 at 00:16, Aaron Wolf <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> 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
> >> https://lists.okfn.org/mailman/listinfo/od-discuss
> >> Unsubscribe: https://lists.okfn.org/mailman/options/od-discuss
>
> --
> Aaron Wolf
> co-founder, Snowdrift.coop
> music teacher, wolftune.com
> _______________________________________________
> 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
>

-- 

*Rufus PollockFounder 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/>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/od-discuss/attachments/20150804/19c7b4af/attachment-0003.html>