Re: [SKOS] ISSUE-31 BasicLexicalLabelSemantics proposed resolution

Alistair

> [1] <http://www.w3.org/2006/07/SWD/wiki/SKOS/Semantics/Labelling?action=recall&rev=5>
>
> This proposal deals with the intuitive semantics of "preferred", "alternative" and "hidden" at the syntactic level, which avoids complicated semantics conditions and allows for error-tolerant strategies to be defined.
>
> This idea of handling some conditions at a syntactic level is new to me, and I have very limited experience of writing normative specifications of application behaviour, so I'd very much welcome comments and thoughts on this proposal.
>   
We've thought about that kind of issue in Mondeca a lot. Our software is 
so-called "ontology-driven"; which means that interfaces are strictly 
controlled by ontologies, but the data base less constrained. 
IOWconstraints expressed in the ontology, and singularly cardinality 
constraints, can be violated when merging or updating data. Say for 
example your data have already one value of prefLabel in English for a 
skos:Concept, or the birthdate of a foaf:Person, and an update batch 
brings a different one. There are several ways to deal with this 
cardinality exception :
1. ignore the new value
2. replace the old value by the new one
3. store the two values and take a catch exception measure, e.g. trigger 
an alert, put the resource in "inconsistent mode" (semantic quarantine), 
take it out of any publication workflow, etc.

1. and 2. can make sense in well-controlled workflows, they can be 
options switched on/off on demand. We have mainly explored 3. which 
offers the best flexibility.
In a full RDF environment, I figure that the "syntactic conditions" can 
be actually implemented as such "catching exceptions" in the context of 
data merging.
Maybe they could be formalized with SPARQL queries, either to SELECT the 
exception triples, or to CONSTRUCT a graph rid of exceptions.

Some first cuts (thinking aloud)

The first syntactic condition contains a negative clause and a MAY, 
which makes two difficulties to handle. A more positive expression could 
be :

"An application MUST process any triple in an RDF graph where the 
predicate is either skos:prefLabel, skos:altLabel or skos:hiddenLabel 
and the object is a plain literal."

The triples that MUST be processed can be selected by a SPARQL query 
(seems to me - should check)

The second syntactic condition seems tricky to implement. The "ignore 
but one" instruction is not deterministic, unless a sorting rule is 
applied, and then an instruction like "keep the first in list". The only 
sure way is to "quarantine" the concept until a human takes care.

The third and fourth conditions seem quite obvious to formalize with 
SPARQL queries also. I will be back with proposals for such queries ASAP.

Bernard
> Cheers,
>
> Alistair.
>
> [ISSUE-31] <http://www.w3.org/2006/07/SWD/track/issues/31>
>
> --
> Alistair Miles
> Research Associate
> Science and Technology Facilities Council
> Rutherford Appleton Laboratory
> Harwell Science and Innovation Campus
> Didcot
> Oxfordshire OX11 0QX
> United Kingdom
> Web: http://purl.org/net/aliman
> Email: a.j.miles@rl.ac.uk
> Tel: +44 (0)1235 445440 
>
>
>   

-- 

*Bernard Vatant
*Knowledge Engineering
----------------------------------------------------
*Mondeca**
*3, cité Nollez 75018 Paris France
Web:    www.mondeca.com <http://www.mondeca.com>
----------------------------------------------------
Tel:       +33 (0) 871 488 459
Mail:     bernard.vatant@mondeca.com <mailto:bernard.vatant@mondeca.com>
Blog:    Leçons de Choses <http://mondeca.wordpress.com/>

Received on Tuesday, 26 June 2007 22:02:17 UTC