[ckan-discuss] Multiple package schemas

[David Read]

There have been plenty of calls for adding explanation text to the
package form and that's something I'm now doing. I agree with
Friedrich that a field's meaning should not change between schemas.
Richard's guidance doesn't contradict any of our core field guidance,
apart from in these cases:

* he gives more specific instructions for a couple of the resource
fields the format field has suggested values like
"application/rdf+xml" which is in fact two pieces of data - the
purpose of the download (e.g. the application, an example, meta-info,
download_page) and the format itself. These would be better in
separate columns.

 * he suggests adding a number of tags according to the properties of
the package. I think these would be better stored as extra fields, as
the answer to these questions is often yes/no or "hasn't be answered
yet", which is preferable to looking at the presence or otherwise of a
tag such as "lodcloud.nolinks", or having a pair of tags like
"provenance-metadata" / "no-provenance-metadata". Indeed tags like
"format-rdf" match even closer to an extra field "format"="rdf". I
think he (and others) have chosen tags over extra fields, because tags
are easier to browse/search on CKAN. So we would need to make it as
easy to browse by these extra fields as it is for them as tags.

If we resolved these two points, I think the LOD use case would
suggest a schema that just describes extra fields.

David

On 6 October 2010 22:53, Tim McNamara <paperless at timmcnamara.co.nz> wrote:
> On 7 October 2010 06:58, Richard Cyganiak <richard at cyganiak.de> wrote:
>>
>> On 6 Oct 2010, at 18:17, David Read wrote:
>>>
>>> Excellent point. Yes, maybe we want a 'schema' to merely define
>>> specific 'extra' fields, with their validation and later their
>>> display. Then you could have a package having several 'schemas' quite
>>> simply. The core package fields then wouldn't be affect by any of
>>> this.
>>
>> 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? It may it things very
> difficult to build applications on the basis of CKAN's packages if they have
> different structures. I prefer the idea of a common set of information that
> is fixed with possible extensions. I think there should be a strong
> community push to keep to the common set unless there are compelling reasons
> (necessity) to add an extension.
>
> Tim.
>