– DRAFT –
DXWG DCAT subgroup teleconference

alejandra: the agenda tries to focus on pending comments
… we also have internal comments, and pull requests

<alejandra> Agenda confirmed

alejandra: in the absence of other comments, let's proceed

approve minutes

<alejandra> https://‌www.w3.org/‌2019/‌01/‌09-dxwgdcat-minutes

<alejandra> +1

<DaveBrowning> +1

<AndreaPerego> +1

<riccardoAlbertoni> +0 ( i was no there)

<SimonCox> +1

+1

Resolved: minutes approved

Outstanding actions

<alejandra> https://‌www.w3.org/‌2017/‌dxwg/‌track/‌actions/‌open

Public comments list

<alejandra> https://‌lists.w3.org/‌Archives/‌Public/‌public-dxwg-comments/

<alejandra> Stephen Richard's comments

<alejandra> https://‌lists.w3.org/‌Archives/‌Public/‌public-dxwg-comments/‌2018Nov/‌0007.html

<riccardoAlbertoni> It is about recounciling the entities

<AndreaPerego> Relevant section: https://‌w3c.github.io/‌dxwg/‌dcat/#Property:catalog_homepage

<PWinstanley_> alejandra: we need to check the usage notes

<PWinstanley_> ... we need to reply, but change the text for something easier to understand

Action: SimonCox to deal with the phrase change and reply to Stephen Richards

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

<alejandra> second comment: https://‌lists.w3.org/‌Archives/‌Public/‌public-dxwg-comments/‌2018Nov/‌0003.html

<PWinstanley_> alejandra: second comment, we haven't replied

<PWinstanley_> ... he suggests changes to section 5

<PWinstanley_> ... We have already addressed these issues

<PWinstanley_> ... I'm not sure exactly what change he is proposing

<PWinstanley_> ... Any Views?

<PWinstanley_> SimonCox: He is referring to section 5 - it has been rewritten. we should process that branch I've been working on then respond

<PWinstanley_> ... asking if it is now clearer

<DaveBrowning> +1 to handling in the existing work

<alejandra> https://‌github.com/‌w3c/‌dxwg/‌issues/‌431

<PWinstanley_> alejandra: the issue is confusion of the different classes, which we have resolved and are improving further

<alejandra> first address issue 432

<alejandra> refer to issue 431 that has been closed (https://‌github.com/‌w3c/‌dxwg/‌issues/‌431)

<alejandra> and after that contact Stephen

Action: SimonCox to respond to Stephen after 432 has been addressed

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

<PWinstanley_> alejandra: there is another old comment mentioned by antoine

<alejandra> Nuno Freire's comment: https://‌lists.w3.org/‌Archives/‌Public/‌public-dxwg-comments/‌2018Apr/‌0001.html

<riccardoAlbertoni> https://‌github.com/‌w3c/‌dxwg/‌issues/‌667

<PWinstanley_> ... he is asking if DCAT is going to have anything similar to void:Resource

<riccardoAlbertoni> https://‌github.com/‌w3c/‌dxwg/‌issues/‌292

<PWinstanley_> DaveBrowning: It may be an existing issue that is still open

<alejandra> corresponding issue: https://‌github.com/‌w3c/‌dxwg/‌issues/‌667

<AndreaPerego> I think this is in scope with the discussion on relationship between DCAT, VoID and RDF DataCube - which is still an open issue.

<PWinstanley_> SimonCox: similar to the cataloguing of resources that are not distributions, we suggested dct:relation where a general case is required

<PWinstanley_> ... that is a potential solution to the question, but we dont say that links to all resources should be included

<PWinstanley_> alejandra: Riccardo also put the link. #292

<PWinstanley_> ... void relates only to RDF datasets

<PWinstanley_> riccardoAlbertoni: this is to facilitate crawling, but in our case the resources are all together, so I don't think that DCAT should include this

<AndreaPerego> See also this one: https://‌github.com/‌w3c/‌dxwg/‌issues/‌88

<alejandra> from VoID: One or more such root resources can be named using the void:rootResource property. Naming a resource as a root resource implies: that it is a central entity of particular importance in the dataset; and that the entire dataset can be crawled by resolving the root resource(s) and recursively following links to other URIs in the retrieved RDF responses.

<PWinstanley_> AndreaPerego: this comment is part of the general issue discussed at the beginning about the relationship between DCAT and other related vocabs. This is still an open issue, and an important problem. People are struggling to know how DCAT, VOID and QB can be used together

<PWinstanley_> ... This is not only about relationships, but about Classes too

<PWinstanley_> ... I've heard people questioning how properties and classes in VOID can be used for non-RDF data

<PWinstanley_> ... It would be nice to come up with some position about these relations, and this might indirectly answer this question

<riccardoAlbertoni> working note 2011

<PWinstanley_> SimonCox: What is the status of VOID?

<alejandra> https://‌www.w3.org/‌TR/‌void/

<PWinstanley_> alejandra: it is an interest group note

<PWinstanley_> AndreaPerego: it is widely used, similar to FOAF - a de facto standard

<PWinstanley_> alejandra: it is *very* specific for RDF

<PWinstanley_> ... if we say we use it in DCAT we need to rely on the specification

<PWinstanley_> ... Given the URI of a dataset how can you crawl the content?

<alejandra> related to this other issue https://‌github.com/‌w3c/‌dxwg/‌issues/‌482

<PWinstanley_> AndreaPerego: even though is it just about RDF data we need to specify the relation to DCAT

<alejandra> PWinstanley_: at the EuroStat meeting, Ed (from Google) was talking and pointing out quite strongly...

<alejandra> ... the interest of considering data for crawling

<alejandra> ... rather than something to be accessed

<alejandra> ... Ed Parsons

<AndreaPerego> This was also what discussed at length in the SDW WG.

<PWinstanley_> SimonCox: it is very much the Google line

<PWinstanley_> ... everything is landing page related

<PWinstanley_> alejandra: they rely on site maps

<PWinstanley_> SimonCox: Do we need a reference to site maps?

<PWinstanley_> alejandra: Yes

<PWinstanley_> PWinstanley_: yes

<PWinstanley_> DaveBrowning: there is perhaps a requirement to do with manifests, something explaining in more detail what is contained

<PWinstanley_> ... I think one of the user cases we've skirted round is scouring catalogues

<PWinstanley_> ... I think it would be good to do a deep dive here, but it might take time

<PWinstanley_> SimonCox: ask him for a suggestion of a solution?

<PWinstanley_> alejandra: there are several solution options.

<alejandra> I would ask if addressing sitemaps or manifest files would cover his use case

<SimonCox> i.e. would a SiteMap or other kind of 'Manifest' file provide the solution?

<PWinstanley_> AndreaPerego: Following on the comment referencing Ed Parsons, manifests are more metadata, whereas google are interested in crawling the data

<PWinstanley_> ... this is a bit out of scope

alejandra: who would like to take that action?

Action: Alejandra to reply to Nuno F asking for more details and mentioning sitemaps and manifest files

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

alejandra: next comment

<alejandra> Luca Trani's comment: https://‌lists.w3.org/‌Archives/‌Public/‌public-dxwg-comments/‌2018Dec/‌0000.html

alejandra: AndreaPerego sent a report. Anything else to discuss
… would you send a reply to him?

AndreaPerego: Yep

Action: AndreaPerego to reply to 2nd Luca's comment

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

DaveBrowning: We discussed last time about adding a comment on dcat:Resource as extension point. This is part of the answer Luca needs

alejandra: last comment

<alejandra> Ine de Visser's comment: https://‌lists.w3.org/‌Archives/‌Public/‌public-dxwg-comments/‌2019Jan/‌0002.html

alejandra: Some of the points is related to the use of some properties, and similar comments are already included in the GH issues
… she refers to INSPIRE, and supports the inclusion of services in DCAT
… any comments?

<alejandra> AndreaPerego: one of the points that Ine is making ...

<alejandra> ... is that the properties (accessURL, etc) should be defined unambigously irrespectively if they are use with datasets or services

<alejandra> ... the issue I see is that there are some legacy properties...

<alejandra> ... and if we change the semantics dramatically, we might break backward compatibility

<alejandra> ... the other point is raising an issue about the aligments between definitions of terms we use and how they are use inside INSPIRE

<alejandra> ... we can check these ones and see if it makes sense to reconsider the terms we are using

<alejandra> ... or if we just mention the corresponding INSPIRE term as related

alejandra: meanwhile we can reply to say thanks and that we'll address her comments

SimonCox: I suggest AndreaPerego to look into this

<DaveBrowning> +1 to Andrea doing analysis

<riccardoAlbertoni> +1 to andrea ( that was also my interpretation, she seemed confused by the presence of properties that are somehow applicable in similar situation)

Action: AndreaPerego to prepare a report about Ine's email and send it to the group

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

DaveBrowning: The part of machine-readability needs to be unpacked

alejandra: I'll then reply to Ine in the meantime

alejandra: karen's comment now

<alejandra> https://‌lists.w3.org/‌Archives/‌Public/‌public-dxwg-wg/‌2019Jan/‌0195.html

<alejandra> https://‌github.com/‌w3c/‌dxwg/‌pull/‌669

alejandra: it's about ODRS / ODRL in the section about
… licenses and rights

AndreaPerego: Actually, one open issue is whether we should keep ODRS or not in the DCAT spec

<alejandra> https://‌github.com/‌w3c/‌dxwg/‌milestone/‌14

alejandra: this concludes the comments

<alejandra> https://‌github.com/‌w3c/‌dxwg/‌pulls

alejandra: just want to bring your attention to milestones and open issues

SimonCox: Maybe we can talk about https://‌github.com/‌w3c/‌dxwg/‌issues/‌432
… one of the things I was thinking of was whether we'd better remove dcat:DiscoveryService

<DaveBrowning> +1 to keeping DDS

SimonCox: I think quite strongly we should keep dcat:DataDistributionService, also because illustrates about the point that dcat:DataService is a possible extension point for other services.

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

SimonCox: I'm revising the definitions now, and I would to ask people to look at it

SimonCox: Are you fine with dropping dcat:DiscoveryService?
… or should we keep it and mark later if deprecated in case?

DaveBrowning: I agree with the idea of dropping it

alejandra: maybe we need to look at the requirements, and see if there's a need for that

<riccardoAlbertoni> bye thanks !

<DaveBrowning> \quit

alejandra: let's close the meeting and keep on discussing offline.

[meeting adjourned]

Action: Alejandra to reply to Ine de Visser to acknowledge her message

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