Re: SKOS concept scheme URIs as values for constraints

We actually do the same in our Graphity processor, to match request
URIs against resource classes:
https://github.com/Graphity/graphity-processor/wiki/How-Graphity-Processor-works

But for constraints, I think relying on explicit RDF relationships is
a better solution.

On Wed, Aug 12, 2015 at 1:17 PM, Phil Archer <phila@w3.org> wrote:
>
>
> 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:38:23 UTC