Re: Excel??!!

Part of the problem here is that we have an incomplete sentence in BP8. I don’t think we need to add a BP to deal with this issue, since we already have BP9. (We need both because one is a MUST and one is a SHOULD.) I think we could be silent about it in BP8, and then give BP9 a stronger intended outcome. I suggest we change the possible approach of BP8 to

“Consider which data formats potential users of the data are most likely to have the necessary tools to parse. Common solutions include but are not limited to JSON, CSV, XML, and RDF.”

NOTE: I took out NetCDF, since it’s not all that common outside scientific computing. I want to remove the sentence about enabling machines to better process the data.

Then we should change the intended outcome of BP9 to

“Data SHOULD be available to intended users in nonproprietary formats whenever practical. A proprietary format MAY be used when it is the preferred option for the majority of expected consumers of the data.”

-Annette
--
Annette Greiner
NERSC Data and Analytics Services
Lawrence Berkeley National Laboratory
510-495-2935

On Jan 22, 2015, at 12:22 PM, Carlos Iglesias <contact@carlosiglesias.es> wrote:

> Indeed removing XLS for being a proprietary format (I also suggest to replace by ODS then) is a little bit inconsistent with leaving " to have the necessary tools to parse proprietary or (preferably) non-proprietary data formats" in the text. 
> On the other hand, there are certain proprietary formats that are industry de-facto standards and have no clear replacement (e.g. SHP). Then, what about splitting this in too, one BP about machine-readable and standardized formats and other about non-proprietary formats?
> 
> Best,
>  CI.
> 
> On 22 January 2015 at 20:42, Annette Greiner <amgreiner@lbl.gov> wrote:
> I’m fine with removing Excel. Perhaps we should remove the reference to proprietary formats, too. I think it would be acceptable to use a proprietary format in the case where the vast majority of users would prefer it, but that is a pretty unlikely case. Using nonproprietary formats seems to me the general best practice. A format like Excel can readily be converted to something nonproprietary, like CSV.
> 
> A couple sentences got smashed together as well. And now that I think of it, I don’t think we should mention vocabularies here. That is covered way too much elsewhere already. In fact, that last sentence “Standard data formats as well as the . . .” is redundant with the “Why”. I think we should just remove it.
> 
> The intended outcome was rewritten and should read:
> "Published data on the web must be readable and processable by typical computing systems. Any data consumer who wishes to work with the data and is authorized to do so must be able to do so with computational tools typically available in the relevant domain."
> 
> -Annette
> 
> --
> Annette Greiner
> NERSC Data and Analytics Services
> Lawrence Berkeley National Laboratory
> 510-495-2935
> 
> On Jan 22, 2015, at 4:05 AM, Phil Archer <phila@w3.org> wrote:
> 
> > Hi,
> >
> > I just noticed that the BP "Use machine-readable standardized data formats" included this:
> >
> > "Consider which data formats potential users of the data are most likely to have the necessary tools to parse proprietary or (preferably) non-proprietary data formats, including but not limited to MS Excel, CSV, NetCDF, XML, JSON and RDF. Standard data formats as well as the use of standard data vocabularies will better enable machines to process the data."
> >
> >
> > No no no no no no no
> >
> > Microsoft Excel is a proprietary format that has no place in a W3C standards document. I have removed it.
> >
> > True, MSFT 'gave' the standard to ISO but it's not an open standard in terms of the way it was developed and is effectively a proprietary one.
> >
> >
> > For tracker: ISSUE-67
> >
> >
> > --
> >
> >
> > Phil Archer
> > W3C Data Activity Lead
> > http://www.w3.org/2013/data/
> >
> > http://philarcher.org
> > +44 (0)7887 767755
> > @philarcher1
> >
> 
> 
> 
> 
> 
> -- 
> ---
> 
> Carlos Iglesias. 
> Internet & Web Consultant.
> +34 687 917 759 
> contact@carlosiglesias.es 
> @carlosiglesias 
> http://es.linkedin.com/in/carlosiglesiasmoro/en