<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
<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
<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
<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
Failed: s/ * pw on the other tab/
Succeeded: s/* Simon sent it to you as a private message/
Succeeded: s/topic: Annette's proposal on services/API//
Succeeded: s/API//
Succeeded: s/API//
Succeeded: s/,,,/.../
Succeeded: s/landingpageURL/landingPage/