suggestion for represent modification

[Naftali B.]

Dear all,

I'm working now on represent our amendments with the modification pattern of akoma ntoso, 

Do you have any suggestion on how to represent this kind of modifications, when the "old" element is only an hint and not a specific text:

(1)  In subsection (a), the date specified therein will be replaced by "March 31, 2016" 

  

Best regards,

Naftali

[monica.palmirani]

Dear Naftali,

In principle the parts of the official text that are not clearly identifiable are not marked-up for not creating problem of legal interpretation.

However if you want to capture the fragment of the text where the old text is expressed (but in incomplete manner using @incomplete="true"), you can use <span> or <concept> as you like, with @refersTo="#oldFragment".

Additionally if the date is important for the "enter into force" or the "enter into operation", or for the "temporal model" of the legal system, we add also a particular metadata in the <activeModifications><forceMod>.

Here after my proposal of AKN-XML:

<<(1)  In subsection (a), the date specified therein will be replaced by "March 31, 2016" >>

here the fragment proposed

<activeModifications>

                    <textualMod type="substitution" period="#temporalGroup_2" incomplete="true">
                        <source href="#sec_1__mod_1"/>
                        <destination href="#/xxx/sec_xxx__subsec_a"/>
                        <old eId="#concept_1"/>
                    <forceMod type="entryIntoForce" period="#temporalGroup_2">
                        <source href="#sec_1__mod_1"/>
                        <destination href="#/xxx/sec_xxx__subsec_a"/>
                        <force period="#temporalGroup_2"/>
                    </forceMod>

</activeModifications>

            <section>
                <num>(1)</num>
                <content>
                    <p> <mod eId="sec_1__mod_1">In <ref href="">subsection (a)</ref>, the <span refersTo="#oldFragment"
                            eId="date_1">date</span> specified therein will be replaced by
                        "<quotedText eId="sec_1__mod_1_qtd_1"><date date="2016-03-31" refersTo="#efficacyDate">March 31, 2016</date></quotedText>" </mod></p>
                </content>
            </section>

Best regards,
Monica

--
You received this message because you are subscribed to the Google Groups "akomantoso-xml" group.
To unsubscribe from this group and stop receiving emails from it, send an email to akomantoso-xm...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/akomantoso-xml/9c5541dc-5a21-4a94-8f87-a346e01edca0n%40googlegroups.com.

-- 
===========================================
Full professor of Legal Informatics 
School of Law 
Coordinator of MSCA-ITN EJD LAST-JD-RIoE
Scientific Director of Legal Blockchain Lab
Director of the Summer School LEX
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.p...@unibo.it

[נפתלי ביליג‎]

Thank you very much,

I haven't gotten into the "entry in force" yet, but thanks for the example, this sure will help me in the future.

About the textualMod, how it should look like after manually editing?

the specific date should be entered inside the old element directly, like this example:

<old>

    <il:text>April 1, 2015</il:text>

</old>

Best regards,

Naftali

To view this discussion on the web visit https://groups.google.com/d/msgid/akomantoso-xml/ec223309-eb0b-10ae-312b-0e29c6a79919%40unibo.it.

--

נפתלי ביליג  - מתכנת מחשבים

052.740.1735

[monica.palmirani]

Dear Naftali,

it is not a good idea to put in the current modificatory document the old text supposed to be in a given moment and not clearly mentioned.

The date (April 1, 2015) could be changed in the middle by extra-events (e.g., constitutional court, other retroactive modifications, etc.).

The "Theory of Law" leads the AKN design and we need to maintain the veracity of the metadata assertions in a legal document. For this reason we don't put information about the destination of the document, if not explicitly included in the official text, because we don't simply know if the destination (especially the text) will change over time.

Best,
Monica

To view this discussion on the web visit https://groups.google.com/d/msgid/akomantoso-xml/CAHiUuQjoa6G4hnAt%2BPNUfP1apHSqFVrbm2K-SY-Umj%3D1ePnOMw%40mail.gmail.com.

[נפתלי ביליג‎]

Dear Monica,

Thanks for enlightening me the problematic with that modification.

I think that our team need to talk more about how much officially we want those modification documents to be.

(maybe we will use it internally only for reducing the work on creating the expressions therefore we can be more flexible)

Best regards,

Naftali 

You received this message because you are subscribed to a topic in the Google Groups "akomantoso-xml" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/akomantoso-xml/nXY3D2_leEA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to akomantoso-xm...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/akomantoso-xml/dd4d5827-ed58-6771-8a3d-2781149c7977%40unibo.it.

[monica.palmirani]

Dear Naftali,

it is not a problem of officiality, it is a problem that if you store this data in a given expression you risk to use an information that could be wrong after three steps of versioning.

It is not correct under the technical point of view and the temporal model of the versioning.

It is so true that nobody do so!

Cheers,

Monica

To view this discussion on the web visit https://groups.google.com/d/msgid/akomantoso-xml/CAHiUuQjXOioNRjLZZJPg9_9YiL%3DxfACZtTWH%2BN2_rfqW0yBCDQ%40mail.gmail.com.