Jusletter IT

Term	Explanation
ASCII	American National Standard Code for Information Interchange («pure text»)
Austrian Portal Network	à PV
BKA	Bundeskanzleramt (Federal Chancellery)
CEN	Comité Européen de Normalisation
CHLexML	XML Schema for legislative data at federal, cantonal and municipal level
CPL	Callable Personal Librarian. In essence, a search engine: «The most reliable and scalable text engine available to manage full text, structured data, hypertext, forms-based searching and multimedia applications».
ELI	European Legislation Identifier
EnAct	Name of the legislation system of Tasmania (Australia)
HTTP	HyperText Transfer Protocol
IOP-Gateway	InterOperability gateway, a specific gateway developed in the R4eGov Project for connecting «e-Administration in the large», as required by the Project
JASPI	Jednotný automatizovaný systém právnych informácií (integrated automated legal information system of Slovakia)
KAV	Kompetenzzentrum für Amtliche Veröffentlichungen (Official Publications Centre, OPC) of the Swiss Federal Chancellery
OE	Ontology Explorer, a tool developed in the R4eGov Project. It allows for the automatic generation of the XML schema out of an ontology, e.g. the ontology used for queries.
OeSD	Österreichische Staatsdruckerei (Austrian State Printing House); remaining operations privatised 2000 as a consequence of electronic publishing of legal information in RIS.
OPC	à KAV
PEAK	Permanente Elektronische Authentische Konsolidierung (Permanent Electronic Authentic Consolidation)
Pilot	In the BKA environment, synonymously used to the Demonstrator (RIS-v3); term used only in some of the original Project texts and work package titles
PKI	Public Key Infrastructure
Project	The R4eGov Project
PV	Portalverbund (Austrian Portal Network). Secure Austrian Interconnect facility for governmental resources allowing e.g. for Single-Sign-On with separation of user management and resource management.
R4eGov	Research for e-Government
RDB	Relational Data Base
RIS	Rechtsinformationssystem (Legal Information System)
RIS Demonstrator	The Demonstrator built in the R4eGov Project. In essence, it was RIS-v3 plus the software needed for a proof-of-concept and a PV interface. Regarding R4eGov the IOP-Gateway software functionality was the important part. Regarding BKA’s RIS environment the SR software functionality was more important.
RIS-v1	ASCII based RIS
RIS-v2	XML based RIS, current production system
RIS-v3	advanced XML based RIS, demonstration system, result of the R4eGov Project
SAML	Security Assertion Markup Language
SOAP	Simple Object Access Protocol
SR	Semantic Repository, a specific database developed in the R4eGov Project. A hierarchical native XML database allowing for «semantic references».
UBAS	Unabhängiger Bundesasylsenat (Independent Federal Asylum Board), predecessor of the Asylum Court.
UN/DESA	United Nations Department of Economic and Social Affairs
XML	eXtensible Markup Language

Project Title: Towards e-Administration in the largeProject Acronym: R4eGov («Research for e-Government»)Start date: 1st March 2006End date: 28th February 2009 http://cordis.europa.eu/projects/index.cfm?fuseaction=
app.details&TXT=r4egov&FRM=1&STP=10&
SIC=&PGA=&CCY=&PCY=&SRC= &LNG=en&REF=79308

 Fig. 1 R4eGov logo

The objective of R4eGov was to develop concepts and technologies for a flexible and secure co-operation of European public administrations in terms of an «E-Administration in the large» approach.

Interoperability, security, heterogeneity, distributed responsibility (still) are key topics on the EU eGovernment research agenda. They must be addressed keeping in mind that eGovernment systems will remain heterogeneous while local administrations remain in charge of their configuration and of the definition of their processes.

Therefore, Project key objectives were:

• To gather and elicit the requirements for e-Administration in the large, on basis of which a concrete interoperation of web service enabled legacy public sector applications was to be achieved using collaborative work flows.
• To provide the tools and methods for an e-Administration in the large from a technical and sociological perspective.
• To provide the required security and privacy for an e-Administration in the large, defining the appropriate methods and tools for control, security and privacy at the collaborative work flow and application layer.

From Austria, two organisations were Project partners: BKA as a large e-Administration organisation, offering RIS as a use case to the Project, and expecting an enhancement of RIS' capabilities from the Project. The second Project partner was METADAT GmbH, offering to the Project its experience as authors of RIS-v1, the first Internet version of the Austrian legal information system, the RIS production system at the time R4eGov started.

Working as a team, the Austrian partners of the R4eGov Project delivered:

• an «InterOperability Gateway (IOP-Gateway)» handling the interoperability requirements of the Project («e-Administrations in the large»), e.g. to automatically and securely exchange data between the work flow systems of administrations, allowing them to use their own (inherently incompatible) legacy and work flow systems and to apply even different security policies.
• a «Semantic Repository (SR)», which is a novel database engine (based on a native XML database) combined with an innovative search engine allowing for a «semantic search».
• an «Ontology Explorer (OE)», a tool which allows for the mapping of the ontology of legal information (queries for information retrieval in particular) to the XML schema (in the sense of the database structure), largely simplifying database design and management.

The work on R4eGov focuses on the following:

• an XML version of RIS (RIS-v2), offering an enhanced user interface. RIS-v2 became the RIS «production system» which still is in use today.
• a prototype of a version of RIS with enhanced capabilities (RIS-v3, fully operational for some time after R4eGov ended). It uses the SR and a specific version of the IOP-Gateway allowing for:
• innovative end-to-end-security for the handling of RIS documents with sensitive information (e.g. personal data)
• Austrian Portal Network access to RIS, allowing for well-defined input to (e.g. for publishing) and output from RIS (e.g. for publishers adding value to RIS contents).
• all the other enhanced capabilities listed in à clause 5 (Achievements) and in à clause 6 (Future potential of current deployment).

This paper is largely based on the R4eGov deliverable «Consolidation of pilot results, summary of lessons learnt, and the preservation of setups and information» [1].

Traditionally the way to publish law was to use paper: the Austrian State Printing House (OeSD) published the Law Gazette.

The transition from a print to an electronic version started in 1972 with a trial project on constitutional law, carried out by BKA in co-operation with IBM Austria. Although this trial ended already in 1973 it became one starting point for BKA with RIS 10 years later.

Another starting point was the index of Austrian federal law. In the mid 80ies the Constitutional Service of BKA started to create this index, to be printed by OeSD. RIS initially was a by-product of the printed version of this index, which has been issued annually since then (à Fig. 2). RIS was a by-product as well for publishing electronic files of their printed counterparts (laws published in the Law Gazette). With time, RIS became a product by itself. This transition period lasted 15 years.

1990 RIS contained all federal laws, published for use within government, based upon an IBM-3270 platform, using the STAIRS software. Later jurisdictions of the three Austrian Main Courts (Constitutional, Administrative and Supreme Court) were added. 1997 the decision was made to move towards a Digital Equipment platform, using the full text retrieval software CPL, creating RIS-v1. This technology was in use up to 2008.

RIS-v1 built upon Internet as an access mechanism, using a web interface. Therefore, RIS was made publically accessible, free of charge. Moving forward from publishing federal law, the first publishing application, up to now 33 more applications are in use.

In 2002 the realisation of the eRecht system, a work flow for the production of federal law gazettes, interconnecting all ministries, Austrian parliament and BKA started. As eRecht used XML as transfer syntax, RIS got its first XML interface and started to develop an XML database for authentic publication of federal law gazettes. This native XML data base (a predecessor of the Semantic Repository used in the Project, and used in the RIS Demonstrator) was able to directly store the documents delivered by eRecht, in their native format.

In 2004, the transition from a print to an electronic version, started in 1972, was completed: the electronic version published in RIS became authentic, obsoleting paper and therefore, the paper based Law Gazette. Austria was one of the first countries worldwide to offer this service.

One of the biggest RIS achievements – compared with other systems for publishing legal information – was the mapping of structural elements of a document to documentalistic units corresponding to a legal point of view on a document, not a printing or layout view on it. These structural elements were called «categories». Contents of the categories can be data or metadata.

One of the theoretical consequences of using categories is to be able to separate content from layout of a document. This capability is especially important for long term archival of documents, to be able to use a file format which is independent from an editor. Unfortunately, up to now this theoretical advantages could not be realised: Austrian government’s editor of choice is Microsoft Word which still (in its version 2010) is not able to work with externally defined style sheets.

Documentalistic categories were already used in the 1972 trial project on constitutional law, transferred to STAIRS, enhanced by Dr. Andreas Manak and Dr. Thomas Herzog in cooperation with Dr. Werner Robert Svoboda. The RIS project including further development of the categories was started under the supervision of Dr. Gerhart Holzinger (current president of the Austrian Constitutional Court), followed by Dr. Clemens Jabloner (current president of the Austrian Administrative Court).

On 6th June 2005, as a contribution to the LOAIT workshop organised within the ICAIL conference in Bologna [2], Harald Hoffmann and Friedrich Lachmayer presented the mapping of categories into the world of legal ontologies. This mapping now partially is used with Ontology Explorer (OE), developed as part of RIS-v3 in the Project.

In the beginning of the Project there was version 1 of the «Rechtsinformationssystem» (RIS-v1), using «structured ASCII text»: Coding and data representation was ASCII, structure was achieved with tags similar to XML, developed prior to the arrival of XML. For the time when RIS-v1 was developed it was well ahead of other systems for storing and publishing legal information, and making it available to the public, by the means of Internet.

At the time the Project started it was quite obvious that an overhaul of RIS was necessary. The following problems had to be resolved:

• The user interface for the retrieval of documents was outdated (e.g. pure ASCII text);
• The documents were coded in a proprietarily structured ASCII format, similar to XML which became a standard later
• The CPL search engine was discontinued
• Security was marginal, differentiating between Internet and Intranet users only;
• Publication of documents was a rather manual process, as was the export of data for value added resellers of legislative information.

In particular, the last bullet point was the reason to join the Project. A solution was sought to connect the RIS internal work flow to independent work flows of other organisations, providing for automated machine-to-machine communications:

• An organisation producing legislative information should be able to upload and publish this information without manual intervention in RIS, meeting all the formal (in particular security) requirements for this process;
• An organisation retrieving legislative information («raw data») from RIS, with the purpose to add value to it (e.g. for re-selling it), should be able to automatically do so.

On one hand R4eGov promised to provide for answers to these problems. On the other hand RIS promised to become a demonstrator for the Project’s results. This was where the idea to make RIS available as The Demonstrator for the Project results (RIS-v3) was born.

The main objective was to resolve the mentioned problems. In detail, resolving these problems meant to go for the following detail objectives:

1. User access had to be brought up to date, keeping what users appreciated in the previous version, and adding the functionality defined by the results of a user survey¹;
2. Migrating all data to XML;
3. Adding security components for the publication of «documents»² and for their retrieval; in particular, use the Austrian Portal Network (PV) mechanisms³ to safely connect the publishing organisation’s work flow with the RIS input work flow;
4. Automating the input process (the publication of «documents») and the output process (retrieval of «documents») by using machine-to-machine communication between the work flow within RIS and the work flows within the connected organisations.

To achieve detail objectives 1 and 2, and partially⁴ objective 3 it was clear from the beginning that actual work on RIS had to start early, working in parallel with the other work packages, preparing for receiving input from them. Therefore, objective 5 was defined:

5. Have version 2 of RIS (RIS-v2) up and running before inputs from the other work packages were due. Today, RIS-v2 is the production system in use, providing for 33 applications.

6. Combine the experience from developing RIS-v2 with the results of the other work packages, resulting in version 3 of RIS (RIS-v3). RIS-v2 contributed e.g. the new user interface and XML as the syntax. The other work packages contributed the «Semantic Repository» (SR) and the «Interoperability Gateway» (IOP), as well as the Ontology Explorer (OE).

7. Make RIS-v3 the desired Demonstrator⁵ for the Project’s results.

For the Demonstrator it was sufficient to implement only one of the 33 RIS applications:

UBAS – Unabhängiger Bundesasylsenat (= Independent Federal Asylum Board): This database contains the judicature of the Independent Federal Asylum Board (selected rulings since 1998).

One idea was to successfully finish the R4eGov Project, migrate the remaining 32 applications to RIS-v3 and to replace RIS-v2 as the production system, keeping its achievements (e.g. XML and the user interface) and possibly keeping its RDB part⁶ to meet the legal requirement for long term storage (PDF-A).

Another idea was, by migrating to RIS-v3, to again put the Austrian legal information system ahead of similar systems in the rest of the world, and possibly to repeat the success in achieving the United Nations' Public Service Award (à Fig. 3).

One of the objectives for BKA to be reached during the Project was the migration to XML (à clause 4.2). This migration contributed to reaching RIS-v2.

There were two reasons which led to the migration to XML. First, there was a general trend to use XML, and BKA decided to follow this trend, moving away from a proprietarily structured ASCII syntax and for using the CPL search engine to a standardised one widely supported in the Internet.

Second, eRecht (the work flow for the production of federal law gazettes) already had decided to use XML. eRecht provided quite some critical mass for XML in Austria as it connected (and still connects) all ministries, the Austrian parliament and BKA, and therefore it made sense to make RIS compatible⁷ with eRecht.

Work flow systems in the other Austrian governmental organisations producing legal documents were out of the scope. Up to now RIS has to accept the formats in which these organisations send documents for publication. However, it would be easy to change this situation, in particular because of the results of the Project, allowing for the automation of transferring sensitive information between the work flows of two organisations.

One of the other decisions at the time of migration to XML (2002 time frame) was to use Microsoft Word as the legal editor of choice throughout government (federal level). As a consequence, a problem arose: How to achieve compatibility between the Microsoft Word file format and XML, using a specific schema? Even starting with Microsoft Word v7 and its «Open Office XML» this issue has not been resolved in a generic form which would allow keeping content and layout separate. Therefore, a software converter was developed which allows the conversion back and forth between both formats. This solution does not come without problems; however, it still is in use. One of the consequences is the requirement of some 70 styles which have to be mapped to corresponding functional elements in XML. One of the big achievements of this time was that these functional elements were not focussed at layout of a text but on «legal categories» (à clause 3.3) – the structural elements seen by the legal community.

A legist (person responsible for the creation and maintenance of laws), of course, from this time on had to use the styles provided by the Word based editor. If the person did not or he/she made an error, the resulting document was rejected during the conversion process to XML. Therefore, it could be guaranteed, that documents could be taken off the work flow and fed back to it repeatedly during the process of law production, and that the documents at the end could be stored to and retrieved from RIS in the correct layout (e.g. of the traditional Law Gazette).

What has been said so far only applies to the process of producing, saving and retrieving Austrian federal law. It does not apply to the production processes of Austrian provinces or other law producing authorities, and it does not apply to the European level.

To accommodate for the latter, work carried out by the European Forum of Official Gazettes has to be taken into account. This body has identified the «Semantic Web of Official Gazettes» as a keystone for future work. The «Semantic Web», «WEB 3.0» or «Web of connectable data», is designed besides for both human and machines but also facilitates machines to understand the meaning of information. It goes further than the actual «Web of documents with hyperlinks» by enabling machine-readable metadata with descriptions about their meaning and relations with other objects, facilitating inter-domain information sharing and encouraging data to be distributed in reusable and interoperable/open formats.

One of the first results of this work is ELI, the European Legislation Identifier [3]. Naming conventions used in RIS (even RIS-v3) will have to be made compatible.

This discussion started with R4eGov and, for BKA, has not come to a conclusion yet, possibly in coincidence with the missing decision to go forward with implementing RIS-v3 (see the end of à clause 4.2). Therefore, for RIS this discussion rather is an action point for the future (à clause 6) than for RIS-v3 (this clause). However, understanding this discussion is required for the time slice discussion of the next clause (à clause 5.3).

In the context of the production of legal documents the terms ex-ante and ex-post mean slightly different things to metadata and data:

Metadata: Ex-ante means that metadata is added to the document simultaneously with data – e.g. an author authentically adds both types of data. Ex-post means that metadata is added to the document later – e.g. a documentalist interprets what an author has meant and adds metadata correspondingly.

Data: Ex-post means that a documentalist assembles a consolidated version of a law, so to say as an afterthought, using the previous version of law plus an amendment, a change order decided by parliament. Throughout the world, this is the usual way for producing consolidated versions of law. Ex-ante means that the legist responsible for changing a law directly changes the law without detour, without having to use a change order, without the risk of being misinterpreted. If a change order is necessary (e.g. out of formal or procedural reasons) it still may be produced, possibly as a second activity of the legist after he changed the text of the law, not as an afterthought by somebody else. Theoretically, there is even the possibility to generate the change order automatically, in a way similar to what Microsoft Word does when working in change mode.

Other legal information systems already implement ex ante consolidation (e.g. the EnAct system in Tasmania, JASPI in Slovakia, some Cantons in Switzerland), or are seriously considering it (e.g. the future federal KAV-System for Switzerland). These systems allow for a high degree of automatisation of the publication process and offer the benefits: faster publication, fewer errors, less manpower involved.

Both approaches have their merits: Ex-ante is authentic and allows more flexibility in automating the production of legal documents. Ex-post is not authentic and requires manual intervention, but allows for e.g. corrective intervention. Therefore, an example where manual intervention makes sense is the alignment of the four language versions of federal law in Switzerland.

eRecht, the work flow for the production of federal law gazettes is independent from the ex-ante – «ex post» discussion: data and metadata can be changed at any position in the work flow. And indeed, the possibility to add metadata simultaneously with data is used in eRecht already – currently not as a rule but where appropriate, and more frequently in formal structural elements («categories»), less frequently in material ones. The tendency is to increase the number of the latter ones, thereby moving forward to ex-ante as the general preference. This tendency gets international support, e.g. by CIRSFID (Bologna) and ITTIG (Florence), where Carlo Biagioli suggests to make not only the formal but also the material structures of the law (the «legal provisions») explicit.

For RIS, the differentiation between ex-ante and ex-post seemingly does not make sense – RIS is the final instrument for storing and publishing legal documents, and therefore always seems to be «ex post». However, the differentiation does make sense at the interface between eRecht and RIS – it has a direct impact on the number of documentalists needed at this point, and the number of errors introduced by human intervention at the sensitive interface between e.g. decided law and published law at federal level.

There are other interfaces as well, e.g. those to other governmental organisations using RIS for publishing law. This publishing requires ex-ante data to be delivered as RIS does not have the authority for «ex post» actions.

Speaking in general terms, all these interfaces are «interconnections between collaborative work flows (an R4eGov objective, à clause 2), in particular between the «publication work flow» within RIS and the work flows of external organisations, for publication upload as well as for information retrieval e.g. by commercial publishers. RIS-v3 has the mechanisms for implementing all these interfaces.

The results of this discussion largely have been implemented in RIS-v2 – it is possible to produce a time slice of e.g. a law – a version of the consolidated law at a specific date. However, the closely related functionality ex-ante still is in discussion. Therefore, an action point is left for the future (à clause 6) rather than for RIS-v3 (this clause). For the ease of understanding, current and future potential is covered within this clause.

This clause deals with the timed versions of a law. After a law is put into force it will not stay the same forever – it will change. Each change comes with a time stamp (and other types of metadata).

The current version of a law (the «geltende Fassung») usually is the one looked at by users. A version of law in force at a specific point of time may be called a «time slice» of law. The first time slice is the initial law. Out of the view of the process for producing law there will be future versions as well, one at least (initially the «draft bill») during the time a law is changed. If the law is published but not yet in force, an extra time slice representing a future version of the law exists, visible to the public.

The most straightforward method of storing time slices is to store them separately as separate files. Disadvantage: Any time slice has to store the whole law, even if the difference to the adjacent time slice is only a word. In a store for thousands of documents the ratio between one word and the whole document makes a big difference in required memory space.

Therefore, RIS-v2 takes a different approach: RIS chops a law (a document) into its paragraphs (resulting in XML fragments with an individual set of metadata like time stamps) and stores each of them separately. Retrieving the same law reverses the process, it «unchops» the fragments and produces a synthetic document on the screen or a file for retrieval. Taking the fragments with the right time stamps generates a time slice, a version of law in force at a defined point of time. Any time slice needs to store only those fragments which are different from others, needing much less memory space than storing all the time slices as a whole. Another advantage of using fragments is that hits (the results delivered by a search operation) are accurate to the fragment (paragraph) level. It is not necessary to view the whole document to find e.g. the occurrences of the highlighted search terms.

There are two generic issues to be covered by any time slice discussion: (1) the size of the fragments of which a time slice consists, and (2) at which point of the legislative work flow (the publication work flow in particular) may fragments be changed?

ad (1) The thinking of lawyers always has been based on paragraphs. Therefore, RIS-v2 maps this tradition. Each paragraph is electronically stored as an element of its own.

Unfortunately, a paragraph can have a size from a few lines to some 10 pages. Long paragraphs obviously defeat the purpose of chopping long text. Short paragraphs or sub elements of a paragraph might be preferable, because e.g. they simplify the use of tables à Fig. 4) comparing old text and new text of a law. Such tables (one called a synopsis) are already in use. So far no better compromise has been found than chopping long text to paragraphs with each paragraph corresponding to one XML fragment.

ad (2) The question of where to exchange fragments leads itself to the ex-ante – «ex post» discussion. In the legislative work flow, this discussion is closely related to the consolidation of law.

Consolidation of law used in RIS-v2 is ex-post: A legist issues a change order, which is decided by parliament, and published. A documentalist executes the change order by «ex post» amending the current version which then is published in RIS.

In the ex-ante approach the legist does not issue a change order. Instead, he implements the change in the text of the current version, creating the new version. Doing so he would normally use a synopsis (à Fig. 4), changing only those paragraphs which are affected. These represent the final government bill, passed to parliament. Independent from whether the parliament just passes the government bill or revises it, in the end the affected paragraphs are accepted in their final form – there is no need for ex-post consolidation any more. For publishing it is sufficient just to replace the affected paragraphs to produce a new current version.

If needed out of e.g. legal (or historic) reasons, it still is possible to use a change order. In the ex-ante case the legal information system might generate it automatically from the difference between old and new text, similar to the way Word produces annotations when in «change mode»⁸. Now the change order is an afterthought not the input for the manual ex-post consolidation. Misinterpretations and errors at this point of the work flow are eliminated.

What comes after consolidation? Another consolidation! This means that the legislative work flow is not a straight line with a beginning and an end – it is a circle (à Fig. 5). Each end is a new beginning. We may talk of an «everlasting process of law revision». With the ex-ante approach this process allows for a high degree of automation, allowing for «permanent electronic consolidation» as consolidation is inherent to this process.

One could go one step further and allow for a «Permanent Electronic Authentic Consolidation (PEAK)».

Currently, not many people use the authentic version of the Federal Law Gazette published in RIS – this version mainly is there to create credibility and trust. Additionally, it would not make sense to assemble all the authentic amendments with the authentic basic version to arrive at an authentic consolidated version of a law. Furthermore, nobody would have the authority to call such a version authentic. Instead, everybody just uses the published not authentic current consolidated version.

Instead, signing individual paragraphs (fragments) as e.g. results of the approval process in parliament (or the result of yet another legal procedure) could make them authentic. As a document (a law) is authentic if all its paragraphs (fragments) are authentic, the consolidated version will be authentic. Replacing some of the paragraphs (fragments) in the automatic consolidation process does not affect authenticity – each time slice will be authentic. The most used RIS applications (the current versions of law) would now directly benefit from credibility and trust.

Adding this capability to RIS would create a «number 1 achievement» visible to the world.

There not really is a discussion regarding the authenticity of a legal document. On paper, authentic versions were necessary, and continuing to think in the dimensions of paper they will continue to be necessary with electronic publications of legal documents. Therefore, the capability to handle authentic versions is implemented in RIS-v2 and in RIS-v3.

However, there is a strong component which deserves to be listed in the future potential of current deployment (à clause 6). This component is the «Permanent electronic authentic consolidation (PEAK)». For the ease of understanding in the context of its «paper» counterpart and its close relation to the preceding two clauses it is described here.

Contents of RIS is not authentic with the exception of what is published as «federal law gazette authentic» (an electronic version). This «authentic version» of the federal law gazette is available since 2004.

But what is an «authentic version»? In practice, an authentic version is authentic if it is defined to be authentic. It is as simple as that.

Not so long ago it was the paper Law Gazettes which published authentic laws or amendments. The publication process was well defined in a law of its own. Parliament gave justification, some president(s) had to sign and then publication could start by printing. Some definitions (legislative blessing) gave the printed copy the blessing to be authentic.

Today the process of authentic electronic publication still is not widespread. However, it is increasingly used. Where it is, in Austria and in most parts of the world, it still works very similar to the paper process. Some presidents still have to sign on paper, «to be on the safe side». Additionally, some civil servant electronically signs the document(s) on the server used for publication.

You can check that the published document is authentic – on the server, not in an environment which is under your control. Accessing an authentic document requires looking at two subsequent screens – the first one showing the result of checking the validity of the document’s signature, the second showing the document’s contents in the trusted Law Gazette layout. All the first screens of all authentic documents look nearly identical and do not show an obvious relation to the second screen. The second screen shows an HTML presentation of the authentic document (which is a set of signed XML fragments).

You can download the document from the server in different formats (HTML⁹, PDF and RTF). None of them is authentic, all of them are different from the signed XML version used on the server.

The discussion of the electronic authentic version goes in the following three directions.

To answer this question we have to recall the paper process for producing and changing laws.

There is the initial version of law and there are sequential amendments. Each amendment is a change order for the previous consolidated version. The Law Gazette publishes the initial law and amendments. It does not authentically publish the consolidated version.

In the life cycle of a law, each consolidated version represents a «time slice». It is interesting to note that an authentic amendment is based on a not authentic time slice. Consolidating one time slice with an authentic amendment produces the next non authentic time slice, and so on.

Why not use authentic consolidated versions? We arrive at à clause 5.4.3.

The only issue to be considered is that we do not always start with initial versions of law, but with an existing not authentic consolidated version. To build an authentic amendment on top of it, we have to declare this particular consolidated version as authentic, be it by a parliamentary act or some legislative blessing. Then, this act will never be necessary again – replacing authentic paragraphs/fragments by others always will create an authentic time slice.

We could request an end-to-end authentication: Some presidents sign electronically (not on paper as they currently do), or even the parliamentarians in the assembly could collaboratively sign, and the signed document is validated locally in the user’s work station.

Neglecting the organisational challenges of such a far reaching authenticity concept it is technically possible to implement it, based on available technology, with some effort. Alternatively, a functionality built into RIS-v3 could be used, free of charge: the end-to-end security feature implemented in the Semantic Repository, the core database of RIS-v3. Additionally, the end-to-end security feature could allow improvements for the RIS content category «judicature of the courts» (e.g. for automating the anonymisation of personal data).

To continue on what the last paragraph stated (à page 18), it would be possible to introduce Permanent Electronic Authentic Consolidation (PEAK). Some presidents (or other legally entitled persons) could sign each structural element (e.g. each paragraph) before storing it in RIS. As a result, authentic time slices of the consolidated version of a law could be produced.

What could be done additionally is, to transfer the verification of the signatures to the user. Currently with RIS-v2 verification is done as a separate step before accessing the authentic version of a federal law gazette. Currently it has to be believed that verification really is done (and not replaced by a fake certificate page) and that the screen presentation available in the second step really is the authentic version of the federal law gazette. Currently some belief in a legislative blessing is necessary to accept authenticity.

Usually verification has to be done at the receiving end, in the workstation of the user, under full control of the user. All what would be needed is downloading a signed time slice. To do the verification check locally, some local functionality is needed (e.g. a «Bürgerkartenumgebung», the Austrian security middleware required for smart cards). Alternatively, there are public web places (e.g. from RTR) which do verification e.g. for signed PDFs remotely – the key issue is under control of the user. If implemented, the belief in a legislative blessing is not necessary any more.

What clauses 5.2, 5.3, and 5.4 said regarding work flow can be summarised in one sentence: One of the biggest challenges is to revise the work flow for the production of laws. This revision is not a challenge because of technical issues but because of the organisational and legal implications¹⁰. However, these implications are out of the scope of this paper.

Starting point is the work flow for producing and publishing a law (à Fig. 5). It transports the initial version of law from station to station of a production process and finally delivers it to RIS for publication. The work flow is a circle: For a change, the whole circle starts again and produces an amendment (a change order) to this law – and so on. Each amendment is published as well. Initial version and amendments are published authentically, mapping the old Bundesgesetzblatt (Law Gazette) procedure.

A current version (synonym: consolidated version) of a law is the integral of the original version plus all amendments.

For generating the current version in the traditional ex-post approach (as implemented in RIS-v2), documentalists (not the legists at the beginning of the work flow) take care of the consolidation manually, outside of the work flow. Based on the current version they implement what the change order says – if they understand it correctly, and if they use the right (not authentic) current version. Therefore, consolidation might be adequate, but not free of errors. However, the result is published as the new current version.

For generating the current version in a new ex-ante approach¹¹, consolidation can be automated. No documentalists are needed, no errors are introduced by using the change order, having to re-invent what the legist who wrote it had in mind, the time to publish is reduced.

The ex-ante approach requires the legist who so far created an amendment now generates the final text of the new version of a law. Creating this final text does not mean that he has to handle the text of a law as a whole – he just continues to use the same synopsis he already uses now – a table comparing old text and new text (à Fig. 4), with unchanged paragraphs/fragments hidden. In this form, creation of new text is quite easy and straightforward.

If required by law or some tradition the legist still might produce a change order as well – as he did in the past. However, technically speaking, this task may be moved to the legal information system, automatically producing the change order. The Tasmanian EnAct system has some decades of experience with this approach.

Once finished, the legist puts the results of his work on the conveyor belt of the work flow (which is eRecht) which transports the documents through several stages (e.g. the parliament) to finally deliver to RIS for publishing:

• the agreed version of the initial version of a law for authentic publication;
• the agreed version of an amendment (change order) for authentic publication;
• in case of the ex-ante consolidation the agreed full text corresponding to the change orders for automatic (if wanted, authentic as well) generation and publication of the consolidated version

In case of the ex-post consolidation the legist just needs to deliver the initial version of a law and the amendments. It is up to the documentalists at the end of the work flow to manually generate a new consolidated version from the current one and to add their understanding of the amendments.

As has been said, the organisational and legal implications certainly will require more effort than implementing the required technical changes.

Looking at processes, production processes in particular, the term «quality» is in common use. As consumers, we are used to requesting (and receiving) goods or services of a certain quality. For using the term «quality» in the context of legal documents a paradigmatical change has to take place: The vertical impact of legislation does not become obsolete; however, for introducing the term «quality» it has to be replaced by a horizontal view, resulting in a work flow (à Fig. 6).

So far, using a horizontal view for looking at the production of legal documents is unusual. This view was presented for the first time in the «Law via the Internet» conference in Florence, October 2008 [4]. This presentation had the focus on the work flows from the point of view of R4eGov. However, the R4eGov environment is much more complex and requires a wider viewing angle than a «simple» work flow (like eRecht) for producing law.

This wider viewing angle allows for defining quality for the process and quality for the product (à Fig. 7). For defining the quality of a process «quality management systems» or «total quality management systems» are in widespread use in the manufacturing and service industry. One of the best known standards in this area is ISO 9000. Having made a short poll at another conference (IRIS 2009 in Salzburg) the result was that none of the participating organisations (mostly from government, administration and from universities) currently has such a quality management system in place.

There is one discipline which is fully process oriented and very much aware of quality: software development. There are many similarities between writing a piece of law and writing a piece of software. Therefore, it is somewhat surprising that the tools (the 4^th generation tools in particular) which are available for software development are not used (or mapped for the use) in the development of laws – so far. What works well for software development (e.g. the development of one homogenous code in independent teams working independently) should work well in developing laws, too. There is much room for further action.

Defining the quality of a product requires not only the definition of what a product is but also its specification in technical terms. Of course, if we try to define a law as a product, we will run into difficulties when we try to define it in technical terms. There is nothing like its height or width. The (unproven) impression is that only indirect indicators of quality possibly could be defined like the complexity of a law (how understandable is it?) or which impact does it have e.g. on the environment?

In part, defining the quality of a product in technical terms has some commonalities with the metrics used for assessing the impact of a law (à Fig. 8). Trying to do that is as unheard of.

Assessing the impact of a law is judging its qualification of doing what it was intended for, whether it is qualified to do the job. This way of looking at laws has some similarity with assessing the performance of a company. For that purpose, Balanced Score Cards (BSC) was published by Robert S. Kaplan and David P. Norton, Boston 1996. Today, BSC is a widely recognised and accepted performance measurement tool that is currently used in thousands of organisations around the world. Not in the legal environment, as far as known.

Of course, BSC would have to be adjusted for the purpose. Its initial four perspectives: customers – financial – business processes – resources would have to be mapped to the ontology of the law. Again, this is something unheard so far.

What will be easier to achieve is achieving qualification by certification. Again, this methodology is well established in the production and service industry. An example is the ISO 9000 certification (à Fig. 9) – its intention is to regularly check whether all processes are implemented and are working as intended, and that the goal of permanently achieving improvements (at least no degradation) is met. Certification of a quality management system of a the production process of laws means that all formal criteria required for a selected definition of quality are met and proven.

Today, we are used to receive services of a proven quality (e.g. in healthcare where ISO 9000 certification becomes increasingly popular) – don’t we deserve to receive a proven quality of service from our administration as well? Certification would indicate to the «customers» that there is reason for them to trust the service provider. Working in the other direction, score cards indicate to the service provider that he is on track with his objectives.

One of the effects of the Project on this discussion is that it provides for the technical grounds to implement work flows in complex organisational environments. Automating work flows in general and complex ones in particular always results in the requirement for quality control. In a legal environment, this is an opportunity to discover new grounds, possibly in further projects.

The Demonstrator mainly demonstrates input to RIS. Third parties are all the Austrian authorities feeding the 33 RIS applications. Referring to à Fig. 15, the third parties are the publishing organisations. Communication takes place machine–to-machine between the work flow of the publishing organisation and the RIS input work flow.

The UBAS application (1 out of 33 RIS applications) uses the Austrian Portal Network (PV) as a transport mechanism (à Fig. 10). The current Demonstrator configuration can easily be expanded to all other applications.

Out of the point of view of RIS using the Austrian Portal Network is all required: It provides for secure access using strong authentication. It is based on a nation-wide PKI, and in the current version it distributes authentication credentials as signed private HTTP headers which the PV implementation used at this point of time. However, anticipating the development of PV, the Demonstrator additionally supported innovative SAML-based R4eGov solutions, anticipating those PV developments which are operational now. Recently, even an innovative PV application for secure logon (security class III) has been demonstrated.

If the Demonstrator is well accepted by the Austrian Portal Network (PV) community the intention is to migrate its achievements (currently available only to BKA) to the PV community. The final intention is to have all authorities connected to Austrian Portal Network (PV) publishing in RIS without manual intervention, achieving one of the R4eGov objectives (à page 6) – the interconnection of independent work flows coming from different vendors, and working under quite some different organisational conditions.

RIS output currently is confined to using a standard web browser. Fortunately, this is what is the workhorse of RIS is –the native RIS user interface.

Currently there is a discussion with a Swiss publisher. From RIS, he wants to retrieve jurisdiction daily. Unfortunately, there currently is no service meeting this requirement even although it looks simple. At the moment, this requirement would have to be manually processed by RIS operators. With the R4eGov functionality implemented in RIS-v3 for interconnecting work flows it will be possible to meet the Swiss publisher’s requirement, and that of all other publishers (if they ask), with access rights precisely confined to the specific data requested. This output capability has quite some commercial impact, too.

Another example of what can and should be done with an output from RIS is its interconnection to N-Lex (à 11). The problem with the current connection is not so much that only consolidated federal law is available (this is what is accessed most frequently). The problem is the reduced functionality of the user interface (compare Fig. 11 with Fig. 12). The reason for this less than satisfactory behaviour has not been analysed so far. Certainly, supporting the SOAP interface which the Publications Office specifies would achieve a better result – RIS-v3 provides this interface. As N-Lex is an official EU portal any RIS achievement or underachievement is very visible at this portal.

So far, all European authorities responsible for publishing legal information have gone their own individual ways. They use data base, types of documents put into this data base, schemata used, user interfaces – they are different. Is there any need to standardise them?

Standardisation only makes sense if information has to be exchanged between the publishing authorities. So far there has not been much need for the governmental authorities to do that. However, this self-centric view is going to change.

The parliaments are increasingly looking into the activities of the parliaments of neighbouring states as an example (e.g., what are the proceedings in Czech Parliament regarding Temelin?). This looking does not really require a full interchange of information, just user access to remote legal information. Currently, there is no N-Lex-type of a portal, neither for parliamentary information, nor for legal information at province or municipal level. N-Lex-type functionality would be needed without a central portal, for direct connections between partners exchanging (at least retrieving) information.

One answer to support direct connection between incompatible legacy systems is using the IOP-Gateway. This gateway meets the R4eGov Project objective «… concrete interoperation of web service enabled legacy public sector applications was to be achieved using collaborative work flows». Based on RIS-v3 this answer should work in an Austro-centric way («we can communicate with everybody») and would not necessarily require changes at the sites of the communication partners.

An alternative is introducing some level of standardisation – possibly at a quite high level, e.g. using Dublin Core. Standardisation is good only if both ends of a communications relation adhere to it. As an example, the key point of the Internet is that everybody is using the same Internet standards, worldwide. There are not many examples like this one.

Even for N-Lex adhering to something like Dublin Core is essential. Dublin Core defines semantics, this is common metadata like those required to issue queries using the user interface depicted in à Fig. 11. Disagreement on metadata results in the gray search fields and in the lack of search fields compared with à Fig. 12.

Of course, there are standards facilitation the exchange of legal information. Their common denominator is the Internet standard XML. XML is a well-defined and standardised syntax. To standardise legal information semantics is necessary as well. XML plus Dublin Core seems straightforward; the problem is that this combination lacks the capability to map the specific requirements of an administration publishing law. As not one administration matches another one, each uses an XML schema of its own. What makes things worse is that many of these schemas are oriented towards the old print outputs of the Legal Gazettes and do not pay much attention to electronic publishing and searching an electronic publishing system.

Of course, there are attempts for standardisation. However, there is no formal standard yet, but first steps in the standardisation process are made already.

CEN MetaLex is the «Open XML Interchange Format for Legal and Legislative Resources». CEN MetaLex claims: «The standard will enable public administrations to link legal information from various levels of authority and different countries and languages. Moreover, the standard will enable companies that are active in the field of legal knowledge systems to connect to and use legal content in their applications, which allows them to support a much larger market. An open interchange format will also protect customers of such companies from vendor lock in. Finally, the standard will help to improve transparency and accessibility of legal content for citizens and businesses.»

In the CEN standardisation process MetaLex is a workshop agreement only, not a standard. METADAT contributed to this agreement which was finalised 2010. In the CEN process such an agreement is one possibility to start the formal standardisation process. So far, there has not been sufficient interest to do so. Based on the 2010 workshop agreement, the standardisation process seems to be frozen.

MetaLex is mainly used in the Netherlands, the place where it was developed as an activity of the Dutch Leibniz Centre of Law (University Amsterdam).

Akoma Ntoso is not a standard, either, it is an initiative of «Africa i-Parliament Action Plan» which is a programme of UN/DESA.

Akoma Ntoso («linked hearts» in Akan language of West Africa) defines a «machine readable» set of simple technology-neutral electronic representations (in XML format) of parliamentary, legislative and judiciary documents. Additionally, in provides for guidelines for legal drafting (à Fig. 13 and  Fig. 14).

Akoma Ntoso XML schemas make «visible» the structure and semantic components of relevant digital documents so as to support the creation of high value information services to deliver the power of ICTs to increase efficiency and accountability in the parliamentary, legislative and judiciary contexts.

Akoma Ntoso was under the lead responsibility of the Italian participants in the MetaLex activities. There was MetaLex input to Akoma Ntoso. Akoma Ntoso development takes place within OASIS («LegalDocML»¹⁴). It is an active development (version 3 released March 2013). Currently the LegalDocML Technical Committee closely co-operates with the KAV of the Swiss Bundeskanzlei (Federal Chancellery) to incorporate generic Swiss requirements in the OASIS standard. KAV is in the process of defining a new legal information system from scratch, starting with the XML schema. Recently KAV made a decision in favour of Akoma Ntoso.

Just looking at the guidelines for legislative drafting it turned out [5] that the guidelines, to a large extent, cover the same issues. However, in both guidelines the effects of electronic publishing are missing – they need to be included in later versions of the guidelines.

In December 2011 the Working Party on e-Law presented the first template of ELI [6]. ELI is a naming convention using «HTTP URIs» to specifically identify all online legal information officially published across Europe.

ELI states that EUR-Lex and N-Lex are important portals and adds: «Knowledge on the substance and application of European Union law cannot be solely acquired from EU legal sources, but also from national sources, in particular from national legislation implementing European Union law.»

ELI helps to facilitate access to national resources. ELI uses unique identifiers and structured metadata in referencing national legislation in Official Journals and Legal Gazettes. «ELI intends to facilitate the further development of interlinked national legislations and to serve legal professionals and citizens in their use of these databases, a common system for the identification of legislation and their metadata is regarded as useful.»

«For the identification of legislation, ELI is a unique identifier which is recognizable, readable and understandable by both humans and computers, and which is compatible with existing technological standards. ELI guarantees a cost-effective public access to reliable and up-to-date legislation. Benefiting from the emerging architecture of the semantic web, which enables information to be directly processed by computers and humans alike, ELI allows for a greater and faster exchange of data by enabling an automatic and efficient exchange of information.»

Meanwhile KAV (Switzerland) has committed using ELI for the new legal information system. However, the Swiss approach will be more general, with ELI being a subset of naming mechanisms supported.

In the context of input to and output from RIS there is only one user interface: the one used in the manual version of retrieving process (à Fig. 15). This interface builds upon a standard web browser interface. In the following the terms «user interface» and «native RIS user interface» always refers to this particular interface.

There is no user interface between the work flows of the publishing organisation and RIS input – at this point a machine-to-machine interface is used. The user interface used by the publishing organisation is out of scope for of this publication, as are the various administrator interfaces within RIS.

This interface is well-known. However, more could be done. Out of the experience gained in the Project, and dependent on the RIS application to be used (currently there are 33 of them) the following functionalities or items should be added to the RIS user interface:

• Other languages – e.g. English. Current support of English is very limited, and other languages are not even thought of. However, selected information should be available for the neighbouring countries in their language. Whether current activities for developing N-Lex on the European level will be able to serve as a substitute remains to be seen.
• Thesauri – getting the user out of the trap of having to use the right word for searching, spelled correctly
• Semantic frontends¹⁶, e.g. allowing users for natural language input. In Austria, the results of text analysis done by Prof. Erich Schweighofer could be built upon. Semantics, of course, would be a research item on its own.
• Intuitive graphical interfaces – as an example Prof. Friedrich Lachmayer developed one for simplifying the handling cases done by agents of insurance companies. Prof. Lachmayer is an expert on this issue, searching for new approaches in the disciplines of legisprudence and visualisation of law, with regular contributions to the «Legistic Talks Klagenfurt» (Klagenfurter Legistik-Gespräche) and the «Munich Conference on the Visualisation of Law» (Münchner Tagung der Rechtsvisualisierung). Additionally, the experience of Dr. Wolfgang Kahlig with mapping of law to flow charts should be mentioned. This experience is not generic; however, but it greatly simplifies the «construction» work for generating a law, and for recognising the dependencies of all clauses of a law, simplifying work e.g. of a judge.

Unfortunately, none of the preceding functionalities or items currently are worked upon.

The distinction between a native RIS interface and the need for a separate front end does not have technical but organisational reasons. Frontends could be services by third parties. Of course, the involvement of third parties invokes commercial considerations – these are out of the scope of this paper.

Example 1: help.gv¹⁷

help.gv is a very successful e-Government portal in Austria. In this portal the «third party» is a dedicated department of BKA.

Based on the current functionality of help.gv a user (a citizen) in a specific situation (e.g. birth of a child) can query help.gv for the required interactions with public administration. The user will get a comprehensive set of canned answers to his most likely questions. The point is – how to get beyond the canned answers? One possibility is to consult law and jurisdiction stored in RIS. Therefore, help.gv could act as a frontend to RIS.

Instead of having to use the native and very generic RIS user interface, help.gv could use the predefined contexts of the situations it covers for giving a more specific access to RIS. Specific access would rely on the same intellectually generated sematics used for the canning of answers now narrowing the search options for RIS. Using generic IT based semantic technologies would not be required.

Example 2: RIDA¹⁸

RIDA is the name of a company and of its product, closely related to Prof. Dietmar Jahnel. RIDA claims: «In contrast to all other databases the RIDA database was developed for the user making queries. It uses a unique index for efficient and fast access of information, supported by a number of supportive tools.» The content partially is the same as with RIS, partially it is complementary (e.g. legal literature and professional commentary notes to the jurisdiction of courts and administrative tribunals). Key point is that all these data are manually annotated, e.g. by key words (à Fig. 16).

Being a commercial offer, RIDA legally cannot be integrated into RIS (RIS must be free of charge, leaving the «value added» market to private suppliers). But it might serve as an idea for how to create similar frontends. Possibly such a frontend would require the RIS data to be augmented with metadata, possibly it means a more creative use of existing metadata. In any case products like RIDA show the direction for further improvement of the functionality of the user interface in the direction of a semantic frontend¹⁹.

The Project achieved what R4eGov intended to achieve (à clause 2). In particular, RISv2 is up and running since the beginning of 2008, and Austrian administration broadly accepts its capabilities. RIS-v3 was successfully demonstrated, the enhanced capabilities developed in the Project do work and are ready for use.

However, after-project-development of the demonstrator to a production system never happened (mostly due to the economic crisis and resulting budget cuts). With only one application working (the UBAS application, à page 12) the Project results were a mere proof of concept. The opportunity was missed to exploit the achievements to a larger audience, waiting for being kissed awake.

Having changed the RIS philosophy from being avant-garde to reactive (demand driven only), current situation is stable. However, there was some internal discussion regarding implementing «Tasmania» and a thesaurus.

«Tasmania» is the BKA internal code name for implementing PE(A)K, the Permanent Electronic (Authentic) Consolidation. (A) is in brackets because authenticity of the consolidated version has not been considered a priority yet²⁰. Implementing the closed circle work flow of à Fig. 5 is the issue. The main arguments are:

• improving quality of the publication by avoiding²¹ ambiguous change orders and misinterpretations by the documentalists;
• speeding up the publication process²² by eliminating the need for ex-post consolidation;
• saving resources by eliminating the duplication of effort²³ required by ex-post consolidation.

The internal discussion has not produced any visible results, so far. However, the status of legal consolidation in view of PEAK has been published [7].

The Thesaurus is not a new idea. As an example, it would allow for searches using synonyms. An example is the EuroVoc²⁴ Thesaurus used by the Publications Office of the European Union.

One of the prerequisites to arrive at a thesaurus is a well-defined terminology of legal terms, e.g. in a terminology data base. To avoid the discussion of the economic crisis and resulting budget cuts from the beginning, the idea was to apply for a 100% publically funded research project: «Central Law Terminology & Readability Improvement –System (CELT-RIS)». Main contributor and project co-ordinator was the Austrian German Research Centre / Centre for Plurilingualism, University of Graz, represented by Prof. Dr. Rudolf Muhr; project partners, amongst others were the BKA (RIS) and the Documentation Centre of the Austrian Parliament. The project proposal was evaluated positively but did not receive funding.

RIS has been avant-garde up to the time when making RIS-v2 operational: RIS/eRecht was awarded the United Nations Public Service Award 2007 (à Fig. 3). Then RIS-v3 was finished as R4eGov demonstrator, but was not implemented. Whether implemented or not, some of its enhanced capabilities still are state-of-the-art.

Currently, Akoma Ntoso creates an environment for legal information systems wanting to implement such enhanced capabilities. According to a LinkedIn blog of Monica Palmirani from February 2012 some success stories of Akoma Ntoso are not «just Africa»: European Parliament for managing the bill amendments (project deployed); Kenya Law Report for publishing their legal documents (project in progress); Parliament of Uruguay for managing the bill legislative process (project just started); Brazil Senate for publishing the law point-in-time (Portuguese version inspired by Akoma Ntoso – project deployed); conversion in Akoma Ntoso of some California State legislative datasets.

Of course, standardising XML for publishing legal texts is only one part of the game. Another is the environment of the publishing organisation, and what enhanced capabilities this organisation implements.

Switzerland is an example. There currently are activities in several cantons. As an example, during the 2012 Magglinger Rechtsinformatikseminar the following cantons report:

• Wallis has a new CHLexML²⁵ based legal information system in operation
• Aargau has an XML based legal information system in operation. It is a LexWork application, replacing Word by an XML editor, with ex-ante consolidation («Tasmania» in operation) capabilities using a synopsis (like à Fig. 4).

At the federal level the Swiss Federal Chancellery (Bundeskanzlei) is in the process of replacing the current legal information system by a new one, uninspiredly called «the new KAV-System» (Kompetenzzentrum für Amtliche Veröffentlichungen). The Project is built upon a defined «roadmap» starting 2012, lasting up and including 2016. Key work done so far is

• Upgrading the current legal information system with an attractive user interface (e.g. with special semantic capabilities to work in the 4 official languages, e.g. with using a 4 language thesaurus). This interface was demonstrated March 2013 and is due in 2013-Q2.
• Defining the basics for the new KAV-System from scratch.
• Deciding for an XML standard. This decision has been made: Akoma Ntoso. Meanwhile this decision has been verified – all current requirements for publication are met.
• Deciding for the naming conventions (mechanism use for referencing between internal and external documents, and from the outside. This work is in progress and might come up with the most general approach (URN: – URI: – ELI: specifications, all of them), it might focus on URI: for the moment, with ELI: compatibility.

No matter what the Swiss implement, in the end their new KAV-System could be more advanced than RIS.

Austria just is in the process of re-defining the ICT-strategy 2014-2020²⁶. One of the goals of this strategy is to develop Austria into a top position within the ICT-oriented nations. RIS could contribute, enhancing RIS even more.

[1] Barotanyi, B. / Hoffmann, H. / Kotsch, L. / Lachmayer, F., Consolidation of pilot results, summary of lessons learnt, and the preservation of setups and information, R4eGov-WP10-D04-final.pdf, Project deliverable, 10th June 2009

 

[2] Hoffmann, H. / Lachmayer, F., From Legal Categories Towards Legal Ontologies, in: LOAIT Workshop of ICAIL-05, Bologna 6th June 2005

 

[3] European Forum of Legal Gazettes' Working Group 1, Access to Legislation, European Legislation Identifier (ELI), Council of the European Union , Doc 17554/11 (Jurinfo 71), 21st December 2011

 

[4] Hoffmann, H. / Lachmayer, F., ICT and Quality of Information, in: Law via the Internet, Florence 30th/31st October 2008

 

[5] Hoffmann, H. / Lachmayer / Pürgy, E., Legistische Richtlinien für Afrika im Kontext der österreichischen Legistik-Tradition, in: IRIS 2010, Salzburg 25th to 27th February 2010

 

[6] Council of the European Union, Working Party on e-Law, European Legislation Identifier (ELI) – Draft conclusions, ELI(2012-st10960-en).doc, JURINFO 25 paper 10960/12, 13th June 2012

 

[7] Hoffmann, H. / Lachmayer, Legal Consolidation in Austria, in: Summer School LEX – Managing Legal Resources in the Semantic Web, Florence 7th to 11th September 2009

---

 

Brigitte Barotanyi; Manager of Abt. I/13 eGOV Program- and Project Management, Software Development und Legal Informatics, Federal Chancellery , Vienna, Austria.

Harald Hoffmann; Senior Consultant for Legal Informatics with METADAT GmbH, Vienna, Austria.

Leszek Kotsch Senior Software Architect with METADAT GmbH, Vienna, Austria.