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

Fri Sep 11 22:41:01 UTC 2015

FYI - I've opened up this discussion within the Australian group on the
OKFN discussion forum. I thought I'd test the thinking and get some wider
views on what folks would like to see from open Government data (not to
diminish the needs of those who implement CKAN for research data, regional
development initiatives, private information asset registers, etc.).

The thread is here:
https://discuss.okfn.org/t/open-government-data-where-to-next/1156

*STEVEN DE COSTA *|
*EXECUTIVE DIRECTOR*www.linkdigital.com.au

On 12 September 2015 at 07:06, Steven De Costa <
steven.decosta at linkdigital.com.au> wrote:

> 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> 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> 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> 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> 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> 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
>>>>>> 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
>>>>> 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
>>>> 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
>>> 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/266c499d/attachment-0003.html>