Closed kvistgaard closed 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!
@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.
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.
Noting that there's a related issue just created: https://github.com/w3c/dxwg/issues/1364
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
.
Is it really 'limiting' - it merely entails that the Concept is also a Class.
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
I also need this for the projects I'm working on. And we work with a rapidly growing number of SKOS-based reference datasets.
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.
@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
.
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.
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.
@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) :-)
We are going to close this issue unless there are objections about still open issues.
@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.
@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.
For example, the scope note of Data service says:
The range of dct:type is rdfs:Class. This creates two serious issues:
rdf:type
anddct: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