Dxwg: DCAT dependencies

[dr-shorthair]

Which external vocabularies should DCAT have dependencies on?
Currently: dcterms, skos, FOAF (very little), vCard (very little).
Proposed: prov-o #94, adms #53

1. Which vocabularies do we trust?
2. How should dependencies be captured - through <owl:imports> or simply by mentioning class/property names?

Discussion was started in DCAT meeting https://www.w3.org/2018/01/31-dxwgdcat-minutes#x06 but not finished.

[nicholascar]

I think we should consider ORG and perhaps ORG instead of FOAF (it's more recently/better formalisms). Also PROV will likely become a dependency.

[dr-shorthair]

ORG also uses (depends on) FOAF, but does not import it.

The general style in w3c ontologies appears to be to avoid using owl:imports, but rely on just mentioning external resources. That's probably fine in the published version. Nevertheless, it is convenient to use owl:imports during development so all the content of the dependencies are visible in the IDE (protege, topbraid, etc).

[dr-shorthair]

If we adopt both PROV and ORG and FOAF we should consider if any axiomatization around foaf:Agent and prov:Agent is warranted.

[makxdekkers]

@nicholascar Again we need to be careful not to make changes that would break existing implementations. I think DCAT 1.0 is in error recommending resources of type foaf:Agent as the range of dct:publisher, because the range of that property is formally defined as dct:Agent. If I remember correctly, there were plans to create an owl:sameAs between dct:Agent and foaf:Agent but I don't see that in the specifications. org:Organization is formally declared to be a subclass of foaf:Agent.
This leaves the case where a publisher is a person, for which person:Person from the Core Person Vocabulary could be used, which is declared a subclass of foaf:Person, a subclass of foaf:Agent.
But, in any case, we would not want to replace the current range definitions, and definitively not by making them narrower, to avoid breaking existing implementations.

[nicholascar]

@makxdekkers PROV has an Agent class and a Person class too. Use of them would allow for dct:publisher to point to an individual. PROV doesn't import anything but people interpret it's Person and Agent in relation to FOAF.

[jpullmann]

Topic: _Motivation for ORG-Ontology_
In course of the telcon discussion on re-use of some ORG concepts Andrea mentioned a property to specify affiliation: https://www.w3.org/TR/vocab-org/#property-memberof

foaf:Agent org:memberOf org:Organization

Possible, but inverse alternative could be: http://xmlns.com/foaf/spec/#term_member

foaf:Group foaf:member foaf:Agent

Badly, foaf:member does not apply to foaf:Organisation, the another "collection"-like concept.
In this particular case a decision should be made, whether foaf:Group is appropriate for purpose of
affiliation reference or the org:memberOf property should be used..?

[nicholascar]

@jpullmann yes, we have used the foaf:member inv. org:memberOf in the past. It's nice to have the property pointing from the Agent to the Org but we cal live with foaf-only and use the inverse.

Regarding FOAF/ORG use: on reflection, perhaps it's fine to just point to foaf:Agent for related agents, given that they are also org:Agents and leave outside of DXWG scope any properties of the Agent, which would be the territory of FOAF/ORG. As long as we establish a good pattern of qualified Dataset -> Agent relations so we are not bound to a few dct properties like creator.

Dealing with prov:Agent might to be harder but perhaps need not be. Clearly a prov:Agent is just a superset of foaf:Agent.

[makxdekkers]

I am in favour of keeping descriptions of Agents out of scope for DXWG.
Where do you see that prov:Agent is a superset (superclass?) of foaf:Agent? Their semantics look very similar.

[dr-shorthair]

prov:Agent is sometimes a piece of equipment ...

[nicholascar]

A PROV Agent is something with agency this in PROV, People are Agents but a SoftwareAgent is too. PROV doesn’t go too far in defining what can have agency but we can easily interpret its intention for its Agent as FOAF Agent superset

[makxdekkers]

@dr-shorthair FOAF Agent is defined as "_An agent (eg. person, group, software or physical artifact)_" (my emphasis) so it can include a piece of equipment as a physical artifact.
@nicholascar Again, the definition of FOAF Agent includes "software", so I don't see the fundamental difference between FOAF and PROV Agents.
Just saying I don't think there is a clear case that one of them is broader or narrower than the other. But maybe this is not a useful discussion. Let's drop the point.

[dr-shorthair]

Thanks @makxdekkers @nicholascar - should have done my homework.
In that case it appears that

prov:Agent rdfs:subClassOf foaf:Agent . 

being the subclass of agents that have participated in prov:Activitys ?

As suggested by @philarcher in https://github.com/w3c/dxwg/issues/131#issuecomment-366165887 perhaps we should follow the lead of SSN/SOSA and provide alignment axioms (to PROV, ADMS?, ...) in separate graphs to the basic DCAT specification, which in its basic form should be as weakly axiomatized as possible.
This will allow DCAT users to choose the level of axiomatization/ontological commitment that they need.

@arminhaller maybe we should brief DXWG on horizontal/vertical modularization pattern.

There is almost certainly an overlap with the Profiles discussion here.

[dr-shorthair]

94 has been modified so that there is a separate module to hold DCAT-PROV alignment axioms

[nicholascar]

Thanks @makxdekkers for revealing those FOAF definitions! Apologies for also not having revisited the definitions to check.

Happy to use foaf:Agent, given that we may not know about any Activities that an Agent participated in.

[davebrowning]

Although this is linked to a number of other open issues, all of them are marked for the future priority milestone or are dependent on other work. The dependencies for DCAT may change for future versions of DCAT but in the context of DCAT 2, the dependencies are listed at https://w3c.github.io/dxwg/dcat/#normative-namespaces. Propose closing this.