search

w3c / dxwg

Data Catalog Vocabulary (DCAT)
https://w3c.github.io/dxwg/dcat/
Other
144 stars 46 forks source link

Following the recommendation to use dct:type prevents using SKOS-based reference datasets or standard rdf typing #1362

Closed kvistgaard closed 3 years ago

kvistgaard commented 3 years ago

For example, the scope note of Data service says:

The kind of service can be indicated using the dct:type property. Its value may be taken from a controlled vocabulary such as the INSPIRE spatial data service type vocabulary.

The range of dct:type is rdfs:Class. This creates two serious issues:

  1. Ambiguity for querying rdf:type and dct:type
  2. The best practice for categorisation is to use SKOS-based controlled vocabularies. Concretely I'm currently describing data services of a kind "REST API", "SPARQL Endpoint", "Download Service", and "Human Interaction Service". They are part of a reference dataset, of type skos:Concept, hence individuals in WOL sense. Although OWL2 allows punning, it would be nice if the recommendation does not suggest using classes for categorization, or -- better -- recommend either using SKOS-based controlled vocabularies for categorising of resource or -- where appropriate -- the standard rdf typing.

See also Corporate Reference Data Management policy in the European Commission.

dcat #service

tombaker commented 3 years ago

@kvistgaard Thank you for raising this issue (and thank you @kcoyle for drawing my attention to it)!

FWIW, I agree that rdfs:Class now seems overly restrictive as a range for dcterms:type. We did not foresee your perfectly reasonable use case when ranges were assigned back in 2008.

In a paper we wrote in 2015, @aisaac and I pointed out that the semantically more informal dc:type (i.e., http://purl.org/dc/elements/1.1/type) "does not require an RDFS orOWL class as its object, contrary to rdf:type, which strictly indicates aninstance-class link in the sense of RDFS and OWL" and is therefore a good choice to use with SKOS concepts.

That said, the distinction between the dc: and dcterms: namespaces is perhaps less relevant (or clear) than it once seemed. In DCMI, we still take the Namespace Policy quite seriously, but that did not stop us from loosening a few ranges for the latest version of DCMI Metadata Terms and the related standard, ISO 15836 Part 2. In my personal opinion, adherence to principle must be tempered by recognition of evolving practice; to me, it is more problematic to tighten semantics than to loosen.

The range of dcterms:type has been on the radar of the DCMI usage Board for awhile. If there is support on this list for dropping the range, or loosening it to rangeIncludes -- or opposition to either idea -- I would appreciate hearing your views either way!

tombaker commented 3 years ago

@kvistgaard @kcoyle @aisaac I find to my surprise that the range of dcterms:type has "gone missing" in the latest release - the only significant mistake I have found since its publication in January 2020. I will look into this.

dr-shorthair commented 3 years ago

I have been designing a number of small ontologies using dcterms:type as a kind of supplement to rdf:type for a more informal sub-classification function. Often with a skos:Concept as the range/object. It is useful to have a 'standard' predicate available for this.

andrea-perego commented 3 years ago

Noting that there's a related issue just created: https://github.com/w3c/dxwg/issues/1364

kvistgaard commented 3 years ago

I agree dct:type can be useful but rdfs:range rdfs:Class is very limiting, especially in the general, when types are defined as skos:Concept.

dr-shorthair commented 3 years ago

Is it really 'limiting' - it merely entails that the Concept is also a Class.

kvistgaard commented 3 years ago

It is. Plenty of cases. One is that punning is allowed in OWL2 put not widely accepted. So, dct:type will be restrictive at least in cases when a user wants to either: a) disallow instances to be also classes b) use RDFS but not OWL c) use a flavour of OWL not allowing punning d) use a tool restricting only classes as values for properties with range rdfs:Class

pietervaneverdingen commented 3 years ago

I also need this for the projects I'm working on. And we work with a rapidly growing number of SKOS-based reference datasets.

tombaker commented 3 years ago

Thank you @kvistgaard @dr-shorthair @pietervaneverdingen @andrea-perego for your comments and @kcoyle for bringing this to my attention.

The Usage Board has quickly and unanimously approved the removal of rdfs:Class as the range for dcterms:type.

Unusually, but fortuitously, the documentation for DCMI Metadata Terms and RDF schemas are already consistent with this change due to my own human error, so no change has been made in the specification. I have updated the release notes. We will look for ways to draw more attention to this useful change.

kvistgaard commented 3 years ago

@tombaker why not using dc:type instead, where there is no range? This way DCAT will be compatible with DC, while it won't be the case with DC Terms, when using dcterms:type.

dr-shorthair commented 3 years ago

See the explanation of the two namespaces here https://dublincore.org/specifications/dublin-core/dcmi-terms/#section-1 In particular

In 2008, in the context of defining formal semantic constraints for DCMI metadata terms in support of RDF applications, the original fifteen elements themselves were mirrored in the /terms/ namespace.

While the /elements/1.1/ namespace will be supported indefinitely, DCMI gently encourages use of the /terms/ namespace.

kvistgaard commented 3 years ago

Thanks, @dr-shorthair , I'm aware of that, but for the sake of compatibility, even when a property is just reused, not extending the ontology with owl:imports, the constraints should be respected. Taking up the property without the rule is a common practice, unfortunately, but it can have consequences when merging one graph with full with another with partial re-use of the same ontology.

aisaac commented 3 years ago

@kvistgaard I am not sure the discussion should continue. DCMI has agreed to drop the problematic range for dcterms:type. This was in fact in line with what DCMI wanted to do anyway, it's just that there was an oversight in the previous update. Indeed having rdfs:Class as range is not helpful, even more the perspective of the 'more modern' dcterms: namespace.

Maybe this was not the original intent of your intervention, but trust me this is actually quite a great outcome, thank you again (with my hat of DCMI Usage Board member) :-)

riccardoAlbertoni commented 3 years ago

We are going to close this issue unless there are objections about still open issues.

kvistgaard commented 3 years ago

@aisaac about

DCMI has agreed to drop the problematic range for dcterms:type

can you please provide a pointer to that. And what does it mean in practice? When will it be released?

Regarding my intervention, my hope was to achieve either that or DCAT to recommend using dc:type instead.

riccardoAlbertoni commented 3 years ago

@aisaac about

DCMI has agreed to drop the problematic range for dcterms:type

can you please provide a pointer to that. And what does it mean in practice? When will it be released?

@kvistgaard: I guess the pointer you are looking for is the following, https://www.dublincore.org/specifications/dublin-core/dcmi-terms/release_history/

It seems the change has already been released.