Re: SKOS concept scheme URIs as values for constraints

+1. I agree that there are lot of variants, but in general its fairly common requirement and loading references from external datasets separately is tedious. I dont think that it is possible to cover all of the variants, but it should be possible cover cases that use skos:inScheme, or any other membership predicate. Usually concept schemes dont describe what concepts are part of the scheme, but it is or SHOULD BE best practice to state the scheme that concept is in with skos:inScheme. 

One general solution would be to support some mechanism for resolving resources. I dont know if there has already been discussions about dereferencing resources? Or is the UC28 dismissed? Maybe it isnt "core issue", but it would be very useful. 

I hope that SHACL could support something like this: 

ex:MemberShape
	a sh:Shape ;
        sh:scopeClass foaf:Agent ;
	sh:property [
                a sh:ResolvablePropertyConstraint # would state that values of this predicate in this shape should be resolved and included to the data graph.
		sh:predicate org:memberOf ;
		sh:valueShape ex:OrganizationInScheme .
	] .

ex:OrganizationInScheme # Shape of the resolved instance that is dereferenced and included to the data 
	a sh:Shape ;
	sh:property [
		sh:predicate skos:inScheme ;
		sh:hasValue <http://id.loc.gov/authorities/names>;
	] .

ex:ValidMember a foaf:Agent ;
    org:memberOf <http://id.loc.gov/authorities/names/no96041976> . # Based on ex:MemberShape and its ResolvablePropertyConstraint this should be resolved. ERROR if not resolvable.

<http://id.loc.gov/authorities/names/no96041976> a skos:Concept ; # Resolved triples that are added to the data graph. ERROR if some properties/values are missing.
 skos:inScheme <http://id.loc.gov/authorities/names> .

This could be used with the SKOS scheme use case or any other similar use cases where resolved resource should have some properties. Alternative solution would be to use remote sparql constraints, which could be used when resources are not deferenceable.

Best Regards,
Miika Alonen

CSC - IT Center for Science
miika.alonen@csc.fi

----- Original Message -----
From: "kcoyle" <kcoyle@kcoyle.net>
To: "Simon Cox" <Simon.Cox@csiro.au>, phila@w3.org, irene@topquadrant.com, martynas@graphity.org, lehors@us.ibm.com, holger@topquadrant.com
Cc: public-data-shapes-wg@w3.org, public-rdf-shapes@w3.org
Sent: Monday, 10 August, 2015 22:05:00
Subject: Re: SKOS concept scheme URIs as values for constraints

+1. Given that this is a very common requirement, but one with a lot of 
variants, even seeing a few examples of how it might be solved would be 
a step forward. A similar discussion [1] looked at how one might convey 
information about remote services and negotiate protocols or profiles. 
If SHACL fits in at any point in this workflow, it would be nice to know.

kc
[1] 
https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind1505&L=DC-ARCHITECTURE&F=&S=&P=9589

On 8/10/15 4:13 AM, Simon.Cox@csiro.au wrote:
> But it is a genuine requirement, so I wonder if we could at least walk through how it might look if there were a suitable practice for publishing vocabularies and registers.

-- 
Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
m: 1-510-435-8234
skype: kcoylenet/+1-510-984-3600

Received on Friday, 14 August 2015 19:10:50 UTC