[od-discuss] Machine readability in v2.1

Aaron Wolf wolftune at riseup.net
Sun Aug 2 23:16:11 UTC 2015



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"?

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



More information about the od-discuss mailing list