Re: SKOS, controlled vocab, and open world assumption

* Dave Reynolds <dave.e.reynolds@gmail.com> [2013-04-06 15:11+0100]
> Hi Jeremy,
> 
> The question of controlled terms is more to do with operational and
> policy issues than modelling issues.
> 
> You can use SKOS to convey a vocabulary that is carefully managed by
> an authority, where there is a defined process for change, where you
> can at any time check the definitive status and history of terms.
> Or you can use it to convey something that someone once wrote on the
> back of an envelope (using strings that look a bit like URIs) and
> that they have since rewritten without telling you.
> 
> One conventional approach to controlled vocabularies is the notion
> of a registry, which in turn contains a set of controlled lists
> often called registers.
> 
> A registry should do two things for you:
> 
> Control and governance:   technical and policy infrastructure to
> control how changes are made (who can make, who can approve them and
> when).
> 
> Validation and discovery:   technical infrastructure to enable you
> to discover the status of any set of terms, whether they are in a
> given controlled set (register) or not, whether they are stable or
> experimental, who approved them and when, whether they were in the
> controlled set at a specific point in time, notify you of changes of
> state or status. Note that this status is an attribute of the
> register (the disposition of its authority towards the term) not of
> the term itself.

Your point about the "the disposition of its authority towards the
term" makes sense to me, but I'm unclear on how folks validate with
SKOS. For a specific example how would one validate the
skos:Collection of Jeremy's icecream flavors?
  <http://example.org/~jjc> {
     <#IceCreamFlavors> a skos:Collection ; skos:member <#Raspberry> .
  }
vs. an OWL enumeration of the same set:
  <http://example.org/~jjc> {
    <#IceCreamFlavors> owl:oneOf ( <#Raspberry> ) .
  }

Is there a way to say that something should be a member of a
skos:Collection, e.g. {
  <#AvailableFlavors> x:usesList <#IceCreamFlavors>
} ? Is it generally up to someone to write a custom SPARQL Query a la
SELECT * {
   { <#AvailableFlavors> <#usesList> <#IceCreamFlavors> ; <#item> ?f }
   MINUS { <#IceCreamFlavors> skos:member ?f }
}

I'm not saying "use OWL" because that path leaves no opportunity for
e.g. Amanda (implementer1) to expand Jeremy's set of flavors. An act
of civil disobedience like:
  <http://example.org/~amanda> {
    <#flavor> rdfs:range jjc:IceCreamFlavors .
    <#Menu> <#flavor> jjc:Raspberry, <#Chocolate> .
  }
leads to the conclusion that jjc:Raspberry owl:sameAs <#Chocolate>.
We can use owl:differentFrom or UNA to conclude that Amanda is
breaking the rules, but again, that's not necessarily the goal.  What
we'd like for "validation" is for JJC to label his notion of ice cream
flavors and someone else to extend it in a way that a 3rd party can
can accept amanda:Chocolate but reject jjc:Choco999late. Any candidates
or starting points?


> There's been quite a bit of work in the UK Gov linked data world on
> what registries mean in a linked data context and how they should
> work [1].
> 
> In that design (and indeed implementation) when you dereference a
> Register it returns a collection of terms as linked data. You can
> configure a register so that the collection looks like a
> skos:Collection, a skos:ConceptScheme, an owl:Ontology, a
> ldp:Container, a ref:URIset etc. However, underneath that simplified
> view you can also request the metadata which gives you access to
> status, maintainer, and history information. The design then
> provides the modelling and APIs to enable controlled management of
> sets of terms.
> 
> Dave
> 
> [1] https://github.com/der/ukl-registry-poc/wiki
> 
> 
> On 05/04/13 21:19, Jeremy J Carroll wrote:
> >
> >It is an explicit goal of SKOS to help with controlled vocabularies.
> >
> >
> >These have a strange behavior with respect to open world assumption.
> >
> >If I define "Jeremy's Ice Cream Vocabulary" and decide that it only has one item "Raspberry" and Amanda  decides to use it in her application and Claudia is an end user of the App.
> >
> >We may expect that:
> >- in the short term, Claudia, Amanda and Jeremy all have to put up with a very limited choice of gelato.
> >
> >When Claudia gets fed up with this, she may make a request to add Chocolate to the list, to Amanda, who may do so, but this doesn't change Jeremy's list; in fact, I may notice that Amanda has done this, and then decide to make the change myself; which in practice can lead to a failure mode in which Claudia is given a choice between Raspberry, Chocolate and Chocolate.
> >
> >So …. to abstract:
> >Controlled vocabularies, by definition, have an authority who decide what's in and what's not in
> >The user (typically the application designer) may well have local modifications, but rather than the open-world 'say anything about anything' they make a rather more restricted statement about their own world (we will use this additional term in this vocabulary)
> >
> >And vocabularies then have a change control problem ….
> >
> >
> >Any thoughts? How are we meant to use SKOS to address these sorts of issues?
> >
> >
> >Jeremy J Carroll
> >Principal Architect
> >Syapse, Inc.
> >
> >
> >
> >
> 
> 

-- 
-ericP

Received on Saturday, 6 April 2013 17:22:20 UTC