- From: <Simon.Cox@csiro.au>
- Date: Tue, 11 Aug 2015 22:20:36 +0000
- To: <kcoyle@kcoyle.net>, <miika.alonen@csc.fi>
- CC: <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>
Well stated Karen. That has probably captured the general case that I was groping towards. -----Original Message----- From: Karen Coyle [mailto:kcoyle@kcoyle.net] Sent: Wednesday, 12 August 2015 1:57 AM To: Miika Alonen <miika.alonen@csc.fi> Cc: Cox, Simon (L&W, Highett) <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 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 Tuesday, 11 August 2015 22:21:27 UTC