Re: SKOS concept scheme URIs as values for constraints

Can you add to the issue that discussion about the role of skos:inScheme is required. Some schemes are constructed from multiple ontologies, and for many reasons uris might not match. I dont want to be the one that says that this is wrong, for example:

<> a skos:Concept ;
    skos:inScheme <> ;
    skos:notation "UnderDevelopment" ;
    skos:prefLabel "Under development"@en . would raise error if scheme validation relies only to STRSTARTS .. and mixed SKOS vocabularies would be even worse to match.


- Miika

----- Original Message -----
From: "Holger Knublauch" <>
To: "Phil Archer" <>, "Miika Alonen" <>, "kcoyle" <>
Cc: "Simon Cox" <>,,,,,
Sent: Friday, 14 August, 2015 01:34:07
Subject: Re: SKOS concept scheme URIs as values for constraints

I have raised this topic as a formal ISSUE for the WG to consider. My 
suggestion is to continue the discussion there on the -wg mailing list 
only, keeping ISSUE-80 in the subject line.


On 8/13/2015 20:38, Phil Archer wrote:
> On 13/08/2015 06:44, Holger Knublauch wrote:
>> On 8/12/2015 19:09, Phil Archer wrote:
>>> 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
>> Could this be extended so that the HTTP look-up only needs to happen if
>> there is no local copy of that namespace, e.g. as a named graph?
> I'd say that was a user choice. In some cases, a local copy would be 
> preferable for the reasons you say, in others - "have you used the 
> current concepts defined by authority X?" - can only be tested with a 
> live look up. The user would then make the choice between the slow 
> live look up and the quick local check.
>  I can
>> imagine that many enterprise setups would not want to rely on live data
>> from the public internet to look up reference data.  If only for
>> performance reasons, it should probably be an option to use local copies
>> that are updated in regular intervals. Then, if no such named graph
>> exists, do the HTTP request as a last measure?
> The live version isn't a fall back: it's the ground truth. So I'm 
> hoping for a  check that the data I have is referring to the external 
> resources as defined by an external authority. A stage that checked 
> that a locally held copy was still up to date could precede the 
> regular validation - HTTP caching would no doubt be useful there. This 
> seems in line with what Miika is suggesting?
> Phil.
>> Holger

Received on Friday, 14 August 2015 19:10:50 UTC