You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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:
@dr-shorthair uses
dct:type
"as a kind of supplement tordf: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:
anddcterms:
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.
The text was updated successfully, but these errors were encountered: