- From: Jakub Klímek via GitHub <sysbot+gh@w3.org>
- Date: Thu, 28 Jun 2018 10:48:15 +0000
- To: public-dxwg-wg@w3.org
@dr-shorthair A note to your comment in the email summary of the issue: > If the content is simple then the “+zip” strategy on the media-type designator is OK I disagree. 1. Some media types already have an extension, e.g. `application/ld+json` and a media type cannot have 2 extensions 2. The `+zip` media type extension indicates the ZIP technique (`application/zip`), which is only one of many 3. It would be an extra place to look for information about compression. 4. What is a simple content and what is a complex content? > This is a potential rabbit hole, too many layers is impractical Sure, too many layers are impractical, but I was proposing a quite simple solution to common (not all) situations, i.e. compressed file, packaged homogeneous files, and their combination. This also covers a compressed file with a standardized directory structure such as a Data Package. @arminhaller Regarding your point in the minutes: > What about a compressed file that contains ttl, n3 and rdf/xml files that are all equivalent These should be 3 `dcat:Distribution`s, e.g. one for `.ttl.gz`, one for `.nt.gz` and one for `.rdf.gz`. @andrea-perego Regarding your point in the minutes: > for standard nested formats we don't need to do anything We still need the proposed extension for the common situations. > if nesting is done in an arbitrary way, a readme file within the structure should be used Primary focus should be on machine readability. In cases something non-standard is used as a distribution, it should be in case where no standard DCAT ways are applicable and this should be documented in the datasets description and documentation. -- GitHub Notification of comment by jakubklimek Please view or discuss this issue at https://github.com/w3c/dxwg/issues/259#issuecomment-400994402 using your GitHub account
Received on Thursday, 28 June 2018 10:48:25 UTC