Re: SKOS concept scheme URIs as values for constraints

Fair point, in this case both http://id.loc.gov/authorities/subjects/sh85113459 and http://id.loc.gov/authorities/subjects/notreallyasubject returns 303 and you have to follow location redirect to get the 200 or 404. Still, relying only on uris would rule out schemes made from concepts in different namespaces (or you would have to use a list) or cases where you need to be sure that referenced resource is actually right type or has all of the required properties. But otherwise, relying on 200 response could also be default procedure with "ResolvablePropertyConstraint" if there is no sh:valueShape defined. 

- Miika

----- Original Message -----
From: "Phil Archer" <phila@w3.org>
To: "Miika Alonen" <miika.alonen@csc.fi>, "kcoyle" <kcoyle@kcoyle.net>
Cc: "Simon Cox" <Simon.Cox@csiro.au>, 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: Wednesday, 12 August, 2015 12:09:26
Subject: Re: SKOS concept scheme URIs as values for constraints

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

Received on Wednesday, 12 August 2015 11:06:14 UTC