Re: SKOS concept scheme URIs as values for constraints

Its a preparation step but errors in resolving resources should also raise "import error" etc. if expanding fails.

It should also be clear that resolving single resources is not reasonable from large datasets. However, this is very reasonable with small datasets that links to the reference data. For example, when creating new rdf record where user inputs reference to skos concept that should be valid.

----- Original Message -----
From: "Holger Knublauch" <holger@topquadrant.com>
To: "Miika Alonen" <miika.alonen@csc.fi>, "kcoyle" <kcoyle@kcoyle.net>
Cc: "Simon Cox" <Simon.Cox@csiro.au>, phila@w3.org, irene@topquadrant.com, martynas@graphity.org, lehors@us.ibm.com, public-data-shapes-wg@w3.org, public-rdf-shapes@w3.org
Sent: Wednesday, 12 August, 2015 01:43:41
Subject: Re: SKOS concept scheme URIs as values for constraints

Dynamically dereferencing and adding triples at constraint validation 
time will lead to complex concurrency problems. However, I believe that 
building the transitive closure of a graph and "required" triples could 
be done as a preparation step, and parts of the SHACL syntax such as the 
scoping mechanism may be useful here. The syntax you describe below 
(sh:ResolvablePropertyConstraint) may also work, yet I wonder whether 
this info should rather be orthogonal to the schema.

To me this begs the question whether building the closure of a graph 
shouldn't be a topic on its own right, with a separate W3C deliverable 
(which may or may not interact with the SHACL vocabulary). Once a graph 
has been expanded, it could be passed into the normal SHACL validation 
process.

Holger


On 8/12/15 12:15 AM, Miika Alonen wrote:
> +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.

Received on Wednesday, 12 August 2015 07:06:11 UTC