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: Wed, 22 Aug 2018 05:58:25 +0000
To: public-dxwg-wg@w3.org
Message-ID: <issue_comment.created-414920723-1534917504-sysbot+gh@w3.org>
Apart from inference considerations, the immediate issue we ran into 
(and actually the way we found out that something fishy was going on), 
was the way that Topbraid Composer uses the rdfs:range assertions for 
determining the list of available values while editing a new resource of 
a particular (rdf:type) class.

For example, let's say that we would like to create a new asset (e.g. of 
rdf:type adms:Asset), and let's say that we would like to add a triple 
with this new asset as subject, and predicate dct:type. Topbraid will 
then give us a list of possible values for the object, containing 
resources of (only) type rdfs:Class. There is no option to select a 
resource of type skos:Concept, what we would like to do in this case 
(according to the adms profile).

The only option we have, is to manually change the dct ontology, 
removing the rdfs:range assertion, or changing it accordingly (and of 
course we could make our skos:Concepts of type rdfs:Class, but that is 
not something we want to do - we would like our concept schemes separate 
from our ontologies).

Although using something like SHACL is more appropriate for deriving 
user interfaces from RDF models IMHO, current state of business is that 
editors (like Topbraid) will look for rdfs:domain and rdfs:range 
assertions, as we found out the hard way.

Marco

On 2018-08-17 10:28, Rob Atkinson wrote:
> Really interested in the take of others here - there are a couple of
> ways of looking at this - but I have never been able to find a cogent
> argument why we shouldnt assume that a rdfs:Class is actually a type
> of skos:Concept - classes are nothing more that concepts that define
> sets of instances.
> 
> It seems to be explicitly supported in OWL 2 as "punning"
> [https://www.w3.org/2007/OWL/wiki/Punning]
> 
> It seems a perfectly natural Use Case to me to model skos:Concepts as
> types in systems, then generate rdfs: and owl Class models only if and
> when we need to model additional behaviours.
> 
> skos:Concept is relevant for "soft-typing" and rdfs:Class for
> hard-typing - and the equivalence is actucally a useful thing.
> 
> Is OWL-Full really a problem? I think not for several reasons:
> 
>  	* I dont see evidence that OWL-DL (or any other flavour) inferencing
> is happening at run-time across distributed systems - all "semantic
> web" implementations I have see cache any models they want to use.
>  	* There is currently no way of telling a client, not specification,
> constraining referenced models to be any particular profile of OWL -
> so no assumptions can be made anyway
>  	* With negotiation-by-profile the same concept can be served with a
> graph that conforms to SKOS, RDFS, OWL-DL, OWL-Full, SHACL and any
> other specific profile needed by a client.
> 
> IMHO there is a need to provide a specific example of the problem and
> why its a problem, and how to handle the use cases of soft-typing.
> 
> My feel here, although I can prove it, is that negotiation by profile
> and OWL 2 punning are two sides of the same coin - implementation and
> theory, and essentially we can get out of the bind by the URI
> dereferencing architecture - OWL-DL reasoners can ask for the
> metaclass representation they want.
> 
> Default behaviour for OWL - i.e. if a client asks for OWL perhaps an
> OWL-DL representation SHOULD be returned. I dont know if the profile
> guidance or content negotiation scope will allow us to go into this
> platform specific detail - or where and who in W3 cares about the
> general architecture of distributed OWL models?
> 
> --
> 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-413795569
> [2]
> https://github.com/notifications/unsubscribe-auth/AHWLeQdPATAfRQ1pIeOnFCAw6yOwiTG6ks5uRn6VgaJpZM4WBC7i


-- 
GitHub Notification of comment by architolk
Please view or discuss this issue at https://github.com/w3c/dxwg/issues/314#issuecomment-414920723 using your GitHub account
Received on Wednesday, 22 August 2018 05:58:27 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 30 October 2019 00:15:45 UTC