Re: SKOS concept scheme URIs as values for constraints

Hmmm... how about using RFC 6570 URI templates?
 
Preferably where the reference/authority data owner publishes the template that
they use.
 
John

> On August 12, 2015 at 1:37 PM Martynas Jusevičius <martynas@graphity.org>
> wrote:
>
>
> 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
>