- From: Holger Knublauch <holger@topquadrant.com>
- Date: Wed, 12 Aug 2015 08:43:41 +1000
- 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
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 Tuesday, 11 August 2015 22:44:21 UTC