Re: shapes-ISSUE-80 (Scheme URIs): Constraint to limit IRIs against scheme/namespace, possibly with dereferencing [SHACL Spec]

Sorry for the reposts - dont know how that happened.

- Miika

----- Original Message -----
From: "Miika Alonen" <miika.alonen@csc.fi>
To: public-data-shapes-wg@w3.org
Sent: Friday, 14 August, 2015 16:25:34
Subject: Re: shapes-ISSUE-80 (Scheme URIs): Constraint to limit IRIs against   scheme/namespace, possibly with dereferencing [SHACL Spec]

We should discuss what is the right place for the "prevalidation" or "assembling" information. This matter is also being discussed by the DCMI AP group [1]. If SHACL core will not address assembling the input graph, the right place to declare such things would be "machine readable" application profile. In such profile you could describe what shapes and concept schemes should be used to validate certain dataset(s).

In my opinion machine readable profiles could be constructed using SHACL, SKOS, DCMI Terms and VOID vocabularies ... and you could do SHACL schema to validate the application profiles - then these profiles could be used to assemble the datasets for the validation process. 

.. or we could just add everything to SHACL.

[1] http://wiki.dublincore.org/index.php/RDF_Application_Profiles/blendingDoc

- Miika

----- Original Message -----
From: "Jerven Tjalling Bolleman" <Jerven.Bolleman@isb-sib.ch>
To: public-data-shapes-wg@w3.org
Sent: Friday, 14 August, 2015 10:04:19
Subject: Re: shapes-ISSUE-80 (Scheme URIs): Constraint to limit IRIs against  scheme/namespace, possibly with dereferencing [SHACL Spec]

> As a minimum, I believe we should add a keyword such as sh:valueScheme
> (suggested by Miika Alonen).  For example
> 
> sh:property [
> sh:predicate org:memberOf ;
> sh:valueClass skos:Concept ;
> sh:valueScheme <http://id.loc.gov/authorities/names> .
> ] .
I think this is a good start, but I believe that the sh:valueScheme 
predicate is not enough. There are to many varieties of how this use 
case needs to be supported in practical systems. I think that being 
explicit about some of the options make this better. Also we do want to 
avoid the XSD catalog issues and every SHACL instance hitting the w3c 
for the owl rdf etc...

sh:property [
sh:predicate org:memberOf ;
sh:valueClass skos:Concept ;
sh:valueScheme [
sh:sourceDocument <http://id.loc.gov/authorities/names> ;
sh:sourceDocumentCacheResponseFor 3600 . #in seconds?
#OR something like this
sh:dereference    true ;
sh:onNetworkDereferenceFailure sh:useCachedVersion ;
#also options like sh:fail, sh:warn
#OR/AND something like this
sh:cachedInGraph <http://id.loc.gov/authorities/names> .
]
]
A side benefit here is that the property must be present in the source 
document. But the IRI of the source document must not be a prefix of all
resources discussed in the document.

Regards,
Jerven
-- 
Jerven Tjalling Bolleman
SIB | Swiss Institute of Bioinformatics
CMU - 1, rue Michel Servet - 1211 Geneva 4
t: +41 22 379 58 85 - f: +41 22 379 58 58
Jerven.Bolleman@isb-sib.ch - http://www.isb-sib.ch

Received on Monday, 17 August 2015 07:31:43 UTC