DXWG DCAT subgroup teleconference 23 January 2019 21:00 UTC

23 January 2019

Meeting minutes


Confirm agenda

DaveBrowning: do we need any changes?
… we need to discuss the issue around data services

SimonCox: there are a number of PRs that are lurking and ready to go
… the one associated with annette_g's questions is one of those
… so it'd be good to know if we can move forward or not

DaveBrowning: we move this issue first?


<SimonCox> https://‌github.com/‌w3c/‌dxwg/‌pulls?q=is%3Aopen+is%3Apr+label%3Adcat

<riccardoAlbertoni> +1

+1 to move this issue up

<AndreaPerego> +1

minutes of the last meeting

<AndreaPerego> +1


<SimonCox> +1 to minutes

<PWinstanley> +1

<Makx> +0 was not there

+1 to minutes

<riccardoAlbertoni> +1 to minutes

<DaveBrowning> +1

Resolved: minutes approved

Review pull requests


<PWinstanley> alejandra: just to mention that I'm still working on mine - text explaining better DCAT

<PWinstanley> .... I'll push very soon

SimonCox: will this be ready in a day or two?

alejandra: yes

DaveBrowning: this one https://‌github.com/‌w3c/‌dxwg/‌pull/‌682 should be a trivial

DaveBrowning: this brings us to https://‌github.com/‌w3c/‌dxwg/‌pull/‌656

related to https://‌github.com/‌w3c/‌dxwg/‌issues/‌432

SimonCox: I can try and introduce the topic
… in the F2F in Genova, we came up with a solution about major use cases and requirements around practice of people running catalogues
… wanting to introduce services in the catalogues
… people that had a go at this, in some cases people had use dcat:Distribution class inconsistently
… and not following the semantics of dcat:Distribution properly
… then we decided to go for a class for data services
… and at some point we came up with a hierarchy of data services
… [reading definitions of classes]
… we have dcat:DataService and dcat:DataDistributionService
… the reality is that most of the services that people have listed in catalogues have been DDS
… but in my domain, not all services are DDS
… now the detail of all of those are insufficiently common and tied down
… so we don't want to speculate on what the hierarchy might be
… but there is a hierarchy
… I think annette_g is asking two questions
… wheter we can use dct:type to distinguish between services
… and by using the word service, hiding the idea that we are talking about APIs
… so I responded saying that DDS are common and having them would help the community
… and having the superclass allows to extend to other service types
… the text is very clear that the services would be some times APIs and in other cases web forms,
… the name of the class is a token and what matters is how it is described

+1 to the proposal in the PR

annette_g: I'll start by addressing the question of the github PRs
… they improve the documentation of the vocabulary as it stands
… as somebody who is a web developer and creates APIs from time to time
… I think what I need to describe an API
… the distinction that we are making are not what I find the operative distinctions
… if I'm looking for an API, I don't want to find other services
… I'm worried that we are not really addressing that
… I appreciate the effort of simplifying this a little bit

<ncar> meeting pwd via SMS please Simon

annette_g: I find it odd that we haven't define the services in the vocabulary
… that's the feel I have about it
… I cannot define how it should be done
… but mention that there is an issue

<PWinstanley> alejandra: 1/ we are not describing the services themselvels- there are various ways to do this

<PWinstanley> ... we are looking to catalogue existing data services, whether or not it is from an API

<PWinstanley> ... we need to define scope and are probably not going to go further

<PWinstanley> ... 2/ what is missing?

annette_g: what I think it is useful is be able to determine if something is available as a programming interface and as a graphical interface
… the different vocabulary describing web services can kick in after knowing it is an API
… being able to say that this is something that was intended for a programming interface is important

SimonCox: my sense is that all the information is expressible in the vocabulary that we have in front of us
… and with the text modifications that we've been making

<SimonCox> https://‌rawgit.com/‌w3c/‌dxwg/‌dcat-issue432-simon/‌dcat/‌index.html#dcat-scope

SimonCox: figure 1 and examples in annex d3


SimonCox: endpointDescription provides info about the endpoint
… endpointURL is the actual address of the service
… the details of all of this are going to vary
… how one describes an endpoint is out of scope, as alejandra mentioned
… looking on the actual examples shows how to address your questions
… and I'm struggling to see what else is needed without a proposal

annette_g: if something has an endpointURL does not mean it is an API

SimonCox: in most cases, web forms / human interfaces are on top of an API

annette_g: you can distinguis the front end and the back end

SimonCox: in many cases, the users (both people advertising this for use, and people making use of them) can identify those nuinances
… if there is a better way of doing it, I'd like to see it

annette_g: I guess one way to do it is to have more subclasses: DataAPI, DataForm, etc

SimonCox: would you prepare a proposal with this?

annette_g: I'll see if I can work on this

PWinstanley: this concerns me, this is about publishing catalogues on the web
… calls to datasets have to be catalogued
… XML-rpc, jdbc, etc
… what do we do with those?
… when I'm documenting web APIs, I use openAPI / swagger /...
… that can be the landing page
… I think that is more than adequate
… I think this is nothing at all to do but providing documentation on how to access the data
… web API is only one way
… but there are many other ways

annette_g: are you suggesting that we should be documenting that are not on the web?

<ncar> +1 to Peter: we use DCAT for things themselves that are not on the web

PWinstanley: yes, because we are providing a way to publish data catalogues on the web
… not only the data sources where they are accessible

ncar: I agree with Peter, we have DCAT entries for things that are not on the web
… all kinds of layers of getting at the resource that we're interested in cataloguing

<PWinstanley> from the specification: " DCAT is an RDF vocabulary designed to facilitate interoperability between data catalogs published on the Web. "

annette_g: would you see that as sibling subclasses of DataServices?

PWinstanley: the first sentence of the DCAT spec copied above

<SimonCox> I'm a bit confused about Annette's needs here - in the GitHub issue you asked for DS and DDS to be collapsed, now you are proposing more and more sub-classes.

<PWinstanley> alejandra: we are moving away from the discussion - we have expanded to cover *any* kind of data service

<PWinstanley> ... as SimonCox explained there is a need for describing DDS, and that is why this subclass was included

<PWinstanley> ... any other distinction can be made via extension points

<PWinstanley> ... there was a larger hierarchy that we discussed and stuck to the minimal

<PWinstanley> ... SimonCox mentioned that with different properties web APIs can be described

annette_g: the properties are useful to describing those things
… but it doesn't make the distinction

<PWinstanley> isnt' this specific requirement for the web API something for a profile?

<SimonCox> (Could Annette point to a Use Case from UCR that describes the requirements she is concerned about?)

alejandra: what use case are you considering?

annette_g: Andrea had one about APIs

SimonCox: I don't think it was that specific

<PWinstanley> https://‌www.w3.org/‌TR/‌dcat-ucr/#ID30

<SimonCox> https://‌www.w3.org/‌TR/‌dcat-ucr/#ID18

annette_g: if the working group is seeking input, there are use cases that are not in there

SimonCox: we can't allow to use cases to creep in this late in the process

SimonCox: looking at the use case https://‌www.w3.org/‌TR/‌dcat-ucr/#ID18, I'm pretty sure we have address it

AndreaPerego: to clarify the use case, it is more about profiles rather than services
… how profile negotiation can be useful
… UCR ID-30

<SimonCox> that's ID30

AndreaPerego: about ID18... my take about services is that the use case is most specific to geospatial domain
… based on what I've been seeing is an increasing amount of catalogues of APIs
… programmable of APIs
… catalogue
… France set up a public catalogue of services, Amsterdam has a catalogue with services and APIs
… there is an increased interest to find APIs that can do some job
… and this is why there was a proposal of having APIs/services as first class citizens

PWinstanley: I think the issue of having a landing page is covering the situation for a number of SPARQL endpoints that have got simplified APIs
… web forms and shopping carts and things like that
… end up with someone downloading a set of data
… prime example about having profiles
… there is going to be an extremely large range of extensions
… I see SPARQL endpoints also being data transformation and data enrichment services
… even providing the different things that the SPARQL endpoint provides opens up complicated aspects
… and that requires something that is tailored for what you are describing rather than a general vocabulary

annette_g: I agree with that

annette_g: I'm not pushing that we try to describe APIs
… but I'm trying to get us give it first class citizenship

SimonCox: would there be a problem with merging a PR as is, but keeping the issue open?

<riccardoAlbertoni> +1 to avoid distinctions and serving a point of extensions as need to be general, and the kind of service/API can be indicated with dct:conformTo

SimonCox: you're asking for a bit more
… and you'll endeavour to make a proposal

<SimonCox> Proposed: merge PR 656 to improve documentation of service hierarchy, and consider additional details in response to upcoming proposals


alejandra: the issue of having data services as first class citizens has been done

<riccardoAlbertoni> +1 to merge

<SimonCox> +1 to merge

<PWinstanley> +1

<Makx> +1

<annette_g> +1

alejandra: distinguishing the different types of services could be hard

AndreaPerego: having a code list would be an option and maybe better addressed by a profile

<ncar> DXWG is pioneering codelist use alongside ontologies, ref Profiles Ontology & Roles codelist

<PWinstanley> http://‌www.hydra-cg.com/‌spec/‌latest/‌core/#documenting-a-web-api

<DaveBrowning> proposed: Merge the existing contribution, but keep the issue open to carry on the discussion

<annette_g> +1

<PWinstanley> Hydra is a vocabulary that might be relevant

<AndreaPerego> +1

<DaveBrowning> +1

<ncar> +0 (uninformed)

Resolved: merge PR 656 to improve documentation of service hierarchy, and consider additional details in response to upcoming proposals

<SimonCox> Thanks Annette

<Makx> +1 cor doodle

Action: DaveBrowning to set up doodle for sprints

<trackbot> Sorry, but no Tracker is associated with this channel.

action DaveBrowning create doodle for sprint

<trackbot> Sorry, but no Tracker is associated with this channel.

<ncar> hi!

<riccardoAlbertoni> thanks, bye...

<Makx> bye

Summary of action items

  1. DaveBrowning to set up doodle for sprints

Summary of resolutions

  1. minutes approved
  2. merge PR 656 to improve documentation of service hierarchy, and consider additional details in response to upcoming proposals
Minutes manually created (not a transcript), formatted by Bert Bos's scribe.perl version 2.49 (2018/09/19 15:29:32), a reimplementation of David Booth's scribe.perl. See CVS log.


Succeeded: s/service/services