– DRAFT –
DXWG DCAT subgroup meeting

<riccardoAlbertoni> PROPOSED: approve last meeting minutes https://www.w3.org/2021/06/09-dxwgdcat-minutes

<riccardoAlbertoni> +1

+1

<AndreaPerego> +1

<PWinstanley_> 0 - absent

Resolution: approve last meeting minutes https://www.w3.org/2021/06/09-dxwgdcat-minutes

<riccardoAlbertoni> https://www.w3.org/2017/dxwg/wiki/Meetings:Telecon2021.06.23

Defining a consistent approach to deal with inverse properties -

<riccardoAlbertoni> https://github.com/w3c/dxwg/issues?q=is%3Aissue+is%3Aopen+label%3Ainverse-properties

riccardoAlbertoni: General issue around inverse properties and diverse views
… Some people want inverse properties (either specific examples or as general principle)
… Also have people strongly opposing
… having two directions makes things harder for publishers and consumers
… Discussion a few months back were inconclusive

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

riccardoAlbertoni: PROV took approach of standardising one direction only
… but 'reserve' the name for the inverse if people wanted to use it - so that we don't end up with many slightly different versions
… Suggestion to mimic PROV wasn't enthusiastically received.
… Can we progress this issue area?

AndreaPerego: Interoperability is affected if we have too many options but in many cases there are use cases which need to have both
… For example various forms of display.

If

AndreaPerego: If we don't provide it people will mint there own (different ones)
… We have seen use cases for specific cases where inverses are needed.
… DCAT doesn't have a consistent approach to naming like PROV.
… Perhaps, add new section in normative part, called "Inverse properties" which gather the optional inverses
… These could be used as additional terms

PWinstanely: Strongest argument is that people will do it themselves unless we provide some organisation
… Do we have any symmetrical properties we would need to cover?
… Would it restrict some uses of reasoners?

riccardoAlbertoni: Probably not.
… At beginning of REC we say we are not bound to a particular implementation technology
… but we are hearing that some technologies do have constraints and weaknesses that make the inverses necessary
… If we provide a section are we really axiomatising?

AndreaPerego: Perhaps we do step by step - update text specification and then discuss updating RDF

riccardoAlbertoni: If we did want to provide RDF we could keep this in a separate file

PROPOSED: Prepare draft along this approach and then use review to refine

<AndreaPerego> +1

<riccardoAlbertoni> +

+1

<riccardoAlbertoni> +1

<PWinstanley_> +1

Resolution: Prepare draft along this approach and then use review to refine

AndreaPerego: I'm happy to prepare the draft

Action: AndreaPerego to prepare a draft of a new section on inverse properties

<trackbot> Error creating an ACTION: could not connect to Tracker. Please mail <sysreq@w3.org> with details about what happened.

Open issues on data services - specification of output format /schema, services with multiple endpoints https://github.com/w3c/dxwg/projects/12

AndreaPerego: Overall, there are a number of issues asking about some gaps in what we say to data services
… Some are rooted in early conversations we had in DCAT 2 where we decided that we didn't want to take on describing all kinds of API
… So we provide a link to an description of the endpoint. But we have requests for this to include particular features such as metadata schemas supported etc
… These requests came from different domains/customers - suggests we should provide more guidance on what kind of features (e.g. languages supported)

<Zakim> AndreaPerego, you wanted to note that minutes are not getting updated

AndreaPerego: we should decide whether we want to deal with this and how
… Also different urls can get confused across different end point descriptions

riccardoAlbertoni: re: Different point for same services - why is this an issue

AndreaPerego: It obscures the link between the services - these are like distributions for the same dataset
… We do seem to have examples where we have the same service but different end points

riccardoAlbertoni: My concern is that by changing this stuff about end point that we break something - we need to remain consistent with DCAT 2

AndreaPerego: Suggest we focus on output formats, query languages etc
… then see if we can address the others once we done something

riccardoAlbertoni: There is already a way to specify this, but more than one way outside of DCAT.

AndreaPerego: Not suggesting that we try to fix that problem

<PWinstanley_> DaveBrowning: what you're suggesting is the thin end of a wedge - we need to be clearer about the characteristics relevant to description of the endpoint that relate to DCAT and nothing more

<PWinstanley_> ... and we should stick to having a go at that, using real examples, and not get sucked into the detail of anything other than what this means for DCAT

<PWinstanley_> ... I think we should try to improve the situation

PWinstanley_: This could be a bit of a tar ball of a problem
… does "conforms to" help?

AndreaPerego: Not particularly (at least as we understand it)
… Work on schema.org extensions for various domains has been done - perhaps we can look the approaches taken there as inspiration

riccardoAlbertoni: Perhaps part of the issue is the limited number of examples we have

AndreaPerego: We can look at whats been asked for (via github etc) - eg clearly related to DCAT. People are interested in parameters for queries for example but this is going a bit too far
… Address the closest things and then see where we are

AndreaPerego: Follow this up in the next call after we've done our homework? We can decide (if we meet 7th July)