Re: questions regarding AN complaint example

[monica.palmirani <monica.palmirani@unibo.it>]

Hi Tara,

please find the comment in the text.
If you need more please let me know, we can fix a skype session.

Cheers,
monica
Il 30/07/2012 22:42, Tara Athan ha scritto:
> Monica - I have several questions
>
> 1.  I am confused about the management of "local" ontologies in Akoma 
> Ntoso and how that affects references to these ontologies from 
> LegalRuleML.
>
> For example, the complaint example contains
>
>         <TLCConcept id="complaint" href="/ontology/concepts/complaint"
>           showAs="Complaint"/>
>
> This concepts seems to take its place in a very general ontology, that 
> could be referenced by any number of legal texts. However, the 
> particular concept of "Complaint" as used in this code is much more 
> specific, being restricted only to complaints in the 
> telecommunications industry.
>
> How is this reconciled?
>
> Further, there is a different definition of complaint in the two 
> examples, so it seems to me there should be different complaint 
> concepts. (complaint-v1, complaint-v2)
*** it is supposed to have an ontology that is able to manage the 
evolution of the classes over time.
So in Akoma Ntoso the purpose, especially for the legal concepts, is to 
favor the semantic searching through a light ontology (e.g. give me all 
the Akoma Ntoso documents that include the "compliant" legal concept).
For this purpose we have pointed to a general abstract class "complaint" 
that in case is split in different sub-classes (reduction or extension) 
depending from the time "compliant-v1", "compliant-v2", etc.
I remind you that /ontology/concepts/complaint/ is a logic URI reference 
not a physical URL to the resource. In case there is a "resolver" that 
is able to detect the proper sub-class (expression of the class) on the 
base of the proper time of the expression of the Akoma Ntoso document.

Inside of the rules, the use of the class ontology is different. We need 
to be more precise.  If you would like to point out to the precise 
compliant version in t1, you should have 
/ontology/concepts/complaint/compliant-v1
But again in Akoma Ntoso vision the call could be also dynamic 
/ontology/concepts/complaint:t1 in order to not know the internal 
evolution of the ontology during the document markup.

> 2. Regarding the management of identifiers for versions.
> The example contains
>
> <FRBRExpression>
>           <FRBRthis 
> value="/au/2007-09-10/C628/main/eng@2012-09-01/main"/>
>           <FRBRuri value="/au/2007-09-10/C628/eng@2012-09-01"/>
>           <FRBRalias value="/au/2007-09-10/C628/eng@"/>
>
> I'm not clear on whether this alias should be used for the identifiers 
> from the first version, since at the time they were created there was 
> no "/au/2007-09-10/C628/main/eng@2012-09-01/main"
> Or is this alias just an informative annotation, so the identifiers 
> for the first version should be, e.g.
> "/au/2007-09-10/C628/main/eng@2012-09-01/main#sec2.2-list1-itm24-v1"
yes the alias is just an informative annotation or an abbreviation 
useful for the resolver
> In the latter case, it seems like the markup of the first version is 
> essentially replaced by the multi-version markup when there is a new 
> version released. In this case, it seems there is a risk of "dead 
> links", if there were other documents that referred to the version 1 
> of this document using the old identifiers. So there would need to be 
> a mapping from the old identifiers to the new ones. I am guessing this 
> is where the alias comes in. However is there an assumption of a 
> rewrite convention:
>
> "/au/2007-09-10/C628/eng@#sec2.2-list1-itm24" ==> 
> "/au/2007-09-10/C628/main/eng@2012-09-01/main#sec2.2-list1-itm24-v1"
>
> where both the prefix (replace eng@ with main/eng@2012-09-01/main) and 
> the suffix are changed (add -v1)?
** the multiversioning document is a document that includes all the 
versions in the same time.

So yes the first version is replaced by the second one.
In Akoma Ntoso is not the only way to manage the versioning.
Another technique is to make two manifestation for two versions.
Sincerely speaking I don't like the multiverisioning for several legal 
reasons (e.g. legal interpretations and annotation, digital signatures, 
etc.) but it is a possible technique used by different pilot cases (e.g. 
California State, some Italian Regions, etc.).

The normative reference to a the legal document is usually a DYNAMIC 
logic link so the reference is made using the "work" annotation of the 
reference. Not only in the Akoma Ntoso, but also in URN:LEX, CELEX, etc. 
there is this attitude in the legal domain because the "section 2.2 item 
24" is a dynamic pointer over time.
So it is used this annotation for referring to a fragment of a resource 
/au/2007-09-10/C628/#sec2.2-list1-itm24
where
"/au/2007-09-10/C628/" is the work and
"#sec2.2-list1-itm24" is the fragment.

The resolver is able to calculate the correct version of the document to 
point to on the base of the date of navigation of the law. If I navigate 
today to the law, I point to the version of today, after one year I need 
to navigate to the version valid in the proper time without to modify 
the XML files. If I navigate the version 3 (2009) all the links have to 
navigate to the proper version valid in 2009. So usually in legal domain 
we use dynamic link and the resolver converts to the proper URL. 
Temporal issue in legal domain is really complex.

In case you need to fix the navigation to a proper STATIC link without 
to know nothing about the versioning approach of the XML, you can use 
/au/2007-09-10/C628/eng@:t1/#sec2.2-list1-itm24 and this dynamic call 
returns to you the proper fragment 
/au/2007-09-10/C628/eng@2012-09-01/#sec2.2-list1-itm24-v2

> What this boils down to is
> 1. I'm not sure what identifiers to use for the "v1" part of the 
> LegalRuleML; and
>
> 2. I'm not sure if there is a need to add an "alias" statement to the 
> LegalRuleML, or is this taken care of by the Akoma Ntoso?
*** recap
2) for LegalRuleML is not necessary to use alias
1) for my point of view LegalRuleML can manage references to "work" or 
"expression" or "manifestation" (discouraged but possible especially for 
those standards that are not based on FRBR model). In our example you 
can use
work  /au/2007-09-10/C628/#sec2.2-list1-itm24 and to delegate the 
connection with the textual resources to a resolver (I will present in 
the Challenge)
or
expressions (even if it is verbose)
/au/2007-09-10/C628/eng@2012-09-01#sec2.2-list1-itm24-v1
/au/2007-09-10/C628/eng@2012-09-01#sec2.2-list1-itm24-v2
or
dynamic URI reference (I will present in the Challenge)
/au/2007-09-10/C628/eng@:t1/#sec2.2-list1-itm24

> .


--
===================================
Associate professor of Legal Informatics
School of Law
Alma Mater Studiorum Università di Bologna
C.I.R.S.F.I.D. http://www.cirsfid.unibo.it/
Palazzo Dal Monte Gaudenzi - Via Galliera, 3
I - 40121 BOLOGNA (ITALY)
Tel +39 051 277217
Fax +39 051 260782
E-mail  monica.palmirani@unibo.it
====================================