Re: SKOS concept scheme URIs as values for constraints

I think syntactical constraints on URIs violate the principle of URI
opaqueness: http://www.w3.org/TR/webarch/#uri-opacity

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

Received on Wednesday, 12 August 2015 11:08:09 UTC