Proposed resolution for org:identifier

On the last call we agreed to open a (late!) issue [1] for ORG on 
org:identifier and compatibility with the forthcoming ISA vocabs.

# Background:

ADMS introduces classes to represent Identifiers in formal registration 
schemes. Thus individual identifiers are resources (so they can be 
annotated with things like validity dates). These resources in turn 
require a skos:notation value. The Legal Entity vocabulary assumes ADMS 
and introduces legal:legalIdentifier to link an organzation to an 
adms:Identifier.

ORG specifies a property org:identifier which is intended to directly 
point to a literal value in the style of skos:notation.

This could be regarded as an inconsistency between two "products" of the 
same working group.

On the call we discussed several options to resolve this.

# Proposal:

Do nothing to org.

In Legal Entity state the relationship between legal:legalIdentifier and 
org:identifier via an entailment rule viz:

     CONSTRUCT {
         ?org org:identifier ?id .
     } WHERE {
         ?org legal:legalIdentifer [skos:notation ?id] .
     }

Since skos:notation is mandatory on adms:Identifier (the range of 
legal:legalIdentifier) then there will always be a corresponding 
org:identifier value. The converse is not true.

# Discussion:

I'm aware of a number of groups (private as well as public sector) who 
use skos:notation style to represent organization identifiers including 
ones not published centrally by governments. Those groups are probably 
not going to maintain their own URIs but do have stable codes[2]. So 
they can't use legal:legalIdentifier even though they are discussing 
legal entities.

So I don't think it is possible to simply deprecate org:identifier.

The option of fudging org:identifier to allow it to point to an 
adms:Identifier *or* a skos:notation-style-literal is tempting but puts 
the burden on the consumer and potentially breaks existing usage. So 
that can't be done without an ontology versioning exercise which is out 
of scope at this stage.

I could introduce a new org:identifierResource alongside org:identifier, 
and explain the relationships and reasons for the overlap in similar 
style to the current discussions on membership.
This would be an acceptable fall-back if the "do nothing" option doesn't 
get concensus.

However, I'm loathe to put even more optionality in the ontology. After 
all the above discussion means that org:identifier is both necessary and 
sufficient.

The proposal gives us a route to enable Legal Entity to describe the 
relationship to ORG. In terms of practical usage I don't see any issue - 
if you have ORG data plus registration identifiers expressed in Legal 
then finding the corresponding adms:Identifier is the trivial SPARQL path:
       org:identifier / ^ skos:notation

Dave

[1] I don't think the issue has been formally opened yet so I can't 
refer to the number. I didn't want to open it myself in case that's 
already in progress.

[2] Yes I know you could always use a bNode but enough tool chains cough 
at bNodes that relying on that as a universal solution is not ideal.

Received on Thursday, 4 October 2012 21:20:21 UTC