[ckan-discuss] Guidance for use of Author and Maintainer fields

[Glen Barnes]

On 28/07/2010, at 11:09 AM, Richard Cyganiak wrote:

> Hi Glen,
> 
> Your mail went only to my address and not to the list; I'm replying to the list, assuming it was sent only to me in error.

Yes - It was meant to go to the list.

> 
> On 27 Jul 2010, at 01:22, Glen Barnes wrote:
>> Good point. I'm dealing with the same issue now migrating the New Zealand Open Data Catalogue into the CKAN format.
>> 
>> As another example I have this dataset:
>> 
>> http://cat.open.org.nz/2010/04/13/auckland-google-transit-feed/
>> Contact Name: Paul Montague
>> 
>> Contact Phone: (09) 379 4422 x9072
>> 
>> Contact Email Address: paul.montague at arta.co.nz
>> 
>> And the 'owner' of the dataset is the Auckland Regional Transport Authority.
>> 
>> I think it would be good to review what the core fields are in the dataset and then look at how we can tag additional fields that may be common across instances.
> 
> +1.
> 
> I started to use a number of custom fields for the datasets that we're tracking for the Linking Open Data Cloud.
> 
> A first general question from my side would be, how to capitalize extension fields? And should words be separated by spaces, dashes, underscores? I've started to use all lower case with underscores, which looks great in the JSON output from the API, but slightly less great in the UI ;-) Should I go back and change these to something else? An example is "license_link" for custom licenses not covered in the Licenses dropdown on the package editing screen.

I think we should separate presentation from the data. Instances around the world will be displaying different data based on different needs so I would prefer to go for a lower cased, underscored, colon delimited format much like Open Street Map.

> 
>> Where would be the best place to start formulating these common tags?
> 
> Perhaps this wiki page should have a section on custom fields:
> http://wiki.okfn.org/ckan/doc/package
> 
> Rufus, is it ok if we just jump in here, add that section to that page, and just document a few extension fields that we find useful?
> 
> Or should we as a rule of thumb send such proposals to the list first, to see if there are objections?

The OSM method seems to work quite well. Essentially there are proposals for tags that can be discussed and then ratified as being official. We don't have to go down the whole voting route just yet but why don't we do this:

- Create a Metadata section that links to a metadata page.
- Have a list of agreed tags
- Have a list of discussion tags

We will quickly come up with list of commonly used tags and we can refine based on future usage. We can then work on the presentation layer for these tags, for example one of my first recommendations would be an external uses set of tags to create links to uses of the data "in the wild":

external_use:=zoodle
external_use:url=http://www.zoodle.co.nz 
external_use:description=NZ Governement data is used to show property information on a map and combined with other  proprietary data 
external_use:organisation=Zoodle Limited
external_use:screenshot(s)=http://some/url
external_use:thumbnail=http://some/url

This will look pretty ugly in the default layout but once a tag gains traction we can build this into the UI so we start to make these package pages look great.

And one thing on the above example. Can we group these tags together? i.e one dataset can have many external_use's how can we group these when creating or updating a dataset?