Meeting minutes
<pchampin> Présent+
spre
<Caroline_> https://
proposed: accept the meeting minutes https://
<Caroline_> +1
+1
<Nobu_Ogura> +1
<pchampin> +0
<annette_g> +1
RESOLUTION: accept the meeting minutes https://
proposed: setting a doodle to decide the proper plenary meeting time
+1
<Caroline_> +1
<annette_g> +1
<pchampin> +1
<Nobu_Ogura> +1
RESOLUTION: setting a doodle to decide the proper plenary meeting time
Caroline_: I can prepare the doodle
DCAT subgroup
riccardoAlbertoni: DCAT subgroup discussed editorial issues
<riccardoAlbertoni> https://
riccardoAlbertoni: suggested updates on turtle file as it is indicated on the link above
<riccardoAlbertoni> https://
<riccardoAlbertoni> https://
riccardoAlbertoni: we decided what is on that link https://
… the privacy group replied here https://
<riccardoAlbertoni> https://
riccardoAlbertoni: I am starting to draft a response and will share with the Plenary and also the other editors https://
… if you have any considerations, please let me know
<pchampin> https://
riccardoAlbertoni: I haven't had the time to look at this issue Definition of dcat:spatialResolutionInMeters incompatible/problematic with JSON-LD https://
<riccardoAlbertoni> pchampin: problem with JSON number xsd:decimal, long discussion on whether the problem is about JSON-lD or xsd
pchampin: for DCAT, I believe that the solution would be to accept both xsd:double and xsd;decimal for that property
<Zakim> annette_g, you wanted to make a suggestion about the checksums and to
<riccardoAlbertoni> pchampin: I am going to prepare a PR
<riccardoAlbertoni> annette_g: I wonder how difficult is for people to read the two types
<riccardoAlbertoni> pchampin: I think this should not impact much, I need to doublecheck
<riccardoAlbertoni> pchampin: when you put a number in JSONLD is canonilize in the e notation, and that is part of the problem
<riccardoAlbertoni> annette_g: I do not know I have to think about how it impact
<riccardoAlbertoni> pchampin: the verifiable credential describe the solution suggested by annette, verifiable credentian are a way to embed the graph, together with metadata including cryptographic signature,
<annette_g> annette_g: we need to provide some guidance for how to let users know how a checksum was calculated. Could we add a property that is the URL of a description of how it was calculated?
riccardoAlbertoni: I think we should point to possible solutions, but the DCAT it is not a Best Practice document. It could be risky to provide it. I am not sure we are in the position to have a deep discussion about it and
… it is a new requirement. An important one, but we are at the end of the standarization
… if the proposal goes forward, I suggest to include it
pchampin: I can propose an additional task
how verifiable credential work with the efforts coming from other groups?
annette_g: how verifiable credential work with the efforts coming from other groups?
annette_g: If we include checksum for distribution we need to admit that the integrity opf metadata is in scope
<annette_g> annette_g: a checksum is absolutely no use if it is not calculated in the same way each time. I don't believe we can offer a property that is a checksum without dealing with this issue.
riccardoAlbertoni: I think we need a document about the security and integrity to provide guidance
… I don't think it is only a DCAT problem
… I agree we must acknowledge that the integrity of metadata is included
… at the same time, the solution that is been required is at the same level of DWBP, which is more transversal
… I don't think we are in the position to do it, since the recommendation is to make a DCAT standard, not best practices
pchampin: the standards are going to be complementary
… +1 that we should not try to reinvent the wheel
… let's point to existing standards that already talk about it
annette_g: I think it is hard to get people to adopt the verifiable credentials
<riccardoAlbertoni> annette_g: one concern is that adopting verifiable credential can be a barrier to the adoption of checksum
pchampin: the way they define thing is very general, verifiable credential require jsonld, i can simpatize with your worrying, but at least it is something we can point at
pchampin: I am wary to trying to come up with owr own naive solution
annette_g: no one wants that
<annette_g> annette_g: I wouldn't want us to limit the utility of the checksum property to those who are using json-ld or verifiable credentials.
<annette_g> ... If we use a URL, that can be used to link to any method of generating the checksum. What's important is that we enable people to indicate this aspect of the checksum.
<annette_g> ...I don't think the checksum proposal is complete enough for real world use without this.
riccardoAlbertoni: I wonder if we need to put this as a requirement for other groups
… if I understand annette_g concerns, what we are doing is not covering all that DCAT need to address
… perhaps instead of doing a wide solution we could see the missing parts
… which requirements of other groups could contribute
… for instance, in the case of RDF, there is another group working on it. So we could put our requirements
annette_g: you are not comparing the same things
… we trying to ensure that what we are downloading is accurate
… we want the metadata to be public so we need a trustful source
<pchampin> https also guarantees that you are "talking" to the genuine server
annette_g: I didn't find anything about it yet
<pchampin> https://
<annette_g> annette_g: https doesn't ensure that the server you contact is authoritative, only that it is run by the person who requested the certificate.
<pchampin> yes, my bad :)
riccardoAlbertoni: I am not sure there is a guide to achieve it
pchampin: I will check about it
<annette_g> annette: the issue arises because it's not obvious how to generate single checksum for multiple files, and which files are included