Re: Proposed resolution for org:identifier

Hi Phil,

On 11/10/12 13:40, Phil Archer wrote:
> Dave,
>
> Sorry for being slow to respond on this.
>
> +1 to your 'do nothing to org' proposal. Any change to Org would be an
> unwelcome mistake.

Thanks.

> That sais... 'do nothing to org' does not, as you say, imply doing
> nothing at all. When I next update Legal Entity, I'll include this
> SPARQL CONSTRUCT query.
>
> I was talking about this at a meeting yesterday in Brussels that I want
> to report on in today's call. A question I was asked was "can this
> entailment be machine encoded and processed?" Well, it can be encoded as
> the SPARQL query and it can be written as an N3 rule (and I dare say
> Sandro could show me how to do it in RIF too). Is there a useful way to
> encode it actually in the legal entity schema?

I think the short answer is "no" depending on how strictly you interpret 
"useful".

OWL 2 includes the notion of property chains [1] so that would be ideal 
but it is restricted to ObjectProperties and so does not fit.

SWRL allows rules to be embedded in OWL ontologies but is not an 
official standard and is not supported by the tool chains used by most 
of the government clients I work with.

RIF does have a notion of linking an RDF document, including an OWL 
ontology, to a RIF rule set via rif:usedWithProfile [2]. This is a 
recognized SPARQL 1.1 entailment regime [3].  However, while at least 
RIF is a standard and covers this case, again it is not widely supported 
in tool chains (especially not this feature of it).

Dave

[1] http://www.w3.org/TR/2009/REC-owl2-syntax-20091027/#Object_Subproperties

[2] http://www.w3.org/TR/rif-in-rdf/#Semantics_of_RIF_in_RDF

[3] http://www.w3.org/TR/sparql11-entailment/#RIFUsedWithProfile

> On 04/10/2012 22:19, Dave Reynolds wrote:
>> 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, 11 October 2012 13:11:19 UTC