Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Range of dcterms:type #100

Closed
tombaker opened this issue May 20, 2021 · 3 comments
Closed

Range of dcterms:type #100

tombaker opened this issue May 20, 2021 · 3 comments

Comments

@tombaker
Copy link
Collaborator

dcterms:type is at issue in the W3C Data Exchange Working Group, as its range (rdfs:Class) makes it hard to distinguish from rdf:type and makes it formally unsuitable for use with SKOS concepts.

For @kvistgaard, the range 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.

@dr-shorthair uses dct:type "as a kind of supplement to rdf:type for a more informal sub-classification function", often with a SKOS concept as value.

In my response to the issue, I expressed support for the idea of loosening (or dropping) the range, adding:

"""
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.
"""

After pressing send, I looked in DCMI Metadata Terms and discovered, to my surprise, that the range has simply gone missing!. This embarrassing omission is clearly my mistake, as I was the one who ported the terms to the new Hugo website and was the only one who edited the entries based on decisions we took in the Usage Board.

The idea of dropping this range has come up before such as in a 2018-05-30 meeting in which we postponed the issue until pending completion of the ISO 15836-2 review process.

@aisaac points out that dcterms:type is frequently used with SKOS concepts as object, which causes things never thought of as classes to be inferred to be classes.

@tombaker
Copy link
Collaborator Author

tombaker commented May 20, 2021

APPROVED

To drop the range of rdfs:Class for dcterms:type.

Rationales:

  • With the range of rdfs:Class, things never thought of as classes are inferred to be classes.
  • The property is already widely used with SKOS concepts as object.

Approved by: Tom, Karen, Antoine, Osma, Phil, Stuart, Kai, Dan, Stefanie, Joachim.

Approval is unanimous among UB members who voted, with no nay votes or abstentions.

@Dlcowjd7252

This comment has been minimized.

@ProfetaJuan
Copy link

He leido.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants