Re: Finding Metadata for CSV Files

 > On 09/03/14 15:07, Jeni Tennison wrote:
 > > From: Andy Seaborne andy@apache.org Date: 9 March 2014
 > > at 10:33:57:
 > >> 5. (no advocacy) Naming convention : if there is a "data.csv"
 > >> then the metadata is adjacent under "data.csv.json"
 > >> or somesuch.
[ . . . ]
 > > Yes, that would be an alternative, but I don’t think we
 > > should include it as an approach in a Recommendation. It
 > > runs counter to the arguments in
 > >
 > > http://tools.ietf.org/html/draft-ietf-appsawg-uri-get-off-my-lawn-01
 > >
 > > that caution against a protocol that specifies a particular
 > > URL path.
 >
 > The cat is already out of the bag on that one!
 >
 > http://central.maven.org/maven2/org/json/json/20140107/
 >
 > json-20140107.jar
 >
 > implies
 >
 > json-20140107.jar.md5 etc

Agreed.  And even from a WebArch perspective, I don't think a convention 
like data.csv.json would be bad if it were treated as a *heuristic*. 
The WebArch issue is that you don't want to impinge on the server 
owner's right to associate any URI (that he/she owns) with any resource. 
   But if data.csv.json had to contain an *explicit* statement 
indicating that it held metadata for data.csv, in order for it to be 
authoritatively considered metadata for data.csv, then this WebArch 
principle would not be violated, because the server owner could still 
use the data.csv.json URI for a completely different purpose without harm.

In other words, the rule could be something like: "If you find data.csv, 
see if there's a data.csv.json.   If there is, *and* it explicitly says 
that it is metadata about data.csv, then treat it as such."

Bottom line: I think this is option should be seriously considered 
(though not to the exclusion of others as well!) as a simple, practical 
way by which anyone could associate metadata with their CSV files, 
without requiring changes to the software that generates those CSV 
files, and without requiring any special server configuration.

David

Received on Thursday, 13 March 2014 18:57:01 UTC