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

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

From: Marco Brattinga via GitHub <sysbot+gh@w3.org>
Date: Mon, 27 Aug 2018 10:23:31 +0000
To: public-dxwg-wg@w3.org
Message-ID: <issue_comment.created-416183190-1535365410-sysbot+gh@w3.org>
I totally agree with the statement "DCAT users should be free to use 
whatever reasoning and entailments they choose". I do have some concerns 
with regard to using terms from other vocabularies and the question of 
committing to the same ontological commitment as the original vocabulary 
(e.g.: committing to the assertions that are part of the vocabulary 
definition, like the rdfs:range assertion). It seems to me that you 
should, or else use something more appropriate - or create your own 

It's very interesting that the Dublin Core community is leaning to a 
more soft approach. This would indeed resolve the issue, and make the 
use of dct:type less problematic.

As a DCAT user ourselves, two solutions seem reasonable:
- using dct:type, as is already been done in de adms vocabulary and de 
DCAT-AP-EU profile, expecting the Dublin Core community to "remove" the 
rdfs:range assertion;
- create some new property in the DCAT vocabulary, that has exactly the 
intended semantics as needed for the DCAT vocabulary, expecting that new 
versions of adms and the DCAT profiles should be created as a response 
of a new version of the DCAT vocabulary.

With respect to the use in Topbraid, I agree that this is not a very 
strong argument, it's simply one of the examples users might (and in our 
case - will) run into.


On 2018-08-27 03:46, Rob Atkinson wrote:
> There is nothing that forces anyone to resolve a dct:type object
> reference and do any inferencing over it.
> If you chose to load both the dcterms RDFS model and resolve the
> dct:type reference and find the RDFS model for the referred object,
> then you would naturally have to accept the intention of the data
> publisher (not the DCAT specification) that any skos:Concepts are
> indeed "units of thought" that represent (and entail) rdfs:Class
> Distributed reasoning means there must be sophisticated contract that
> actually makes URI references to objects, intrinsically as instances
> of things, link to a class model.
> TopBraid, for example, has a bunch of built in assumptions that some
> graphs are loaded - and this is a mixture of explicit OWL imports,
> (perhaps also TBC controlled imports smuggled into comments in TTL
> files?) , and reflection based on "magic" patterns in file names in
> projects, whose Eclipse UI controlled open-or-closed state determines
> if they are loaded. Its kind of horrible, but seems a fair reflection
> of the reality that the application context is responsible for
> determining the graph to reason over, and any entailment regimes.
> So, I dont see a reason why the project discussed cannot make its mind
> up that all references must have a rdfs:Class axiomitisation, and that
> resources resolved from URIs they use are constrained to be OWL-DL. I
> think to flip the argument on its head, it seems unwise to force such
> assumptions on everyone. DCAT users should be free to use whatever
> reasoning and entailments they choose.
> That said, the existence of examples that do implicity rely on
> (perfectly legal) OWL punning interpretations should carry an
> explanation that some examples do assume an environment where punning
> between skos:Concepts and rdfs:Class is allowed, and that DCAT itself
> does not dictate this either way.
> --
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub [1], or mute the
> thread [2].
> Links:
> ------
> [1] https://github.com/w3c/dxwg/issues/314#issuecomment-416091796
> [2]
> https://github.com/notifications/unsubscribe-auth/AHWLeSBz4ro1xeS-_xGSolK4BvsnsL-Vks5uU09dgaJpZM4WBC7i

GitHub Notification of comment by architolk
Please view or discuss this issue at https://github.com/w3c/dxwg/issues/314#issuecomment-416183190 using your GitHub account
Received on Monday, 27 August 2018 10:23:32 UTC

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