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

[Rufus Pollock]

On 28 July 2010 02:43, Glen Barnes <glen at opengovt.org.nz> wrote:
> On 28/07/2010, at 11:09 AM, Richard Cyganiak wrote:
[...]
>> 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.

I agree with  both of you here. I think we should converge or a
standard formatting for extra field keys. Following both suggestions,
what about:

1. lowercase
2. underscore
3. ':' separation for prefixing (more on this in response to will waites below)

On presentation we could have a general rule that we then prettity
this in the web user interface when presenting the read view e.g.
license_link -> "License link" (though would not want to confuse
users)

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

Sounds very sensible.

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

I think we should probably also distinguish in our terminology between
"tags" and "extras" (i.e. extension fields).

> 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

That's a really nice idea. BTW are these intended to be 'tags' (as in
the tags field) or for the "extras" field.

For tags we should really work out our standardization. Up until now
we have used a rather hacky approach of key-value e.g. country-uk.
This should clearly change since '-' gets used in "normal" tags.
Options:

1. key.value (or namespace:key.value) e.g. country.uk or
external_use:organisation.Zoodle-limited
3. Flickr machine tag (your example above): namespace:key=value
For tags, up until now we have been reluctant to use ':' as it is
invalid in the url, but given

One reluctance for full machine tags (which was suggested to us 3y ago
in fact by a flickr chap) was issue of ':' being invalid in urls.
However flickr seem to survive just fine with:

http://www.flickr.com/photos/tags/exif:*=

(How do they do this or is just browsers being liberal? Also how will
this fly with RDF which seems to be quite strict about valid uris ...)

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

Indeed.

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

All good questions. At this level of multiplicity we may really need
an alternative approach (which leads on to will waites).

Rufus
-- 
Open Knowledge Foundation
Promoting Open Knowledge in a Digital Age
http://www.okfn.org/ - http://blog.okfn.org/