Re: DCAT: Describing APIs

If I understand Stuart's point, APIs --- let's consider only those for
accessing data --- "often" are listed as if they are downloadable
datasets in dataset catalogs. A couple things:

* DCAT is about datasets and catalogs of datasets. There are no plans
to extend DCAT to cover "catalogs of datasets and other stuff" (ie
arbitrary APIs)
* If an API is used to access a dataset, the proper way to use DCAT is
to describe that dataset and list the API as the means for accessing
the data
* The means for providing a detailed description of the API is beyond
the scope of DCAT, but we should consider an optional property or
properties for linking to some resolvable description, possibly
including format, protocol and "API Home" (see for example
http://bit.ly/16yN0DL )
* Nothing in the current DCAT prevents it from being extended as
needed. The question is, is this case sufficiently common to warrant
changing this last call draft. Please provide some real use cases from
the wild to make the point...

John

On Thu, Apr 4, 2013 at 2:16 AM, Stuart Harrison
<stuart.harrison@theodi.org> wrote:
> Hi,
>
> I've just had a look at DCAT, and, as someone who's tried to maintain and
> submit to government data catalogues in the past, it looks really
> comprehensive.
>
> The only thing I can see which may be missing is how we describe APIs -
> these often end up in data catalogues (rightly or wrongly), and, as they're
> being constantly updated, a lot of things like dct:updated would be
> meaningless. Are there any plans to add a description for an API, or any
> other constantly updating dataset?
>
> Cheers
>
> --
> Stuart Harrison
> Web Developer
> Open Data Institute
>
> Sent with Sparrow
>



-- 
John S. Erickson, Ph.D.
Director, Web Science Operations
Tetherless World Constellation (RPI)
<http://tw.rpi.edu> <olyerickson@gmail.com>
Twitter & Skype: olyerickson

Received on Thursday, 4 April 2013 13:58:04 UTC