[ckan-discuss] Format / resource type dilemma

[Pablo Mendes]

I support Richard's proposal. If the values were in a dropdown, people
would likely find themselves more easily.

Wondering now if it's worth further slicing the orthogonality in the
resource types.

Resource type:
- File
- API
- Code
- Metadata

Intended use
- Example item
- Bulk access
- Documentation

That way, you can have a file with an example item, or a file with bulk
download. Documentation for an API or documentation for code, etc. An
example linked data resource URI could be provided by a file or an 'API'
(codeword for conneg)

This may be an overkill ,and the model is not as clean as it could be ,but
I'm in transit and decided for a half-baked thought over no input at all.

Cheers
Pablo
On Dec 1, 2011 6:33 PM, "Richard Cyganiak" <richard at cyganiak.de> wrote:

> 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
> _______________________________________________
> ckan-discuss mailing list
> ckan-discuss at lists.okfn.org
> http://lists.okfn.org/mailman/listinfo/ckan-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/ckan-discuss/attachments/20111202/2fe3aa82/attachment.htm>