[ckan-discuss] Multiple package schemas

Thu Oct 7 09:03:02 BST 2010

On Oct 7, 2010, at 8:19 AM, Richard Cyganiak wrote:
> Hi Tim,
> 
> On 6 Oct 2010, at 22:53, Tim McNamara wrote:
>>> But 'schemas' still might want to modify the behaviour of some of the core
>>> fields:
>>> 
>>> - add a note underneath the field
>>> - provide a selection of choices for the resource format field
>>> - provide a number of checkboxes to add specific tags with special meenings
>>> - ...
>>> 
>> 
>> Would this level of flexibility be desirable?
> 
> The proposal above doesn't add flexibility, it *restricts* flexibility, by encouraging certain pre-defined values for formats and tags (which currently are completely unrestricted), and by providing additional documentation for fields that are currently not documented/explained at all in the form.
> 
> Please have a look at [1] -- this is how we currently ask people in the Linked Data community to contribute their work to CKAN. Being able to present all these guidelines directly in the form would be a *huge* step forward.

I think we now have several proposals that are similar: 

a) We might want to keep the main metadata fields the same for any package and add one more extras-based schema to the package upon entry. 

b) We might want to keep the metadata fields the same but then add a set of different "natures" (eclipse term) upon entry and at later points. 

c) We could make the whole form (including default fields) configurable. The mechanism for that (even per-package) already exists if you add the proper query parameters. While you can of course also modify the display page as well, I am a worried about the implications of having one CKAN instance with several semantics attached to fields of the same name in different packages. Isn't that the kind of ambiguity the linked data people are trying to get rid of?

If we're going to do that, why not run more instances of CKAN instead? At least then we can later use a more expressive method to integrate their metadata - doing lots of "if schema is X, then Y means Z" doesn't seem very attractive to me. 

We might want to consider reducing the number of default fields down to a minimum (and making things like authors, groups or even resources plugins), but those remaining should, IMO, then be set per-instance (and have a common meaning).

Friedrich 