W3C home > Mailing lists > Public > public-dxwg-wg@w3.org > August 2018

Re: [dxwg] Use of dct:type with both Class and Concept

From: starred75 via GitHub <sysbot+gh@w3.org>
Date: Thu, 30 Aug 2018 16:27:26 +0000
To: public-dxwg-wg@w3.org
Message-ID: <issue_comment.created-417381377-1535646445-sysbot+gh@w3.org>
@tombaker brings good news for the future of dcterms.

I think at the basis there is a huge problem with the collapsing of the local names of two very relevant properties. Oh, yes, they are different URIs but I would not use any locally named "type" property when there is such a cumbersome guy called "rdf:type" around.
Certainly none is to be blamed: DC was born after RDF, but when they got married both of them already had their own "type" properties. 

Going to logical aspects, I'm with @jakubklimek and @lvdbrink. Yes there's punning, skos:Concepts can be rdfs:Class or owl:Class (it's written in the skos specs as well) etc... 
...yet having a property which is meant to point to rdfs:Class and then it is going towards generic resources - would be individuals if there were this classification - (I read in some comment that not all of the suggested examples are skos concepts, yet I don't think we are expecting classes) is not gonna help keeping things clean. One thing is that, to the purpose of one ontology somehow merged/imported etc.. with a thesaurus, you want to say that a certain skos:Concept is also a class, one thing is deliberately using a property in the (IMHO) wrong way.
Tom is right, probably DCMI went too far at that time.

Additionally, if we look just from a terminologica point of view, is it really a type? from the suggested target datasets and their data, I see many things that could be topics, genres, maybe "type" would not be what I had in mind.. (yet others could be)

I'd be in favor of using another property or, simply, dc:type (not dct).
@makxdekkers made a point on the existence of existing profiles using dct:type, but at least it was not in the specs of the original DCAT and thus the AP maintainers could in theory continue to use their property and their semantics (possibly redundantly with the new one here if adopting the new DCAT in old data) or, if updating the AP specs to the new DCAT, change the property.

P.S I disagree on the local standards and AP with embedded semantics. This may and will always happen, but at least in principle they should try to be understandable as widely as the World Wide Web.
APs are useful to put together different ontologies, discard some unused properties and tell users which ones to use, concretely suggesting potential target datasets for some properties (as in this case) etc... they should not redefine semantics.
I prefer a world in which if I pull from anywhere a triple such as:
:Mario foaf:knows :Luigi
I'm totally sure that :Luigi is a foaf:Person and not the rabbit pet of :Mario
In my experience, all soft spots in available standards, all those "do it as you wish" create more issues than solutions. But better I stop this "P.S.", I'm on the boundary of being OT ;-)

GitHub Notification of comment by starred75
Please view or discuss this issue at https://github.com/w3c/dxwg/issues/314#issuecomment-417381377 using your GitHub account
Received on Thursday, 30 August 2018 16:27:27 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:42:05 UTC