– DRAFT –
DXWG DCAT subgroup teleconference 13 March 2019 21:00 UTC

<annette_g> Hi, is there a webex for this?

<annette_g> The agenda links to CSIRO webex, which comes up as cancelled or ended.

<DaveBrowning> link is https://‌csiro.webex.com/‌csiro/‌j.php?MTID=m7f5ece41d26d5e36c16af8c20faadc15

<annette_g> erg, need a pw

<alejandra> * pw on the other tab

<DaveBrowning> try this link https://‌csiro.webex.com/‌csiro/‌j.php?MTID=m7f5ece41d26d5e36c16af8c20faadc15

confirm agenda

<alejandra> +1, point 3 is key

Need to focus on resolving issues, no new features

main concern is annette_g comment on services

annette_g comment is https://‌github.com/‌w3c/‌dxwg/‌pull/‌805

<AndreaPerego> +1

+1

<Makx> +1

<alejandra> +1

<PWinstanley> +1

<DaveBrowning> +1

<annette_g> alejandra sent around a better link for viewing

approve minutes

<annette_g> +1

<alejandra> the link is in the PR

https://‌www.w3.org/‌2019/‌03/‌06-dxwgdcat-minutes

<DaveBrowning> minutes at https://‌www.w3.org/‌2019/‌03/‌06-dxwgdcat-minutes

<AndreaPerego> +1

+1

<PWinstanley> +1

<alejandra> +1

<DaveBrowning> 0 (not present)

<annette_g> +0 (not present)

<Makx> +1

Resolved: minutes of last meeting approved

Services design

<alejandra> s/ * pw on the other tab/

<AndreaPerego> //API

<AndreaPerego> https://‌raw.githack.com/‌agreiner/‌dxwg/‌annette-dataservices/‌dcat/‌index.html#Class:Data_

annette_g: current design does not serve the purpose of cataloguing services
… DDS is specialization that has no peers
… DDS is ambiguous - is it only for distributions? or is it for any service?
… since any data service will serve distributions of some form
… too ambiguous, too readily changed
… change structure subtly to differentiate
… does not cover UIs, does not cover typical user questions
… propose data service model that provide clear and practical distinction begtween application service (UI?) and API
… don't require switching classes: DDS is really not needed? but API vs UI is.

<alejandra> SimonCox: I had the most to do with designing the current proposal

SimonCox: The current proposal displays my experience, and to cover the use cases I am aware of.
… If you check the first example (5.9) and the more extended example (D.3)
… I would ask you can show how the examples are reshaped according to your proposal.

annette_g: I think I did that.

<riccardoAlbertoni> https://‌raw.githack.com/‌agreiner/‌dxwg/‌annette-dataservices/‌dcat/‌index.html#a-dataset-available-from-a-service

SimonCox: We did have the discussion about DataService vs DataDistributionService

<alejandra> https://‌rawgit.com/‌w3c/‌dxwg/‌annette-dataservices/‌dcat/‌index.html#a-dataset-available-from-a-service

SimonCox: I agree with you that any data service may end up being a data distribution service

<alejandra> the new example is probably somwhere else? as this is the same as before: https://‌rawgit.com/‌w3c/‌dxwg/‌annette-dataservices/‌dcat/‌index.html#a-dataset-available-from-a-service

SimonCox: However this reflect the fact that there are services which are not bound to specific datasets, though they provide data processing, visualisation, etc.

<DaveBrowning> Yes, we need to use the https://‌raw.githack.com/‌agreiner/‌dxwg/‌annette-dataservices/‌dcat/‌index.html#a-dataset-available-from-a-service link

annette_g: Are you thinking of service where people can upload data?

SimonCox: Yes, but there are also other cases.

<DaveBrowning> and https://‌services.w3.org/‌htmldiff?doc1=https%3A%2F%2Fw3c.github.io%2Fdxwg%2Fdcat%2F&doc2=https%3A%2F%2Fraw.githack.com%2Fagreiner%2Fdxwg%2Fannette-dataservices%2Fdcat%2Findex.html for diff

SimonCox: Probably the problem is the name of the class that may be misleading.

annette_g: I would agree that people should know the difference between the two.

<SimonCox> annette_g: don't need subclass, just presence or absence of 'servesDataset' link

alejandra: part of the problem may be that we are still unclear about definition of 'distribution'
… differentiation between application and API is not clear - need further clarifications :-(
… but now running out of time
… propose: retain 'DataService', but don't have more details

<AndreaPerego> +1 to alejandra's proposal

alejandra: improve DCAT with class for services, but don't model it now in more detail

annette_g: sharp distinction between service for programmatic access, and service for human access
… can select easire

alejandra: services are the same, just different ways of accessing them

<AndreaPerego> Exactly.

<alejandra> I don't think we need two classes

<alejandra> to distinguish APIs and other services

landingPage vs endpointURL is the distinction between UI and API!

PWinstanley: it will be difficult to keep up with the detail of emerging APIs
… e.g. netflix
… so perhaps we can't try to specify too much detail in API descriptions
… 'API' ties it down to a way of thinking which is changing

annette_g: netflix example is good - UI and API are very distinct
… not specific to REST API

<alejandra> it is the same catalog entry (a service) with an API and a landing page

annette_g: need separate catalog entries for the documentation (landingPage) and API (endpoint)

AndreaPerego: didn't understand background of annette_g proposal
… was assuming service=API!
… use-cases from geospatial are all APIs
… in Europe, for geospatial services, the main problem was that people were finding a dataset, with link to service which was an XML document
… people outside geospatial were nto familar with this
… so this was the main issue, and how to make it machine-actionable
… enabling user-agents to make it transparent
… so they know e.g. if it is a WMS, they can then open a client app which knows how to bind to a WMS (which is only described in an XML document)
… (the XMl document is on the web as a 'capabilities' description, with all the query parameters)
… in geospatial there has been distinction between the (i) endpoint (ii) description of the service (XML document) and (sometimes) (iii) a UI (landing page)
… endpoint = API
… long narrative of how geospatial clients bind to services
… generally agree that can have separate pointers to endpoint and UI, but not (yet) as distinct classes

view-source: http://‌linked.bodc.ac.uk/‌sparql/

<PWinstanley> +1 to the alejandra proposal

<AndreaPerego> +1

<alejandra> I was proposing to drop DataDistributionService but leaving DataService and its properties

SimonCox: 1. alejandra proposal would retain all the service properties but only on one DS class 2. sub-classes of DS are premature at this stage, particularly in view of PWinstanley contention that service models are changing

alejandra: yes, collapse to a single class
… but some services have multiple APIs and UIs all on the same service

Proposed: 1. collapse service hierarchy to one class

annette_g: would still need q+

<PWinstanley> is there a space for a qualified relation here?

SimonCox: it is up to the service provider to decide whether to make multiple entries in a catalog for a service, but can all use the same class

alejandra: DS class allows for different instances or one DS instance with different URLs for landingPage and APIs

AndreaPerego: may have alternative APIs on the same 'service', so yes, may need multiple entries
… so that endpointURL and endpointDescription is coupled in each case
… concerned to conflate service (API) with webpage that provides UI access.
… sees merit in separating notion of service and notion of web-application
… risk that extension point will be used inconsistently

<alejandra> SimonCox: at the moment, we don't have a class which describes UIs

<alejandra> ... we do have a link (landingpage link) to a web page about data services or datasets

<alejandra> ... at the moment, it has been out of scope the notion of a data application

<alejandra> ... the model that is in the ED is only attempting to provide just enough information about an API

<alejandra> ... is this discussion based on a mistaken assumption?

<alejandra> annette_g: it depends if you define a data application as a data service

web-application (UI) is out of scope for DCAT?

dcat: Dataservice is only for APIs

dcat: landingPage is a link, but does not describe a web-application (UI)

AndreaPerego: developer needs link to API, and then either machine-actionable or human-usable documentation

AndreaPerego: gives more examples of how it works for geospatial data distributions and services

DaveBrowning: this has been a constructive meeting as it has shaken out the differences of perspective
… but we are running out of time, so what can we get done now?

<alejandra> SimonCox: annette_g's use case is interesting

<riccardoAlbertoni> +1 to alejandra and andreas' proposal ( get rid of subclassing for DataService), and don't discuss sub classing or postpone it to the evergreen group or dcat profile after that we have "tested" the simple structure against the examples discussed tonight

<alejandra> ... I got to understand that what we are discussing was not being considered before

<alejandra> annette_g: is the proposal covering all that my proposal covered?

<alejandra> SimonCox: I think the answer would be no, but it would provide an extension point

DaveBrowning: however we got here, we are out of time

annette_g: thinnks her proposal satisfies AndreaPerego requirements

AndreaPerego: service-interface is probably not a sub-class of data-service

<PWinstanley> Presumably a data service (the subsetting / enrichment / etc service) can be provided through many interfaces

AndreaPerego: 'interface' is a separate class, perhaps as a distinct sub-class of dcat:Resource?

annette_g: OpenDAP is a kind of service that allows to navigate through distributions in a UI

<alejandra> https://‌www.opendap.org/

annette_g: netflix is not the same.

DaveBrowning: what can we do to progress?

alejandra: we need to start closing stuff!
… 2 different understandings - thought that DS might cover both Data Application and Data API, but AndreaPerego (and SimonCox ) suggest maybe not

alejandra: suggest DCAT v1.1 has one dcat:DataService class, refinements to come in future.

alejandra: data applications was not in the original Use Case analysis

SimonCox: data applications are out of scope in this version of DCAT

DaveBrowning: add Data Applications in the future as part of the rolling/evolving DCAT specification

<alejandra> we have a roadmap for future versions

<riccardoAlbertoni> let's have a vote...

Proposal: remove dcat:DataDistributionService as separate class, move properties and links to dcat:DataService,

+1

<annette_g> We would have to move servesDataset to DataService

yes

<AndreaPerego> +1

<riccardoAlbertoni> +1

<PWinstanley> +1

<DaveBrowning> +1

<annette_g> +1

<alejandra> 'move properties and links to dcat:DataService' implies moving servesDataset to DataService

<alejandra> +1

yes

Resolved: remove dcat:DataDistributionService as separate class, move properties and links to dcat:DataService

alejandra: need CR in two weeks - move outstanding issues to future milestone

DaveBrowning: will tidy up milestones so we can tell plenary what plans are in detail.

AndreaPerego: unclear what will happen past 1.1?

<annette_g> new charter, I think

AndreaPerego: does it include a 6-month extension? what is process?

<alejandra> milestone is now 'DCAT CR': https://‌github.com/‌w3c/‌dxwg/‌milestone/‌14

DaveBrowning: process was not fully explained, merely alluded to by Phillipe in yesterday's plenary
… not clear if formal charter, membership, etc.
… but this does allows us to focus on v1.1

AndreaPerego: need clarifications on process

DaveBrowning: will explain how we plan to work in the next report to plenary

<PWinstanley> we are talking to phillipe

<PWinstanley> Phillipe is advising on procedures and routes to solving our overloaded state

DaveBrowning: 'Evergreen standards' is a goal of the W3C advisory Board
… with DXWG/DCAT as the prototype

<annette_g> yes

<riccardoAlbertoni> Thanks !!!!

<annette_g> Thanks, all!!

<PWinstanley> night night! Bye