- From: Armin Haller via GitHub <sysbot+gh@w3.org>
- Date: Tue, 20 Feb 2018 02:09:34 +0000
- To: public-dxwg-wg@w3.org
As @philarcher pointed out in https://github.com/w3c/dxwg/issues/131#issuecomment-366165887 there has been a tendency lately to stay clear of domain/range restrictions in ontologies, since it is hard to anticipate consumer behaviour, i.e. the way the ontology is used. In the past, global constraints have been used to impose a certain use of properties on the user. However, it has been shown in many applications (particularly in federated querying and search on the semantic Web, e.g. [1]) that these global constraints are leading to undesired issues (naïve users tend to think of domain and range restrictions as constraints, too). Guarded local constraints are achieving a similar purpose (i.e. suggesting a specific use of a property) without the undesired side-effects of global constraints. They should be accompanied with a better documentation of the property, which can include domain/rangeIncludes annotation properties. Deprecating domain/range restrictions (i.e. relaxing the semantics) cannot, however, "brake" any current use of DCAT. The only way it can have an impact is, if an application wrongly relies on domain/range restrictions only for auto-completion or faceted browsing. We agreed in our last phone conference that we need to investigate if that is the case with current DCAT implementations. I also agree that there is no need for a seperate namespace. However, there can be a lightweight profile of DCAT in a seperate namespace that the new version of DCAT imports and extends (under the old DCAT namespace). We went down this route with SOSA/SSN and I am happy to outline our reasoning and design choices in the telco. [1] http://ceur-ws.org/Vol-628/ldow2010_paper04.pdf -- GitHub Notification of comment by arminhaller Please view or discuss this issue at https://github.com/w3c/dxwg/issues/110#issuecomment-366847350 using your GitHub account
Received on Tuesday, 20 February 2018 02:09:38 UTC