Re: DCAT: Describing APIs

Stuart and Vasily's points ring true, however, DCAT's primary scope is 
to make different catalogs interoperable, comparable and tractable  with 
respect to each other, not to enable machine consumption of data within 
datasets.

Describing APIs would require the deployment of serious extensions to 
the existing schema. It would have to cater for the majority of 
different types of endpoints, APIs etc. which would make it rather 
unrealistic to expect to be able to describe every arbitrary/custom API 
out there (not just the usual stuff).

Moreover, it would discourage people from using DCAT if they have custom 
distribution methods or any kind of access method that is for some 
reason more complex. Processes like automated machine access would only 
work in some, but not all cases, thus making the whole approach 
inconsistent.

However I would like to express this concern: things get a bit more 
complicated semantically because of the dcat:downloadURL property, 
because this provides an unambiguous access method description when the 
dataset is downloadable (i.e. the dataset can be downloaded from the 
specified URL). Doesn't this make DCAT biased on the accessibility of 
downloadable resources?

In any case, I do believe that DCAT should provide a means to link a 
particular dcat:Distribution to an external concept that describes its 
access rules and methods, in a similar way that ORG uses 
org:classification to link organizations to external classification 
schemata, taxonomies etc.


Kind regards,
Marios Meimaris
Research Associate, NTUA
skype:marios3280

On 04/04/2013 16:57, John Erickson wrote:
> 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
>>
>
>