– DRAFT –
DXWG DCAT subgroup teleconference 24 July 2019 20:00 UTC

Admin

proposed: accept minutes of last meeting

<AndreaPerego> +1

<riccardoAlbertoni> +1

<DaveBrowning> +1

<SimonCox> +1

Resolved: accept minutes of last meeting

DaveBrowning: No issues from the DCAT plenary for us

PWinstanley: there is a poll, everyone needs to answer ASAP

<DaveBrowning> Issues as listed in the googel doc https://‌docs.google.com/‌spreadsheets/‌d/‌1biOFTFAlF6wd7nhi5MsSusMokfdbwWII9OXSyfAw2iQ/‌edit?usp=sharing

<Makx> Done poll

issues as in Google Doc

<AndreaPerego> Poll on DCAT2: https://‌lists.w3.org/‌Archives/‌Public/‌public-dxwg-wg/‌2019Jul/‌0495.html

DaveBrowning: There has been tidying up - the doc has all closed issues at the top, then future work , issues due for closing (lots) which I tend to close later in the week
… issues under ColA are effectively still open
… I made a unilateral colour coding decision - yellow = unclear about future course; green = PR fairly advanced; no colour = unclear as to what we're doing
… If colleagues are OK, I'd like to suggest that we start with #725

<DaveBrowning> https://‌github.com/‌w3c/‌dxwg/‌issues/‌725

<DaveBrowning> https://‌github.com/‌w3c/‌dxwg/‌pull/‌1010

DaveBrowning: I want to make sure that this is sorted before holiday season

riccardoAlbertoni: re: 725 - a suggestion in the PR that can include SimonCox views

SimonCox: where is the short report of what is needed to be done?

riccardoAlbertoni: it is in the PR.
… Please can others pick this up whilst I'm away
… #725 and the related PR are affecting all the skos:scopeNote and I'm trying to avoid conflict by merging issues

SimonCox: Thanks riccardoAlbertoni - sorry it got so complicated
… I think you've implemented accurately. well done

riccardoAlbertoni: your suggestions were very helpful
… the solution might be repetitive, but at least we won't lose anything

SimonCox: I'm looking and accepting mostly the comments you made
… the significant contribution we are making is the translations

DaveBrowning: issue #983 - is this superceded?

riccardoAlbertoni: no, because deleting the terms at the beginning that were duplicated gets rid of the link to the definitions, but we need to harmonise
… the previous version used rdfs:comment and the new version uses skos:definition.
… we decided to use both for backward compatibility

DaveBrowning: sounds sensible - we don't want a mess
… SimonCox are you ok taking on #1010
… ?

DaveBrowning: We have discussed #725 and #983

<DaveBrowning> https://‌github.com/‌w3c/‌dxwg/‌issues/‌958

<DaveBrowning> ... about languages and direction marker

DaveBrowning: the remaing 2 with yellow markers are #958 (coming from the internationalisation review, about language tags and direction markers) I'd like to acknowledge the point about direction metadata and that we respond by saying that we know about it and will incorporate later
… so I've marked in the milestone for future work
… Are people happy with that?

+1

<riccardoAlbertoni> +1

<AndreaPerego> +1

<SimonCox> +1

<alejandra> +0

<Makx> +1

Resolved: to add the direction metadata to a future milestone

<AndreaPerego> I think this feature is more fit to https://‌www.w3.org/‌TR/‌Content-in-RDF10/

DaveBrowning: so I've updated the google doc and will incorporate AndreaPerego suggestion
… The remaining yellow (#972)

<DaveBrowning> Next issue https://‌github.com/‌w3c/‌dxwg/‌issues/‌972

DaveBrowning: I cannot parse the thread to get the sense. Has it reached consensus.

SimonCox: I say Steve last week and should have discussed it with him.
… the issue was that I thought he had missed the key point
… he is concerned about the range of foaf:document and then wondered if accessURL should be accessPage
… it might need some finessing to deal with foaf:document
… I will attend to it

AndreaPerego: just a note about foaf:Document - the point is that this class is more generic than the name of the class itself
… it is very generic

SimonCox: I think this is from DCAT 2014

AndreaPerego: the semantics is broader than just 'document'

SimonCox: you are correct AndreaPerego but we are addressing backward compatibility

AndreaPerego: I don't see big issues here
… the problem raised by Steve ended up in also in the wording of props such as accessURL etc
… I don't know if it can be sorted by modifying the wording of the definition
… in DCAT 2014 there was a relationship between landingPage and accessURL - a usage note indicating a soft relationship

DaveBrowning: So is this enough

SimonCox: I am adding a note to the issue capturing some of the discussion we have just had

AndreaPerego: from my side, when working around GeoDCAT-AP and DCAT-AP they were missing the broad notion of landingPage - they were thought to be more for usage with a service than with a dataset
… in DCAT 2014 it was not possible to use landingPage because of a domain restriction

<alejandra> Stephen was referring to the scope notes

<alejandra> so I imagine he will agree on tighten up the text

DaveBrowning: So we have covered the points I thought would be most significant or most simple to deal with, but there are still other open issues on the google doc
… #979 - I'm not sure what we want to do
… DCAT 2014 didn't do anything, btw
… A related topic is how we publish these things on the website. My assumption is that the dcat.ttl is a replacement for the one currently in place. Correct?

SimonCox: Yes

DaveBrowning: Sure?

AndreaPerego: related topic - we had discussions about keeping the old version of dcat.ttl, but I don't know how to do this
… it is about versioning

DaveBrowning: I thought it might work by having the ttl file at /ns/dcat replaced by the new one. we can also use the latitude afforeded by the namespace file to point to the old dcat.ttl and state that we are publishing a backwardly-compatible file
… the old version will therefore be available

AndreaPerego: W3C has a policy for latest and previous versions - perhaps we could use that

PWinstanley: Perhaps we could couch it in an HTML file and use the W3C 'latest' version

riccardoAlbertoni: I was making the same point as AndreaPerego
… we could add a prov statement

<Zakim> AndreaPerego, you wanted to note there are some properties from DCTERMS and ADMS that can be used for linking versions of a vocabulary.

DaveBrowning: can this be covered with phillipe?

PWinstanley: yes - I will prime him with this question

AndreaPerego: There is prior art with ADMS
… we can use this approach

<AndreaPerego> Last version https://‌www.w3.org/‌TR/‌vocab-adms/#adms-last

<AndreaPerego> Next version https://‌www.w3.org/‌TR/‌vocab-adms/#adms-next

<AndreaPerego> Previous version https://‌www.w3.org/‌TR/‌vocab-adms/#adms-prev

<Makx> +1 to andrea

DaveBrowning: I think we need to be careful not to gold plate this.

riccardoAlbertoni: I don't think we can change the old spec, so the warning that is seen on the page should be enough

SimonCox: I will do the conversion to different formats when the time is right

AndreaPerego: I wonder if the server is supporting content negotiation
… we need to clarify what is happening so that we don't add a fudge that then results in inappropriate returns

<riccardoAlbertoni> for DQV we had to explicitly ask for content negotiation

DaveBrowning: The conneg seems to support this, and there is the scope for issues with the version perhaps

DaveBrowning: I think we've concluded

<AndreaPerego> Thanks, and bye!

<DaveBrowning> Bye

<alejandra> bye!