YEARS OF EUROPEAN ONLINE ANNÉES DE EN LIGNE ...
YEARS OF EUROPEAN ONLINE ANNÉES DE EN LIGNE ... YEARS OF EUROPEAN ONLINE ANNÉES DE EN LIGNE ...
grammar or in the instances. the elements are deined in alphabetical order, just to simplify the access to the elements for a human user. the various models are always completed by annotations or comments which explain the semantic role of a given element. these explanations are based on the deinitions in the metadata glossary. Although it is possible to use the various elements at any place within an instance, it is recommended to integrate them within a single block. this should simplify searches in the documents. furthermore a control of cardinality is only possible within the predeined block. Another possibility is the creation of an element in the local schema which is related to the efog-type. from a technical point of view this approach is as eficient as the use of the efogblock element; the only disadvantage is that for researching the instances the name of the block should be known. the grammars will be available from the formex website, which is managed by the Publications Ofice (http://formex.publications.europa.eu/schema/). the URL is completed by the name of the grammar and is also valid for the DtD. the directory will always contain all versions of the grammars. So in the case of improvements there is not necessarily the need to review and update all instances. the syntax of the names of the grammars has been deined as follows: • [ 1] name :: = name.schema | name.DtD • [ 2] name.schema :: = ‘efog_’ ‘cnt_’? date ‘.xsd’ • [ 3] name.DtD :: = ‘efog_’ date ‘.dtd’ • [ 4] date :: = d{8} • [ 5] d :: = ‘0’|‘1’|‘2’|‘3’|‘4’|‘5’|‘6’|‘7|‘8’|‘9’. the date relects the date when the version of the grammar was adopted. the constant part ‘cnt_’ is only to be used when the schema is referred to by means of the namespace technology. (the schema is to be found in Annex 2B.) As discussed earlier in this document, the implementation can be achieved in different ways: a copy-paste method, the inclusion of the schema, or a namespace reference. for the DtD, the copy-paste method and the inclusion are feasible. the copy-paste method is highly deprecated; details on inclusion and namespace references can be found in Annex 2D. 6. BENEfItS Of COmmON mEtADAtA In this chapter the working group will exemplify the beneits of common metadata by different cases of use that hopefully will promote the dissemina- 01_2007_5222_txt_ML.indd 94 6-12-2007 15:13:49
WORKSHOP tion of the common metadata. It is important to understand that the implementation of the common metadata does not exclude the use of systemspeciic metadata; with the proposed naming convention, there should not be any conlicts. the main beneits of the common metadata could be: • improved access to a set of standard deinitions of metadata terms through the Internet, • improved standardisation of metadata for dissemination and international comparisons, • support to XmL structures for searching and exchanging metadata on legislation. 6.1. Checklist for metadata design when creating or redesigning a legal information system, the common metadata can be used as an inspiration or a checklist to ensure that the most typical subjects of legislative metadata are covered. this advantage also covers the proposed grammar, where metadata designers can use the XmL schema deinitions when deining local metadata. 6.2. Facilitating access to legislation across different legal information systems Implementing the common metadata will facilitate the creation and maintenance of cross-system portals giving access from the same website to multiple legal information systems. this is made possible when the portal can be designed with a uniform interface to metadata in the different systems. the opposite case is also facilitated when new legal information systems are created or existing systems are renewed. the new or redesigned sites can more easily be integrated in the portal; if the portal supports the common metadata, the access to a metadata search is more or less prefabricated. Besides the more technical beneits for cross-system portals, users will hopefully ind it easier and more intuitive to query the different systems. when metadata are common, the query in different systems will not be hindered by confusion over ‘where to search for what’. 94 | 95 01_2007_5222_txt_ML.indd 95 6-12-2007 15:13:49
- Page 44 and 45: It is a dificult task to predict th
- Page 47 and 48: MEETING OF THE COUNCIL WORKING PART
- Page 49 and 50: SOUVENIRS D’UNE DÉLÉGUÉE NATIO
- Page 51 and 52: EUR-LEX TODAY AND TOMORROW After mo
- Page 53 and 54: MEETING OF THE COUNCIL WORKING PART
- Page 55 and 56: MEETING OF THE COUNCIL WORKING PART
- Page 57 and 58: MEETING OF THE COUNCIL WORKING PART
- Page 59 and 60: DOCUMENT ANALYSIS AND LEGAL INFORMA
- Page 61 and 62: MEETING OF THE COUNCIL WORKING PART
- Page 63 and 64: MEETING OF THE COUNCIL WORKING PART
- Page 65 and 66: MEETING OF THE COUNCIL WORKING PART
- Page 67 and 68: LIFE AS A CELEX HOST INtRODUCtION I
- Page 69 and 70: MEETING OF THE COUNCIL WORKING PART
- Page 71 and 72: MEETING OF THE COUNCIL WORKING PART
- Page 73 and 74: CONCLUSIONS first, I would like to
- Page 75 and 76: En tant que déléguée de la Grèc
- Page 77 and 78: LEGAL XML — USE OF XML FOR THE PR
- Page 79 and 80: WORKSHOP • publishing technologie
- Page 81 and 82: WORKSHOP • NiR and the NiR editor
- Page 83 and 84: WORKSHOP tors, thus providing the o
- Page 85 and 86: WORKSHOP 3. SCOPE the expected resu
- Page 87 and 88: WORKSHOP gestützt auf die Verordnu
- Page 89 and 90: WORKSHOP which describe general com
- Page 91 and 92: WORKSHOP Arithmetic Poetry. Ameri
- Page 93: WORKSHOP Metadata fields collected
- Page 97 and 98: ELECTRONIC PUBLISHING OF LEGISLATIO
- Page 99 and 100: WORKSHOP the working group has focu
- Page 101 and 102: WORKSHOP • the integrity of a rec
- Page 103 and 104: WORKSHOP Examples of different appr
- Page 105 and 106: WORKSHOP conidence uses certiicatio
- Page 107 and 108: WORKSHOP 3. LEGISLAtIVE ISSUES CONC
- Page 109 and 110: WORKSHOP signature, is only publish
- Page 111 and 112: WORKSHOP 3.2.4. ARE THERE ACTS, DEC
- Page 113 and 114: WORKSHOP Electronic signature of PD
- Page 115 and 116: WORKSHOP formats are available: htm
- Page 117 and 118: WORKSHOP the chain of conidence is
- Page 119 and 120: WORKSHOP the object of SOLON is to
- Page 121 and 122: WORKSHOP 5. A secure session is now
- Page 123 and 124: WORKSHOP ESTONIA A certiicate-based
- Page 125 and 126: WORKSHOP ertheless, some assistance
- Page 127 and 128: WORKSHOP (b) If the system is XmL-b
- Page 129 and 130: COHERENCE OF TERMINOLOGY AND SEARCH
- Page 131 and 132: WORKSHOP nym for legal categories,
- Page 133 and 134: WORKSHOP Article 4(2) of Directive
- Page 135 and 136: WORKSHOP the tool could prove to be
- Page 137 and 138: EUR-LEX: FROM DATA STRUCTURES TO LE
- Page 139 and 140: WORKSHOP duces a ‘magic result’
- Page 141 and 142: WORKSHOP sion of the current one, i
- Page 143 and 144: WORKSHOP for test and demonstration
grammar or in the instances. the elements are deined in alphabetical order,<br />
just to simplify the access to the elements for a human user.<br />
the various models are always completed by annotations or comments<br />
which explain the semantic role of a given element. these explanations are<br />
based on the deinitions in the metadata glossary.<br />
Although it is possible to use the various elements at any place within an<br />
instance, it is recommended to integrate them within a single block. this<br />
should simplify searches in the documents. furthermore a control of cardinality<br />
is only possible within the predeined block. Another possibility is the creation<br />
of an element in the local schema which is related to the efog-type. from<br />
a technical point of view this approach is as eficient as the use of the efogblock<br />
element; the only disadvantage is that for researching the instances the<br />
name of the block should be known.<br />
the grammars will be available from the formex website, which is managed<br />
by the Publications Ofice (http://formex.publications.europa.eu/schema/).<br />
the URL is completed by the name of the grammar and is also valid for<br />
the DtD. the directory will always contain all versions of the grammars. So in<br />
the case of improvements there is not necessarily the need to review and update<br />
all instances. the syntax of the names of the grammars has been deined<br />
as follows:<br />
• [ 1] name :: = name.schema | name.DtD<br />
• [ 2] name.schema :: = ‘efog_’ ‘cnt_’? date ‘.xsd’<br />
• [ 3] name.DtD :: = ‘efog_’ date ‘.dtd’<br />
• [ 4] date :: = d{8}<br />
• [ 5] d :: = ‘0’|‘1’|‘2’|‘3’|‘4’|‘5’|‘6’|‘7|‘8’|‘9’.<br />
the date relects the date when the version of the grammar was adopted.<br />
the constant part ‘cnt_’ is only to be used when the schema is referred to by<br />
means of the namespace technology. (the schema is to be found in Annex 2B.)<br />
As discussed earlier in this document, the implementation can be achieved<br />
in different ways: a copy-paste method, the inclusion of the schema, or a<br />
namespace reference. for the DtD, the copy-paste method and the inclusion<br />
are feasible. the copy-paste method is highly deprecated; details on inclusion<br />
and namespace references can be found in Annex 2D.<br />
6. B<strong>EN</strong>EfItS Of COmmON mEtADAtA<br />
In this chapter the working group will exemplify the beneits of common<br />
metadata by different cases of use that hopefully will promote the dissemina-<br />
01_2007_5222_txt_ML.indd 94 6-12-2007 15:13:49