|
Hi Tara,
in the text my comments.
Yours,
monica
Il 02/08/2012 22:36, Tara Athan ha scritto:
Thanks,
Monica. That was enough information for me to resolve that part of
the example.
Now I have a new question. In the complaint example, there is no
explicit mention of time in the rules themselves, yet the temporal
characteristics of the norm (period of efficacy etc) should have
some connection to the time period where it is being asserted that
the axioms hold.
*** the temporal parameters in the norms are classified into two
types:
- internal temporal parameters when the norms talk about events,
intervals, time. Some time the norms define also the external
temporal paramneters of the other textual provisions. In this case
we have
- external temporal parameters established by external rules not
written in the text or in the norm but decided by other high level
norms (gunternorm Kelsen, constitutional law, legislative process
regulation, etc.)
For this reason we need to have <ruleInfo> where to state the
external temporal information as axioms.
In this example, there are variables, such as
<Var>X</Var> corresponding to events, which will
inherently have a temporal duration.
Can we assume that the implementation will figure out how to apply
the period of efficacy to the temporal duration of these events?
Something like an implicit restricted quantification, forall
<Var>X</Var> where the duration of
<Var>X</Var> is within the period of efficacy of the
norm,
it holds defeasibly that ...
*** Several comments.
A. We need to distinguish internal events and external events.
The internal event that you mentioned are "legally valid" only
respect the external temporal parameter (inforce and efficacy).
So usually we have a set of rules valid in t1, a set of rules valid
in t2, etc. for t3, t4.
Each set of rule is connected to the respective textual provision
inforce in t1, t2, t3.
r1-v1-effectiveIn-t1 (where t1 is an interval)
r1-v2-effectiveIn-t2
r1-v3-effectiveIn-t3
r1-v1-isConnectedTo-textsec23-v1
r1-v2-isConnectedTo-textsec23-v2
r1-v3-isConnectedTo-textsec23-v3
A. Take in consideration that the t1, t2, t3 can change over time
and the rule could not change (e.g. annulment by a constitutional
court)
So we can have:
r1-v1-effectiveIn-t1 (where t1 is an interval)
r1-v2-effectiveIn-t2
r1-v3-effectiveIn-t3
r1-v2-effectiveIn-t5 where t5 says: inforce in t4 (when happened the
annulment) and effective in t1.1 in retroactive way
<ruleInfo> block says when the rules are legally valid respect
inforce and efficacy temporal external parameters.
C. We usually filter the rules needed for the reasoner on the base
of the fact happened (e.g. crime, tort, fact). The Fact is happened
in tx so we filter the rules valid in the tx.
D. It is not all the story: we have different set of temporal
external parameters respect body, head, atom and rule.
rule((head(t2), body(atom1(t1), atom2(t2))) t3)
Example: emergency regulation, earthquake, flood, etc.
Italian case: Act 2012(effective 2012) says that the people affected
by earthquake in 2010 Abruzzo with particular conditions effective
in 2012, will not pay tax in the future financial year 2013.
So the Rule1(head(2013); body(atom1(2010), atom2(2012))) 2012)
Note that Rule1 is effective since the 2012 even if the head will be
effective in 2013.
In this case the judge could be decide, on the base of the effectiveness
of the ACT, to suspend the trial (ex. tax-evasion trial) for
waiting for the 2013 in order to see if the company will pay the tax
after the derogation period.
This is the reason why we prefer to use metadata/axioms for the
static external temporal parameters rather than deliberation rules
that we will reserve for the Internal temporal parameters and for
the MetaRules.
E. Metarules are rules about rules. One of these metarules are
usullay modification of the External temporal Paramters.
E.g. change "2004" in "2012" where 2004 is the year of
ending/starting the efficacy.
F. We have static events and dynamic event.
Static classical events in legal document are: date of assent, date
of publication, date of the first enter into force of the whole ACT
(in some legal tradition is fixed by constitution)
Dynamic events in legal document are: enter into force of the
partitions, enter in efficacy of the partitions, application of a
partition
Personally I am open to see possible different solutions that you
can propose.
Or does the LegalRuleML document need to supply any hints to the
implementation about how temporal constraints are to be applied?
Tara
On 8/1/2012 10:18 AM, monica.palmirani wrote:
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=""
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
====================================
|