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

Mon Sep 14 09:09:31 UTC 2015

Thanks Steven - these are all excellent points about machine interactions
with CKAN.

Exposing the workings of government via live data makes sense, and CKAN's
datastore is a decent enough way to do this. The UK has handy dashboards
like this:
https://www.gov.uk/performance/tax-disc
(although it is on a separate platform) The number of vehicle tax renewals
is shown monthly - maybe you could argue the benefits of publishing this
daily or hourly. I guess some people would want more detailed management
information about the inner workings of a system, but I guess at some point
you'd accuse the public of wanting to micro-manage offices.

Dave

On 11 September 2015 at 22: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
>
>
>
>
> _______________________________________________
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/ckan-dev/attachments/20150914/49af3c04/attachment-0003.html>