Meeting minutes
<riccardoAlbertoni> PROPOSED: approve last meeting minutes https://
<AndreaPerego> +1
-0
<riccardoAlbertoni> +1
<DaveBrowning> +1
Resolution: approve last meeting minutes https://
<riccardoAlbertoni> https://
Pending PRs
<riccardoAlbertoni> issue https://
<trackbot> Sorry, but no Tracker is associated with this channel.
AndreaPerego: I made the first try - what was agreed was to define in the RDF vocab a list of inverse props not included in DCAT, and we put them in a separate section of the specification
… the inverses are all moved into a specific section that describes them but references section 6 to the predicates recommended
… The inverses are not meant to be used alone
… but in addition to the forward forms of the predicates
… I also included inverse properties that are already in Section 6. If we go wtih this solution these inverse properties will be removed and placed with the others
… Note that this list of inverses is preliminary and should be open to proposals for including others
riccardoAlbertoni: my impression is that this is a good piece of work in a difficult part of the specification. There may be comments from others in the group who have not been in the meetings, and they might have contrary views, but I think those here agree with the position you've taken. However, for balance, we need to ensure that the whole team is able to comment.
… We can accept the PR, but perhaps it is better to ask the whole team before it is merged
AndreaPerego: perhaps an editorial note stating that this is for discussion is enough, and we can bring to the Plenary
… we can provide inverses as a separate RDF file if that makes it easier for colleagues to settle with them being associated with the recommendation
DaveBrowning: I agree with the general approach - both in the handling of the inverses, and with doing the merge at this point. My concern is the normative status of these predicates, esp the ones already in section 6. The content of section 7, these inverses, are already present in other vocabs and we might get tangled up in the discussions of those vocabs. The editors note needs to point to the goal of providing these inverses, i[CUT]
… of home-grown inverses
… I think that it is the 'right thing' to do
AndreaPerego: I only included in the list inverses to properties already in section 6
<riccardoAlbertoni> https://
AndreaPerego: if there is anything missing, proposals can be made for them to be included. I think this is a general approach
riccardoAlbertoni: The links in the minutes are issues already addressed by the draft - and we need feedback
and
AndreaPerego: we can use #1336 as a placeholder for discussion about the approach
DaveBrowning: Annette makes a going point about updating of metadata after the item has been published - but I think that stability of metadata is a 'good practice' issue. However, there might be other use cases and motivations that allow other approaches to using previous and next for provenance
AndreaPerego: another issue is normalising the graph. The RDF Cube vocab has a section on queries for normalising the graph.
… we might use similar/simpler guidelines
riccardoAlbertoni: Simon raised the point that if we assume that the triples are on the same server we don't need the inverse as that can be determined in a SPARQL query, but when the data are distributed the links in both directions are needed for a 'follow your nose' approach
AndreaPerego: based on discussion we can add the editorial note at the beginning of the section, and perhaps colleagues can edit that if they see need for further clarification - if there is additional text needed then colleagues can make their proposals
<riccardoAlbertoni> https://
riccardoAlbertoni: this PR #1325 was in an earlier one proposed by Simon & with additional suggestions from AndreaPerego . Can this revision be merged?
AndreaPerego: I will check, but it is for Simon to ensure that the change is OK.
AndreaPerego: I think this needs to go to the Plenary - we have tried to address it but there is no reply
riccardoAlbertoni: propose to adjourn
<DaveBrowning> +1
<riccardoAlbertoni> +1
<AndreaPerego> +1
+1