[ckan-discuss] Multiple package schemas

[David Read]

Richard,

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.

David

On 6 October 2010 18:07, Richard Cyganiak <richard at cyganiak.de> wrote:
> 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
>
>