– DRAFT –
DXWG DCAT team

<SimonCox> chair SimonCox

<SimonCox> minutes of last meeting: https://‌www.w3.org/‌2018/‌02/‌07-dxwgdcat-minutes

<SimonCox> audio PWinstanley ??

Confirm agenda

Approve minutes from last meeting – https://‌www.w3.org/‌2018/‌02/‌07-dxwgdcat-minutes

<Stijn_Goedertier_AIV> +1

<SimonCox> +1

0 - wasn't there

<PWinstanley> 0

<DaveBrowning> 0 not there

<Jaroslav_Pullmann> +1

Resolved: Minutes approved

Actions from last meeting

- Review of Requirements in GitHub issue tracker - https://‌github.com/‌w3c/‌dxwg/‌issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+label%3Adcat+label%3Arequirement

<SimonCox> https://‌github.com/‌w3c/‌dxwg/‌issues?utf8=%E2%9C%93&q=is%3Aissue+label%3Adcat+is%3Aclosed+

<SimonCox> https://‌github.com/‌w3c/‌dxwg/‌pulls?q=is%3Apr+is%3Aclosed

<SimonCox> s/waives/waves/

SimonCox: points to closed issues and pull requests

Global constraints - Relax global domain axioms on many dcat properties https://‌github.com/‌w3c/‌dxwg/‌issues/‌110

Pull requests resulting from last meeting’s resolutions - https://‌github.com/‌w3c/‌dxwg/‌pulls

<Makx> presnt+ Makx

SimonCox: Comments on the proposal from Max on global constraints

Jaroslav_Pullmann: Will tooling support be hindered by removal of global axioms?

Jaroslav_Pullmann: Autocomplete in WebProtege may not work?

DaveBrowning: Agree with the approach. More explanatory text is needed. Having the domains there helps to give context, so if we remove them, we need to be more explicit in the descriptions.

+1 on better annotations

<Makx> +1 for annotations

<Jaroslav_Pullmann> +1 for usage of profiles instead

alejandra: Agree with removing global constraints. 2 Questions? Do we need to link to this to a requirement? Any of those restrictions could potentially be added for profiles.

<AndreaPerego> Adding a use case + req makes perfect sense to me.

SimonCox: Comment around Protege. Protege and the RDF editors are to be used at the design phase. When people create records, they most likely don't use Protege.

<AndreaPerego> Agree with SimonCox

SimonCox: I would downplay the importance of editors for these users.

<RiccardoAlbertoni> +1 to SimonCox

Jaroslav_Pullmann: I am convinced now that users will not use editors to create instances.
… profiles are auxiliary documents for documenting if we remove global constraints

<PWinstanley> My colleagues use DCAT for query to get data. http://‌data.sepa.org.uk/‌metadata/‌datacatalog.html - these sort of applications might involve reasoning

<SimonCox> arminhaller: there are tools that use domain and range - form generation tools, but also use guarded restrictions, could use both of those;

<SimonCox> ... if remove domain/ange, replace with guarded restrictions

SimonCox: Let's address alejandra's question around the requirements

<AndreaPerego> +1 to add use case + req as suggested by alejandra

<alejandra> plus we need an analysis of the impact this change would have: in terms of tooling and reasoning

<PWinstanley> +1 to AndreaPerego

+1 to AndreaPerego, adding a use case with the issue on dcat:contactPoint

alejandra: Removing it from the main vocabulary, but add it as a profile, for example.

<alejandra> In the case of contactPoint, Andrea did present a specific use case: https://‌github.com/‌w3c/‌dxwg/‌issues/‌95

<SimonCox> Makx proposes retain domain restriction on For dcat:Catalog: dcat:dataset, dcat:record For dcat:Dataset: dcat:distribution For dcat:Distribution: dcat:accessURL, dcat:downloadURL

<SimonCox> see https://‌github.com/‌w3c/‌dxwg/‌issues/‌110#issuecomment-365526268

ArminHaller: Maybe replace all global constraints and replace it with local restrictions that capture the intent of the original authors of DCAT and then move forward from there.

<alejandra> +1 to reviewing one by one

AndreaPerego: Look at the use cases and see which properties we need to remove global constraints.
… tools that use domain and range restrictions use it in hard-coded way. They may not work any longer.

<RiccardoAlbertoni> +1 to consider the dropping following a case by case approach as andrea is suggesting..

AndreaPerego: it is worth asking people who use tools if the removal would impact their implementation.

SimonCox: back off from having a resolution today on that issue. There needs to be a use case contributed (although that is a modelling issue).

<Jaroslav_Pullmann> we have some meta-use cases within the UCR document, so a new UC would be fine

SimonCox: we have a need to give people the ability to respond to a potential removal of domain/range restrictions
… create an issue per property and have a discussion on a case by case basis

<AndreaPerego> +1

+1

<RiccardoAlbertoni> +1

<DaveBrowning> +1

Jaroslav_Pullmann: the process you suggested makes sense. We have examples of meta modelling use cases already.
… provide a motivation out of the arguments you have provided
… add guidance on the usage on properties where we remove global restrictions

Action: SimonCox to include issues for each property that uses global domain/range restrictions

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

Action: SimonCox and Jaroslav_Pullmann to create meta-use-case

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

<alejandra> For contactPoint there was a specific example from GeoDCAT-AP that Andrea discussed in the issue: https://‌github.com/‌w3c/‌dxwg/‌issues/‌95

<alejandra> it would be good to find similar motivation for further changes in other properties

Action: SimonCox to create set of issues per dcat:property

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

Action: Jaroslav_Pullmann to create a use case that explains the meta modelling requirement for domain/range restrictions on the dcat:ContacPoint

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

<SimonCox> see Local constraints - Use owl:Restriction constraints to bind DC properties to DCAT classes https://‌github.com/‌w3c/‌dxwg/‌issues/‌105

<SimonCox> for related issue

Local constraints - Use owl:Restriction constraints to bind DC properties to DCAT classes https://‌github.com/‌w3c/‌dxwg/‌issues/‌105

we discussed this in the context of the above

Dependencies – continue discussion from https://‌www.w3.org/‌2018/‌01/‌31-dxwgdcat-minutes#x06 and https://‌github.com/‌w3c/‌dxwg/‌issues/‌111

Dependencies – continue discussion from https://‌www.w3.org/‌2018/‌01/‌31-dxwgdcat-minutes#x06 and https://‌github.com/‌w3c/‌dxwg/‌issues/‌111

SimonCox: DCAT has dependencies on several ontologies, e.g. DC-Terms, SKOS, FOAF, potentially PROV in the future
… only SKOS and vCard are W3C standards
… and PROV, if we add it, but the others are popular vocabularies on the Web
… including them introduces risks, but also efficiencies if they are used
… NicholasCar and Makx have asked if there are more opinions on that issues
… another questions was around the ORG ontology and a Person ontology (which I am not familiar with)

<PWinstanley> https://‌joinup.ec.europa.eu/‌page/‌core-vocabularies

SimonCox: if we adopt PROV, the agent class is potentially replicated

<Jaroslav_Pullmann> Nicholas, what is the rationale of including org-ontology?

<AndreaPerego> ISA Core Person Vocabulary: https://‌www.w3.org/‌ns/‌person

SimonCox: we may end up with some axiomatization that is not intended

<Makx> Yes it's the W3C one https://‌www.w3.org/‌ns/‌person

NicholasCar: reusing old ontologies may be a problem in regards to what happened in the meantime. Dublin Core, in particular.

<SimonCox> org, prov, person, foaf all have agent-ish classes and do not necessarily have clear relationships

<SimonCox> also vCard implicitly

NicholasCar: For ORG, we may want a better handling of groups which is not done in FOAF
… broader set of metadata available if we allow a more sophisticated agent handling

+1 for NicholasCar for a better agent handling allowing groups

<Makx> No need for change in DCAT I think. org:Organization is a subclass of foaf:Agent anyway.

SimonCox: One of the modelling solutions is to define a local agent class and describe its relations to external vocabularies

<Makx> It seems to me that foaf:Agent/dct:Agent are broad enough.

AndreaPerego: In our case we associate the authors to the Dataset. We need to assign the affiliations of the authors. We can't do that in FOAF, so we use the ORG ontology.
… metadata coming from CrossRef, for example, we add this metadata using the external vocabularies

<Makx> I think it is perfectly fine to describe a foaf:Agent with properties from ORG

AndreaPerego: if we have a tool that only understands FOAF, for example, everything that is related to ORG, it will be ignored

Jaroslav_Pullmann: We looked at the ORG ontology, but we had a hard time to see the extra benefit of the ORG ontology.
… we don't need to import

<AndreaPerego> The ORG property I mentioned to specify affiliation is https://‌www.w3.org/‌TR/‌vocab-org/#property-memberof

alejandra: Agree to not importing the whole ontology.

alejandra: we should use what we need from ontologies, but be minimal and not use a local class.

<Makx> I fail to see the problem here. DCAT only declares the range of one of its properties to be a foaf:Agent. Nowhere is it said that you can only use FOAF properties to describe a foaf:Agent.

SimonCox: the ORG ontology's primary functions are organisational history and structure
… the tricky one will be PROV-O. with the agent class

<NicholasCar> Agree with just using ORG where needed if foaf:Agent already used

<Makx> DCAT actually says nothing about how to describe agents.

<NicholasCar> Agree too that PROV Agent more difficult

<SimonCox> arminhaller: need to make clear that dcat classes and properties are consistent with the other W3C ontologies

PROPOSED: The preference as a general rule will be not to import ontologies

<RiccardoAlbertoni> +1

+1

<alejandra> +1

<SimonCox> +1

<AndreaPerego> +1

<Stijn_Goedertier_AIV> +1

<Jaroslav_Pullmann> +1

<NicholasCar> +1

<DaveBrowning> +1

Resolved: The preference as a general rule will be not to import ontologies

<PWinstanley> +1

<Makx> +1

<NicholasCar> I import in Protege for dev then delete imports before publication!

<SimonCox> https://‌github.com/‌w3c/‌dxwg/‌issues/‌53

SimonCox: I have dominated the agenda so far, I am inviting members to use the mailing list to propose topics
… there was a lot of discussion on versioning earlier, maybe someone from that set of people can propose an agenda item

AndreaPerego: Another issue, I want to raise an issue if we can use DCAT terms also for Catalogs or other data sources, not only dcat:Dataset
… other type of resources should be supported other than datasets

Jaroslav_Pullmann: There are comments on the UCR document, the dynamic access to data, paramaterialised URIs. we need to look at those.

<Jaroslav_Pullmann> bye

<alejandra> thanks, and bye!

<AndreaPerego> Thanks, and bye!

<RiccardoAlbertoni> Thanks for the interesting discussion, bye

<PWinstanley> bye

<Makx> bye