[ckan-discuss] Format / resource type dilemma

Uros Milosevic uros.milosevic at pupin.rs
Fri Dec 2 09:48:29 GMT 2011


Thanks, both of you.

@David Unfortunately, we don't have direct access to the XML/XLS/PDF files. They're all generated on the fly and the export function's called through JavaScript.

Although I do understand that the "proper" way to do it would be to link to the page and use index/html for the format field, I'm afraid that this could be misleading, since the real value of these resources lies in the machine readable data that would be visible only after visiting the attached link. Moreover, there could be other resources out there with a similar problem, and not only web pages (e.g. ZIP archives). Therefore, my question is, how do we tell users there's (more important) data behind the linked data? Should we, simply, mention it in the resource description? Is there room for an additional format/resource type (or even a field) that would indicate this?

Best,
Uros



-----Original Message-----
From: Richard Cyganiak [mailto:richard at cyganiak.de] 
Sent: Thursday, December 01, 2011 6:33 PM
To: David Read
Cc: Uros Milosevic; Rufus Pollock; ckan-discuss at lists.okfn.org
Subject: Re: [ckan-discuss] Format / resource type dilemma

On 30 Nov 2011, at 12:48, David Read wrote:
> @Rufus can you say what the intention is for 'resource type'?

I'm going to throw in my €0.02 here…

I'd like to see this field hardcoded to have the following values:

- File
- API
- Example
- Metadata
- Documentation
- Code

In the case of an RDF dataset, this might be used as follows:

- zipped download of the entire RDF dump: “file”
- SPARQL endpoint: “api”
- a resolvable URI pointing to one example resource: “example”
- an associated RDF Schema file: “metadata”
- a PDF white paper describing the dataset: “docs”
- the link to the GitHub project page: “code”

Best,
Richard=




More information about the ckan-discuss mailing list