20:53:11 RRSAgent has joined #dxwgdcat 20:53:11 logging to https://www.w3.org/2019/01/23-dxwgdcat-irc 20:53:23 chair: DaveBrowning 20:53:45 meeting: DXWG DCAT subgroup teleconference 7 March 2018 21:00 UTC 20:53:59 RRSAgent, make logs public 20:54:12 present+ 20:55:22 agenda: https://www.w3.org/2017/dxwg/wiki/Meetings:DCAT-Telecon2018.03.07 20:55:48 RRSAgent, draft minutes v2 20:55:48 I have made the request to generate https://www.w3.org/2019/01/23-dxwgdcat-minutes.html DaveBrowning 20:57:51 PWinstanley has joined #dxwgdcat 20:58:36 PWinstanley has joined #dxwgdcat 21:00:58 regrets+ Riccardo 21:01:48 AndreaPerego has joined #dxwgdcat 21:02:13 present+ AndreaPerego 21:03:13 Makx has joined #dxwgdcat 21:03:31 alejandra has joined #dxwgdcat 21:03:50 present+ Makx 21:04:27 meeting: DXWG DCAT subgroup teleconference 23 January 2019 21:00 UTC 21:04:43 agenda: https://www.w3.org/2017/dxwg/wiki/Meetings:DCAT-Telecon2019.01.23 21:04:50 RRSAgent, draft minutes v2 21:04:50 I have made the request to generate https://www.w3.org/2019/01/23-dxwgdcat-minutes.html DaveBrowning 21:05:24 riccardoAlbertoni has joined #dxwgdcat 21:05:24 present+ 21:05:44 SimonCox has joined #dxwgdcat 21:05:57 annette_g has joined #dxwgdcat 21:05:59 present+ 21:06:05 present+ 21:06:15 regrets- Riccardo 21:06:18 RRSAgent, draft minutes v2 21:06:18 I have made the request to generate https://www.w3.org/2019/01/23-dxwgdcat-minutes.html DaveBrowning 21:07:40 regrets+ Alasdair Gray, Erik Mannens, Thomas D'Haenens, Lars Svensson 21:08:30 RRSAgent, draft minutes v2 21:08:30 I have made the request to generate https://www.w3.org/2019/01/23-dxwgdcat-minutes.html DaveBrowning 21:09:29 scribenick: alejandra 21:09:52 https://www.w3.org/2017/dxwg/wiki/Meetings:DCAT-Telecon2019.01.23 21:09:59 present+ 21:10:04 topic: Confirm agenda 21:10:14 DaveBrowning: do we need any changes? 21:10:27 ... we need to discuss the issue around data services 21:10:52 SimonCox: there are a number of PRs that are lurking and ready to go 21:11:03 ... the one associated with annette_g's questions is one of those 21:11:14 ... so it'd be good to know if we can move forward or not 21:11:58 DaveBrowning: we move this issue first? 21:12:35 +1 21:12:40 https://github.com/w3c/dxwg/pulls?q=is%3Aopen+is%3Apr+label%3Adcat 21:12:41 +1 21:12:42 +1 to move this issue up 21:12:51 +1 21:12:54 topic: minutes of the last meeting 21:12:57 +1 21:13:09 https://www.w3.org/2019/01/16-dxwgdcat-minutes 21:13:23 +1 to minutes 21:13:30 +1 21:13:39 +0 was not there 21:13:40 +1 to minutes 21:13:49 +1 to minutes 21:13:54 +1 21:14:09 resolved: minutes approved 21:14:22 ncar has joined #dxwgdcat 21:14:30 topic: Review pull requests 21:14:32 present+ 21:14:33 RRSAgent, draft minutes v2 21:14:33 I have made the request to generate https://www.w3.org/2019/01/23-dxwgdcat-minutes.html AndreaPerego 21:14:51 https://github.com/w3c/dxwg/pulls?q=is%3Aopen+is%3Apr+label%3Adcat 21:15:04 +q 21:15:17 ack alejandra 21:15:36 q+ 21:15:39 alejandra: just to mention that I'm still working on mine - text explaining better DCAT 21:15:44 .... I'll push very soon 21:15:54 ack SimonCox 21:16:22 SimonCox: will this be ready in a day or two? 21:16:24 alejandra: yes 21:16:59 DaveBrowning: this one https://github.com/w3c/dxwg/pull/682 should be a trivial 21:17:20 DaveBrowning: this brings us to https://github.com/w3c/dxwg/pull/656 21:17:31 related to https://github.com/w3c/dxwg/issues/432 21:17:58 SimonCox: I can try and introduce the topic 21:18:24 ... in the F2F in Genova, we came up with a solution about major use cases and requirements around practice of people running catalogues 21:18:31 ... wanting to introduce services in the catalogues 21:18:51 ... people that had a go at this, in some cases people had use dcat:Distribution class inconsistently 21:19:04 ... and not following the semantics of dcat:Distribution properly 21:19:16 ... then we decided to go for a class for data services 21:19:31 ... and at some point we came up with a hierarchy of data services 21:19:49 ... [reading definitions of classes] 21:20:07 ... we have dcat:DataService and dcat:DataDistributionService 21:20:31 ... the reality is that most of the services that people have listed in catalogues have been DDS 21:20:40 ... but in my domain, not all services are DDS 21:20:55 ... now the detail of all of those are insufficiently common and tied down 21:21:07 q? 21:21:09 ... so we don't want to speculate on what the hierarchy might be 21:21:15 ... but there is a hierarchy 21:21:21 ... I think annette_g is asking two questions 21:21:36 ... wheter we can use dct:type to distinguish between services 21:21:52 ... and by using the word service, hiding the idea that we are talking about APIs 21:22:16 ... so I responded saying that DDS are common and having them would help the community 21:22:33 ... and having the superclass allows to extend to other service types 21:23:12 ... the text is very clear that the services would be some times APIs and in other cases web forms, 21:23:29 ... the name of the class is a token and what matters is how it is described 21:23:43 +1 to the proposal in the PR 21:24:04 annette_g: I'll start by addressing the question of the github PRs 21:24:14 ... they improve the documentation of the vocabulary as it stands 21:24:32 ... as somebody who is a web developer and creates APIs from time to time 21:24:46 ... I think what I need to describe an API 21:24:57 ... the distinction that we are making are not what I find the operative distinctions 21:25:12 ... if I'm looking for an API, I don't want to find other services 21:25:15 +q 21:25:23 q+ 21:25:26 ... I'm worried that we are not really addressing that 21:25:36 q? 21:25:44 ... I appreciate the effort of simplifying this a little bit 21:26:04 meeting pwd via SMS please Simon 21:26:20 ... I find it odd that we haven't define the services in the vocabulary 21:26:32 ... that's the feel I have about it 21:26:50 ... I cannot define how it should be done 21:26:52 ack alejandra 21:26:58 ... but mention that there is an issue 21:27:35 alejandra: 1/ we are not describing the services themselvels- there are various ways to do this 21:27:54 ... we are looking to catalogue existing data services, whether or not it is from an API 21:28:15 ... we need to define scope and are probably not going to go further 21:28:26 ... 2/ what is missing? 21:28:59 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 21:29:20 ... the different vocabulary describing web services can kick in after knowing it is an API 21:29:35 ack SimonCox 21:29:38 ... being able to say that this is something that was intended for a programming interface is important 21:30:00 SimonCox: my sense is that all the information is expressible in the vocabulary that we have in front of us 21:30:10 ... and with the text modifications that we've been making 21:30:21 https://rawgit.com/w3c/dxwg/dcat-issue432-simon/dcat/index.html#dcat-scope 21:30:47 SimonCox: figure 1 and examples in annex d3 21:30:59 https://rawgit.com/w3c/dxwg/dcat-issue432-simon/dcat/index.html#data-service-examples 21:31:22 SimonCox: endpointDescription provides info about the endpoint 21:31:30 ... endpointURL is the actual address of the service 21:31:32 q+ 21:31:38 ... the details of all of this are going to vary 21:31:58 q? 21:32:03 ... how one describes an endpoint is out of scope, as alejandra mentioned 21:32:37 ... looking on the actual examples shows how to address your questions 21:32:57 ... and I'm struggling to see what else is needed without a proposal 21:33:15 annette_g: if something has an endpointURL does not mean it is an API 21:33:36 SimonCox: in most cases, web forms / human interfaces are on top of an API 21:33:45 annette_g: you can distinguis the front end and the back end 21:34:17 SimonCox: in many cases, the users (both people advertising this for use, and people making use of them) can identify those nuinances 21:34:33 ... if there is a better way of doing it, I'd like to see it 21:35:21 annette_g: I guess one way to do it is to have more subclasses: DataAPI, DataForm, etc 21:35:33 SimonCox: would you prepare a proposal with this? 21:35:43 annette_g: I'll see if I can work on this 21:35:58 q? 21:36:03 ack PWinstanley 21:36:17 PWinstanley: this concerns me, this is about publishing catalogues on the web 21:36:36 ... calls to datasets have to be catalogued 21:36:59 ... XML-rpc, jdbc, etc 21:37:05 ... what do we do with those? 21:37:30 ... when I'm documenting web APIs, I use openAPI / swagger /... 21:37:38 ... that can be the landing page 21:37:48 ... I think that is more than adequate 21:38:07 q? 21:38:09 ... I think this is nothing at all to do but providing documentation on how to access the data 21:38:19 ... web API is only one way 21:38:31 ... but there are many other ways 21:38:44 annette_g: are you suggesting that we should be documenting that are not on the web? 21:39:07 +1 to Peter: we use DCAT for things themselves that are not on the web 21:39:08 PWinstanley: yes, because we are providing a way to publish data catalogues on the web 21:39:21 ... not only the data sources where they are accessible 21:39:40 q+ 21:39:50 ack ncar 21:40:11 ncar: I agree with Peter, we have DCAT entries for things that are not on the web 21:40:27 ... all kinds of layers of getting at the resource that we're interested in cataloguing 21:40:40 from the specification: " DCAT is an RDF vocabulary designed to facilitate interoperability between data catalogs published on the Web. " 21:40:50 annette_g: would you see that as sibling subclasses of DataServices? 21:40:52 +q 21:41:20 PWinstanley: the first sentence of the DCAT spec copied above 21:41:37 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. 21:41:59 ack alejandra 21:42:35 alejandra: we are moving away from the discussion - we have expanded to cover *any* kind of data service 21:43:03 ... as SimonCox explained there is a need for describing DDS, and that is why this subclass was included 21:43:16 ... any other distinction can be made via extension points 21:44:02 ... there was a larger hierarchy that we discussed and stuck to the minimal 21:44:21 ... SimonCox mentioned that with different properties web APIs can be described 21:44:28 annette_g: the properties are useful to describing those things 21:44:36 ... but it doesn't make the distinction 21:45:15 isnt' this specific requirement for the web API something for a profile? 21:46:00 (Could Annette point to a Use Case from UCR that describes the requirements she is concerned about?) 21:46:06 alejandra: what use case are you considering? 21:46:16 annette_g: Andrea had one about APIs 21:46:29 SimonCox: I don't think it was that specific 21:46:37 https://www.w3.org/TR/dcat-ucr/#ID30 21:46:49 https://www.w3.org/TR/dcat-ucr/#ID18 21:47:02 q+ 21:47:03 q+ 21:47:07 annette_g: if the working group is seeking input, there are use cases that are not in there 21:47:20 SimonCox: we can't allow to use cases to creep in this late in the process 21:48:16 ack AndreaPerego 21:48:20 SimonCox: looking at the use case https://www.w3.org/TR/dcat-ucr/#ID18, I'm pretty sure we have address it 21:48:35 AndreaPerego: to clarify the use case, it is more about profiles rather than services 21:48:45 ... how profile negotiation can be useful 21:48:54 ... UCR ID-30 21:48:55 that's ID30 21:49:45 AndreaPerego: about ID18... my take about services is that the use case is most specific to geospatial domain 21:50:16 ... based on what I've been seeing is an increasing amount of catalogues of APIs 21:50:20 ... programmable of APIs 21:50:25 ... catalogue 21:50:48 ... France set up a public catalogue of services, Amsterdam has a catalogue with services and APIs 21:50:58 q+ 21:50:58 ... there is an increased interest to find APIs that can do some job 21:51:16 q? 21:51:17 ... and this is why there was a proposal of having APIs/services as first class citizens 21:51:32 ack PWinstanley 21:52:02 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 21:52:11 ... web forms and shopping carts and things like that 21:52:20 ... end up with someone downloading a set of data 21:52:21 q- 21:52:30 ... prime example about having profiles 21:52:49 q? 21:52:51 ... there is going to be an extremely large range of extensions 21:53:00 RRSAgent, draft minutes v2 21:53:00 I have made the request to generate https://www.w3.org/2019/01/23-dxwgdcat-minutes.html DaveBrowning 21:53:21 ... I see SPARQL endpoints also being data transformation and data enrichment service 21:53:26 s/service/services 21:53:34 present+ ncar 21:53:54 ... even providing the different things that the SPARQL endpoint provides opens up complicated aspects 21:54:12 ... and that requires something that is tailored for what you are describing rather than a general vocabulary 21:54:19 annette_g: I agree with that 21:54:28 q+ 21:54:39 annette_g: I'm not pushing that we try to describe APIs 21:54:44 q? 21:54:56 ... but I'm trying to get us give it first class citizenship 21:54:57 +q 21:55:08 ack SimonCox 21:55:30 SimonCox: would there be a problem with merging a PR as is, but keeping the issue open? 21:55:56 +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 21:56:02 ... you're asking for a bit more 21:56:09 ... and you'll endeavour to make a proposal 21:56:15 ack alejandra 21:57:28 Proposed: merge PR 656 to improve documentation of service hierarchy, and consider additional details in response to upcoming proposals 21:57:54 +1 21:58:13 alejandra: the issue of having data services as first class citizens has been done 21:58:30 q+ 21:58:35 q? 21:58:46 ack AndreaPerego 21:58:52 +1 to merge 21:58:57 +1 to merge 21:59:01 +1 21:59:10 +1 21:59:20 +1 21:59:44 alejandra: distinguishing the different types of services could be hard 22:00:06 AndreaPerego: having a code list would be an option and maybe better addressed by a profile 22:00:08 DXWG is pioneering codelist use alongside ontologies, ref Profiles Ontology & Roles codelist 22:00:16 http://www.hydra-cg.com/spec/latest/core/#documenting-a-web-api 22:00:31 proposed: Merge the existing contribution, but keep the issue open to carry on the discussion 22:00:44 +1 22:00:48 Hydra is a vocabulary that might be relevant 22:00:48 +1 22:00:51 +1 22:01:03 +0 (uninformed) 22:01:14 resolved: merge PR 656 to improve documentation of service hierarchy, and consider additional details in response to upcoming proposals 22:01:25 Thanks Annette 22:01:34 RRSAgent, draft minutes v2 22:01:34 I have made the request to generate https://www.w3.org/2019/01/23-dxwgdcat-minutes.html AndreaPerego 22:02:19 +1 cor doodle 22:02:32 Action: DaveBrowning to set up doodle for sprints 22:02:32 Sorry, but no Tracker is associated with this channel. 22:02:34 action DaveBrowning create doodle for sprint 22:02:34 Sorry, but no Tracker is associated with this channel. 22:02:44 hi! 22:02:46 thanks, bye... 22:02:50 bye 22:02:52 RRSAgent, draft minutes v2 22:02:52 I have made the request to generate https://www.w3.org/2019/01/23-dxwgdcat-minutes.html alejandra 22:03:26 RRSAgent, draft minutes v2 [22:02] I have made the request to ge 22:03:26 I'm logging. I don't understand 'draft minutes v2 [22:02] I have made the request to ge', alejandra. Try /msg RRSAgent help 22:03:36 RRSAgent, draft minutes v2 22:03:36 I have made the request to generate https://www.w3.org/2019/01/23-dxwgdcat-minutes.html alejandra 22:17:33 annette_g has joined #dxwgdcat