[ckan-discuss] Format / resource type dilemma

Richard Cyganiak richard at cyganiak.de
Mon Dec 5 14:32:53 GMT 2011


On 5 Dec 2011, at 12:49, Rufus Pollock wrote:
>> - File
>> - API
>> - Example
>> - Metadata
>> - Documentation
>> - Code
> 
> I'm with you on file, API, Example, and Code but not sure about
> Metadata or Documentation (Metadata is what is already in CKAN and
> shouldn't Documentation be in or reffed from notes section)?

Examples of the stuff that I can see going into Metadata:

- link to Google sitemap.xml 
- link to VoID file
- link to a SQL schema file that creates the necessary tables
- link to an XML schema or OWL ontology

(I'm not sure whether Metadata is such a great name for this, but none of this fits comfortably under File, API, Example or Code, IMO. All of these potentially enable specialized processing, so it's potentially helpful if clients can figure out that this isn't “just” a data file for download or a link to a black box.)

Regarding documentation, yes ideally it would be better if users linked those things in the Notes section. But many don't and simply plop documentation links into the Resources section as well. And I have to say, why not?

> I'd also like to add:
> 
> datapackage as an option for situation where we do have proper
> datapackage's as per the Data Package spec (now here):
> 
> <http://www.dataprotocols.org/en/latest/packages.html>

Shouldn't this be a “format” under the “file” type? If you make datapackage a type of its own, then what's its “format”?

One could even argue that datapackage should be a format under the “API” or “Metadata” types. At any rate, I'm not sure it needs its own top-level type.

> When finalized, all of this should merge into the spec for this field
> defined in the 'official' location, i.e.:
> 
> <http://wiki.ckan.org/Domain_Model/Resource>
> 
> (We could put some of this in the Discuss page there for future reference!)

I've added some links to the mail archive on the Discuss page there.

If you feel that any wiki page related to the conventions for using specific CKAN fields needs some wiki gardening, just let me know, I'm happy to help.

I mentioned this before, but I still believe that it is important to have “field help” links from the CKAN edit form into the wiki. This would be a way how conventions for the use of the fields could be shaped and promoted. There are already several places – in the wiki, in the mailing list archive, in off-site material created for specific groups – where such best practices and conventions for field use are discussed. But at the moment where they're needed – in the edit form – users have no way of finding them.

Best,
Richard


More information about the ckan-discuss mailing list