W3C home > Mailing lists > Public > public-rdf-shapes@w3.org > August 2015

Re: SKOS concept scheme URIs as values for constraints

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
Message-ID: <55CB2B41.4080407@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:32 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:02:42 UTC