– DRAFT –
DXWG DCAT subgroup teleconference 23 January 2019 21:00 UTC
23 January 2019
https://www.w3.org/2017/dxwg/wiki/Meetings:DCAT-Telecon2019.01.23
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?
+1
<SimonCox> https://github.com/w3c/dxwg/pulls?q=is%3Aopen+is%3Apr+label%3Adcat
<riccardoAlbertoni> +1
+1 to move this issue up
<AndreaPerego> +1
<AndreaPerego> +1
https://www.w3.org/2019/01/16-dxwgdcat-minutes
<SimonCox> +1 to minutes
<PWinstanley> +1
<Makx> +0 was not there
+1 to minutes
<riccardoAlbertoni> +1 to minutes
<DaveBrowning> +1
Resolved: minutes approved
https://github.com/w3c/dxwg/pulls?q=is%3Aopen+is%3Apr+label%3Adcat
<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
https://rawgit.com/w3c/dxwg/dcat-issue432-simon/dcat/index.html#data-service-examples
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
+1
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
Succeeded: s/service/services