[ckan-discuss] Multiple package schemas

[Richard Cyganiak]

Hi David,

Good proposal. I think this would work very well for the LOD use case.

It is important to make sure that the package type really just affects  
the display of the form, and that changing the type doesn't actually  
affect any data. Care has to be taken to communicate that in the UI as  
well.

There is a potential pitfall. For some packages, the correct type  
would not be obvious. For example, some of the data.gov.uk packages  
might conceivably use the LOD form, and a hypothetical custom “UK  
government data” form. With the proposed solution, users would  
probably be tempted to create two different packages for what is  
essentially the same data.

One way around this would be to make the custom forms *extensions* of  
the default form. In that case, the edit page for our data.gov.uk  
package would show the default form, and below that the LOD extended  
form, and below that the UK Gov extended form. The problem though is  
that the LOD form would probably “modify” some default form field,  
e.g., seed the Resources/Format field with a selection of default  
values (api/sparql, application/rdf+xml and so on).

But maybe that is just an unlikely corner case.

Best,
Richard


On 6 Oct 2010, at 17:51, David Read wrote:

> Dear all,
>
> We are starting to need to allow different *sorts* of packages, each
> with particular metadata fields. This allows package editors use a
> more suitable form than the 'standard' one, and in the future we can
> display different packages according to their schema too. Below I
> outline a proposal to extend the UI and API - do let me know what you
> think there are potetial pitfalls or other issues or solutions come to
> mind.
>
> David
>
> Intro:
> Packages have 'extra' fields which allows users to freely extend the
> package metadata. Now we are seeing groups of packages all wanting to
> use the same 'extra' fields and structure that data. Structuring the
> data is of course good. For a couple of CKAN customers we've
> customised the package edit form to show these 'extra' fields and
> provide validation, and the next logical step is to allow people to
> have multiple forms per CKAN instance.
>
> Example:
> LOD packages are automatically turned into the LOD cloud diagram. LOD
> packages are on CKAN.net which is needs to keep the general form, but
> a LOD specific form would be beneficial, to replace the extensive
> guidelines stored externally:
> http://esw.w3.org/TaskForces/CommunityProjects/LinkingOpenData/DataSets/CKANmetainformation
>
> Use cases:
> A user wants to create a new LOD package.
> A user wants to move a standard package to/from the LOD schema.
> Future:
> Users can view each LOD package in a 'package read' page customised  
> for LOD.
>
> Proposed solution:
> * A new extra field 'schema' stores the schema name if not the
> standard one. e.g. schema=lod
> * The package/new and package/edit forms have a combo box at the top
> where you select the schema and a (form submit) 'change' button.
> * When you change the schema the form changes, (but no data is
> changed, allowing you to reverse your changes having not lost any
> 'extra' data.)
> (* Schema forms can either include the free-form 'extra' fields, or
> not, in which case any non-showing extra fields are not affected by
> submitting the form.)
> * The form API is extended to provide the same facility:
>    /form/schema - a new register listing available schemas (for the  
> combo box)
>    /form/package/create?schema=lod - the new parameter allows you to
> select a form schema
>    /form/package/edit/PACKAGE-REF?schema=lod - if you want to edit
> with a new schema
>
> _______________________________________________
> ckan-discuss mailing list
> ckan-discuss at lists.okfn.org
> http://lists.okfn.org/mailman/listinfo/ckan-discuss