[ckan-discuss] Multiple package schemas

[Richard Cyganiak]

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
- ...

Best,
Richard


>
> 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
>>
>>