- From: Phil Archer <phila@w3.org>
- Date: Wed, 12 Aug 2015 12:17:21 +0100
- To: Martynas Jusevičius <martynas@graphity.org>
- Cc: Miika Alonen <miika.alonen@csc.fi>, kcoyle <kcoyle@kcoyle.net>, Simon Cox <Simon.Cox@csiro.au>, Irene Polikoff <irene@topquadrant.com>, Arnaud Le Hors <lehors@us.ibm.com>, Holger Knublauch <holger@topquadrant.com>, public-data-shapes-wg@w3.org, public-rdf-shapes@w3.org
On 12/08/2015 12:07, Martynas Jusevičius wrote: > I think syntactical constraints on URIs violate the principle of URI > opaqueness: http://www.w3.org/TR/webarch/#uri-opacity I don't question that URI opacity is important - but this is a practical step saying "in this context, I know I need URIs here to match this pattern." And, personally, I've been violating that particular principle - knowingly, carefully, respectfully - for a while now http://www.w3.org/TR/powder-grouping/ :-) > > Martynas > > On Wed, Aug 12, 2015 at 11:09 AM, Phil Archer <phila@w3.org> wrote: >> It might be worth noting that - although failures will happen for any number >> of reasons - generally speaking if there is a dependency on an external >> source, those sources are likely to be reference/authority data (things like >> LOC subject headings, the INSPIRE registry, UK Government time periods >> etc.). They are going to be stable, predictable and well known to the person >> writing the constraint. >> >> So for me a design that requires the constraint writer to have specific >> knowledge of what to expect when a specific resource is dereferenced (at any >> stage in the validation process) is OK. >> >> http://id.loc.gov/authorities/subjects/sh85113459, for example, includes the >> skos:inScheme property and is likely to continue to do so. If that changes - >> and one has to be prepared for that - then it's going to be a rare event >> that can be dealt with at that time. The constraint would be that LOC >> subject heading URIs were used and were genuine and not just a URI that >> happened to match /^http.*sh\d+$/ >> >> Hmmm... >> >> Actually, in this case, the test could be: >> >> 1. the value of a dcterms:subject property matched >> /http:\/\/id\.loc\.gov\/authorities\/subjects\/\d+$/ >> >> AND >> >> 2. an HTTP HEAD request returns a 200 response >> >> >> Phil. >> >> >> >> On 12/08/2015 09:33, Miika Alonen wrote: >>> >>> 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 >>> >> >> -- >> >> >> Phil Archer >> W3C Data Activity Lead >> http://www.w3.org/2013/data/ >> >> http://philarcher.org >> +44 (0)7887 767755 >> @philarcher1 > > -- Phil Archer W3C Data Activity Lead http://www.w3.org/2013/data/ http://philarcher.org +44 (0)7887 767755 @philarcher1
Received on Wednesday, 12 August 2015 11:17:31 UTC