[ckan-dev] Deprecated: related items (Apps & Ideas)

Fri Sep 11 21:06:28 UTC 2015

Once setup you'd like to load or register datasets in a catalogue. The data
will typically come from an external source of truth. Whether a DB or a
spreadsheet, or a harvest location. Moving/registering and maintaining the
currency of those datasets is best done with automation. This is where I
think the back end machine to machine use cases are extremely important.

>From a front end we already have resource views with embed scripts. This is
a great example of supporting another machine to machine integration point.
Although it sounds technically trivial, having a view on a data resource
embedded on any other website supports real time syndication of those views.

>From an open government perspective where transparency around government
business is important, I see the future of data catalogues as being the
window into operations. A place from which anyone can draw government
business intelligence. Government can build data triggers into every day
operations and publish these events into datasets in a similar way as
google analytics does for website events.

For example, Government can easily build simple web form integrations with
CKAN via any CMS to run public consultations where community feedback is
published in real time. This can make it more clear when lobbyist or
activist groups flood responses.

I'm a big supporter of machines as primary users, perhaps because I see
open data as a way to iteratively transform government operations by
showing where improvements can be made.

I'm working on how to grow these ideas around open referral, open 311 and
CKAN to provide open platforms for transparent and accessible government
operations. I think things are ready to come together quickly and the next
few years will see open data catalogues receive a lot of attention.

Cheers,
Steven

On Friday, September 11, 2015, David Read <david.read at hackneyworkshop.com>
wrote:

> Steven,
>
> Interesting! I'd love to believe it, but I struggle it is the case yet.
> People have long talked about machines accessing data catalogues, but
> actual use seems low. There's been various analyses of catalogues
> themselves, which is good, but of limited interest. And there is use in
> using the catalogue to provide a backup/cache of datasets en-masse. But
> it's problematic to automatically put quantities of datasets into databases
> due to poor CSVs, rareness of schemas etc. (although you could look at the
> well-curated catalogues or ones that require table-ification up-front like
> Socrata, or linked data for where this isn't so much a problem). And I
> imagine you could do some automatic "this dataset could be easily joined
> with this other dataset" discovery using a catalogue, or maybe discovering
> 2 properties in different datasets that correlate. But I kind of feel there
> should be something more achievable with machines and a data catalogue.
>
> Maybe I'm being glass-half-empty though... Do you have some ideas or
> examples you can share with us, about where data catalogues are going? Or
> was there something else behind this comment?
>
> Dave
>
> On 11 September 2015 at 13:06, Steven De Costa <
> steven.decosta at linkdigital.com.au
> <javascript:_e(%7B%7D,'cvml','steven.decosta at linkdigital.com.au');>>
> wrote:
>
>> +1 re 'as an aside' Machines are the primary users...
>>
>> *STEVEN DE COSTA *|
>> *EXECUTIVE DIRECTOR*www.linkdigital.com.au
>>
>>
>>
>> On 11 September 2015 at 21:32, David Read <david.read at hackneyworkshop.com
>> <javascript:_e(%7B%7D,'cvml','david.read at hackneyworkshop.com');>> wrote:
>>
>>> Carl,
>>>
>>> Related Items was not designed for relating datasets to other datasets,
>>> but I see that you could use it for that. There are two alternatives that
>>> you could use to replace it, though:
>>>
>>> 1. It would be simple to have an extra field instead. It's well
>>> documented how to add a field to the form & underlying schema and you just
>>> need to adjust the template to display it on the dataset page.
>>> 2. You could take advantage of the 'package relationships' model that
>>> exists in CKAN but has no UI. Again you need to adjust the form, schema &
>>> dataset view template.
>>>
>>> As an aside, I've struggled to find compelling use cases to show
>>> relationships between datasets. Some people talk about wanting to show
>>> 'parent/child' relationships, or 'related to' or 'is similar to'. But the
>>> nature of the relationship always seemed difficult to define clearly in a
>>> way that is useful for datasets en mass. I think they tend to be
>>> conveniences for the human user, rather than useful machine-readable
>>> metadata.
>>>
>>> So what might be more appropriate is to show next to a dataset other
>>> similar datasets, which is automatically filled based on similarity in the
>>> metadata record. So two with similar titles because they are about the same
>>> thing, would reference each other. As might two that share an ArcGIS layer.
>>>
>>> David
>>>
>>> On 11 September 2015 at 11:50, Carl Lange <carl at derilinx.com
>>> <javascript:_e(%7B%7D,'cvml','carl at derilinx.com');>> wrote:
>>>
>>>> Hi all,
>>>>
>>>> After deprecation, is there another feature planned to allow relation
>>>> of datasets to one another? For example, I have two datasets which are of
>>>> the same ArcGIS layer, and I'd like to 'relate' them so that end users are
>>>> able to see that they are connected at the source. Removing apps, dataviz
>>>> etc from this feature makes sense, but relating datasets is still a useful
>>>> feature.
>>>>
>>>> Cheers,
>>>> Carl
>>>>
>>>>
>>>> On 4 September 2015 at 14:21, Steven De Costa <
>>>> steven.decosta at linkdigital.com.au
>>>> <javascript:_e(%7B%7D,'cvml','steven.decosta at linkdigital.com.au');>>
>>>> wrote:
>>>>
>>>>> Thanks David!
>>>>>
>>>>> I really appreciate this notice AND the approach it represents. CKAN
>>>>> is an awesome data management system. I think it will retain this awesome
>>>>> status by remaining its focus on core workflows.
>>>>>
>>>>> The related data use cases is something of a content addition for what
>>>>> I'd say are tertiary users of CKAN. Primary are machines, secondary are
>>>>> data custodians.
>>>>>
>>>>> Having this as an extension makes more sense as CKAN continues to be
>>>>> adopted for Government open data, open research data and even open private
>>>>> sector data.
>>>>>
>>>>> Plus one and two thumbs up from me. And, big props to the developers
>>>>> contributing to the related use case extension as it is very cool :)
>>>>>
>>>>> Cheers,
>>>>> Steven
>>>>>
>>>>>
>>>>> On Friday, September 4, 2015, David Read <
>>>>> david.read at hackneyworkshop.com
>>>>> <javascript:_e(%7B%7D,'cvml','david.read at hackneyworkshop.com');>>
>>>>> wrote:
>>>>>
>>>>>> ! Warning for all CKAN admins !
>>>>>>
>>>>>> We will be removing the 'related items' feature in the next version of
>>>>>> CKAN (v2.5 expected around December). Several sites use this core ckan
>>>>>> feature to list "Apps" or "Apps & Ideas".
>>>>>>
>>>>>> It has been replaced by the ckanext-showcase extension, which allows
>>>>>> 'showcasing' apps, vizualizations, news items etc associated with
>>>>>> datasets. It includes a paster script to copy existing related items
>>>>>> into showcase ones. Since ckanext-showcase works with existing
>>>>>> versions of CKAN (2.3+), we suggest all sites migrate in advance of
>>>>>> the CKAN 2.5 release.
>>>>>>
>>>>>> https://github.com/ckan/ckanext-showcase
>>>>>>
>>>>>> David
>>>>>> _______________________________________________
>>>>>> ckan-dev mailing list
>>>>>> ckan-dev at lists.okfn.org
>>>>>> https://lists.okfn.org/mailman/listinfo/ckan-dev
>>>>>> Unsubscribe: https://lists.okfn.org/mailman/options/ckan-dev
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> *STEVEN DE COSTA *|
>>>>> *EXECUTIVE DIRECTOR*www.linkdigital.com.au
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> ckan-dev mailing list
>>>>> ckan-dev at lists.okfn.org
>>>>> <javascript:_e(%7B%7D,'cvml','ckan-dev at lists.okfn.org');>
>>>>> https://lists.okfn.org/mailman/listinfo/ckan-dev
>>>>> Unsubscribe: https://lists.okfn.org/mailman/options/ckan-dev
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> ckan-dev mailing list
>>>> ckan-dev at lists.okfn.org
>>>> <javascript:_e(%7B%7D,'cvml','ckan-dev at lists.okfn.org');>
>>>> https://lists.okfn.org/mailman/listinfo/ckan-dev
>>>> Unsubscribe: https://lists.okfn.org/mailman/options/ckan-dev
>>>>
>>>>
>>>
>>> _______________________________________________
>>> ckan-dev mailing list
>>> ckan-dev at lists.okfn.org
>>> <javascript:_e(%7B%7D,'cvml','ckan-dev at lists.okfn.org');>
>>> https://lists.okfn.org/mailman/listinfo/ckan-dev
>>> Unsubscribe: https://lists.okfn.org/mailman/options/ckan-dev
>>>
>>>
>>
>> _______________________________________________
>> ckan-dev mailing list
>> ckan-dev at lists.okfn.org
>> <javascript:_e(%7B%7D,'cvml','ckan-dev at lists.okfn.org');>
>> https://lists.okfn.org/mailman/listinfo/ckan-dev
>> Unsubscribe: https://lists.okfn.org/mailman/options/ckan-dev
>>
>>
>

-- 
*STEVEN DE COSTA *|
*EXECUTIVE DIRECTOR*www.linkdigital.com.au
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/ckan-dev/attachments/20150912/491d91ff/attachment-0003.html>