Re: SKOS concept scheme URIs as values for constraints

Thanks for the reference, its important one!

I hope resolution would become part of the property constraints where you could also describe the severity of the possible resolution failures. It can be seen as prevalidation step, but nevertheless it should be considered as part of the core spec.

- Miika

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

On 8/11/15 7:15 AM, Miika Alonen wrote:
> One general solution would be to support some mechanism for resolving resources. I dont know if there has already been discussions about dereferencing resources?


Miika,

This came up around User Story 40 [1], which was discussed by the group 
but which did not result in a specific requirement. The story, provided 
by Arthur Ryman (and modified by me), would result in a requirement to 
be able to designate specific objects that would need to be resolved 
before validation could be applied. (Arthur, if I've got that wrong, pls 
correct.) How resolution would be effected was not part of the story.

Admittedly, validation requiring resolution will be less precise/more 
error prone than validation where all data is under ones control. But it 
is this less precise world where much academic and cultural heritage 
data management takes place. This not only means that we need to resolve 
to outside resources, but we need to tolerate some level of failure 
without breaking. To me, this is very much in the spirit of RDF.

kc
[1] 
http://www.w3.org/2014/data-shapes/wiki/User_Stories#S40_Describing_Inline_Content_versus_References

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

Received on Wednesday, 12 August 2015 08:35:12 UTC