The schema is based on best practices from amongst others the previous versions of the MetaLex
schema (and also the MetaLex/CEN schema), the Akoma Ntoso schema, and the Norme in Rete
schema. Other important sources of inspiration are i.a. LexDania, CHLexML, FORMEX, R4eGov, etc. In addition to
these government or open standards there are many XML languages for publishing legislation in use by publishers. Standards like PRISM4, in which major publishers are involved, are also a source of inspiration.
See:
http://www.metalex.eu/
http://www.akomantoso.org/
http://www.nir.it/
http://www.prismstandard.org/
Source of law
A source of law is the content (textual information as well as other multimedia content) of a
document that can be, is, was, or presumably will be used to back an argument concerning
the existence of a norm or definition in a certain legal system, or, alternatively, a writing used
by a competent legislator to communicate a norm to a certain group of addressees. The
classification as a source of law can be derived from the intent and legislative competence of
its originator, or from the way it is used in the processes of law. Source of law is a familiar
concept in law schools, and may be used to refer to both legislators (fonti delle leggi, sources
des lois), legislation and case law (fonti del diritto, sources du droit), custom, etc. In this workshop it strictly refers to bibliographic entities. A single source of law is an expression,
unless otherwise specified.ggi, sources des lois), legislation and case law (fonti del diritto, sources du droit),
custom, etc. It should be noted that many romance languages make a distinction between the
legislator as source of law, by way of speaking or writing, and the law as source of right(s),
which is presumably what the existence of the law brings about.
In its broadest sense, the source of law is anything that can be conceived of as the originator
of legal norms. In the context of this workshop it strictly refers to communication in writing,
and in a sense covers the fonti del diritto in Italian and sources du droit in French. There are
two main categories of source of law in writing: legislation and case law.
As understood by the members of the workshop, legislative resources and legal resources
are also writings.
The notion of a legislative resource includes legislation, and all writings produced by the
legislator explaining and justifying legislation. The legislator is a legal person: it exists
separately from any natural persons and organizations involved in the process of drafting and
evaluating legislation. It is the formally correct completion of certain processes, usually
dictated by law, that makes the legislator the formal author of a writing, and at the same time
identifies the addressees to whom it applies. Obviously, the persons and organizations
involved in the process of legislating may produce writings that are clearly precursors or
legally required ingredients to the end product. These writings are also included in the
notion of a legislative resource, but in this case it is not easy to give straightforward rules for
deciding whether they are, or are not to be considered legislative resources. Different
jurisdictions will have different theories on this subject.
The notion of a legal resource is potentially very wide in scope: it includes at least sources of
law and legislative resources. It also includes all writings that create a legally recognized fact. All writings required in a court procedure, in legislating, or in exercising a(nother)
declarative or proclamative power (granting permits, taking administrative decisions, civil
marriage ceremonies, etc.) are potentially legal resources, as well as writings required for
compliance with duties to inform (tax application forms, etc.).
Legal Subjects, Legal Actions, and Legal Competence
There are several closely related common methods for describing a legal order: classification
of legal subjects, classification of legal objects, and classification of legal norms.
Classification of legal subjects starts from the group of intentional agents that constitute the
legal order, and classifies them by their roles in the legal order. Relevant differentiae are the
kinds of actions these agents can engage in, the legal consequences that these actions have,
and the ways in which they are liable or privileged towards other agents (i.e. what other
agents can do to them). A related notion is that of jurisdiction over the person: for each source
of law we can ask ourselves which group of agents it applies to.
The classification of legal objects identifies which behaviours (for instance those involving
driving a vehicle, those involving sales transactions) and matters (for instance the design of
ships) are the object of the law. This is related to the (unfortunately named) subject-matter
jurisdiction.
The legal norm does one of three things: it directs behaviour, by way of a prohibition or an
obligation, it allows behaviour, or it attributes the legal competence (power, potestative right)
to bring about certain legal consequences. It has three components: a description of the
intended addressees (those to whom the norm applies: derived from German normadressat),
a description of the subject matter (the legal object: a behaviour of the addressee or some
matter that can be brought about by the addressee), and a legal qualification of the subject
matter (for instance as a prohibition, obligation, permission, or attribution of a competence, or
more complex patterns involving these). The CEN Workshop will not attempt to define a final
jurisdiction-independent theory of any of these components.
Legal subjects are at least natural persons and legal persons. Legal persons are entities with
legal personality (for instance a limited company, or a municipality). Entities with legal
personality generally speaking act though agents representing them, since they cannot act by
themselves. There are also legal subjects that are neither natural persons nor legal persons.
A criminal organization for instance typically has no legal personality, but can be held
responsible for its behaviour. A constituting part of a legal person can in some cases also be
a legal subject without personality. Other special legal subjects, like the parliament, may also
be excluded from legal personality based on the assumption that their existence precedes the
present legal order but it has a role in bringing it about.
The kinds of legal action we are interested in are usually performed by public legal subjects:
organizations dedicated to some public interest. We also distinguish public persons, or
persons brought about by public law, public bodies, their constituting parts, public offices, that
are held by a natural person for a specific period, as well as any auxiliary public legal subject
that does not belong to any other class.
The object of interest to the legal order is the behaviour of legal subjects. Part of this
behaviour consists of actions. An action is an intentional behaviour in the sense that it occurs
because the legal subject has the intention to bring some effect about. This doesn’t mean that
the action cannot have unintentional effects: I may want to pick up a glass, but instead
unintentionally knock it over. In this case I unintentionally knocked over the glass, but acted
with another intention, i.e. to pick it up.
Of special interest for the CEN standard are actions that only public legal entities can engage
in that are relevant to the production of sources of law, and public competences used in the
process. The notion of competence is important for two reasons:
• In the discussion of legal subjects it is often unclear whether one is talking about the
(natural) person itself or the role he fills at the moment of acting. The minister is
competent to produce ministerial guidelines, but the person filling this office can only
use the competence when acting in his capacity as minister, and loses the
competence when he stops being minister. The minister has decided to grant a
pardon to illegal immigrants and the minister has decided to divorce his wife are
fundamentally different actions: in the first case he is acting as minister (the office),
uses a public competence, and creates legal consequences, while in the second case
he is a natural person making a decision. If the law states that the minister sets
restrictions additional to this law on some subject matter, it should be clear that the
competence attributed here remains with the office of minister and not with the person filling the office at the moment of enacting the relevant law. The agent acting
is in this standard obviously always the office holder if such ambiguity exists. The
office may however hold competences of a different character. The minister may hold
the competence to create internal guidelines for his employees, the competence to
create ministerial directives on specific types of legal object, and the competence to
make limited changes in formal law that can otherwise only be changed by parliament
(for instance indexing tax law for inflation). It should be clear which competence he
was exercising.
• In most jurisdictions the fact that a certain directive was based on a competence
attributed in a certain source of law is relevant to deciding:
o the relative priority of the directive in the legal system in case of apparent
conflict with other directives;
o the addressees;
o the exact scope of the subject matter;
o the potential legal consequences of violation.
Provided that we take the position that the user will not generally question the validity of a
legal action on a source of law, some subset of {action, agent, competence} is usually
sufficient to store metadata about the lifecycle and position of legislation.
3.4 Separating Content and Metadata
A guiding principle of the workshop is that content is described by XML Schema8
, and
metadata by the Resource Description Framework (RDF)9
. XML Schema refers to an
accessible world consisting of XML data structures that can (usually) be retrieved in some
way, and RDF to an in principle inaccessible one consisting of things out there that can only
be referred to by way of a symbol that functions as a mental substitute for the thing itself.
XML schema uses the same symbols – uniform resource identifiers – as RDF. The
fundamental difference is that the URI is used in XML schema is used to attach identifiers to
XML data structures in order for software to refer to XML data structures, and in RDF to refer
to things in a usually inaccessible domain of reference out there that are described by way of
XML data structures.
A set {a, b, c} in a knowledge representation language could be a representation of the three legs of a specific barstool out there, in which case a, b, c are only identifiers for real
things that are inaccessible. But in some cases a knowledge representation language like
RDF does indeed refer to things that are accessible, or the distinction between the real thing
and the description of the thing is immaterial. This is for instance the case with fully abstract
notions like a mathematical set. There is no material difference between the set {a, b, c}
and the model theoretic representation {a, b, c} of this set, since this mathematical set
only exists by virtue of the fact that it is being described. Something similar is the case with
documents: for most purposes there is no material difference between the accessible XML
structure and the document. Only when one considers issues like how many copies of the
document are around one starts noting a material difference. It has therefore become a
convention that the XML data structure referred to by a URI is a manifestation of the
document, and not some description of it.
Compare the following two XML statements:
8
http://www.w3.org/XML/Schema
9
http://www.w3.org/RDF/
1. Alexander Boer
2. A
lexander Boer
The first one is an XML element defined in some XML schema with a URI identity marker
http://www.metalex.eu/people.xml#aboer. It identifies the XML element
Alexander Boer, and not its value Alexander Boer or the fact that the
value is a name, or its carrier a person. The second statement is RDF, and encodes a (rather
trivial) statement about the thing referred to by the identity marker
http://www.metalex.eu/people.xml#aboer, being Alexander
Boer.
This difference in interpretation cannot be inferred from the XML but is a difference in the
semantics of basic XML (specifically xml:base and xml:id) and RDF. The interface
between metadata and the XML structure consists of these shared URIs. The XML structure
is what the URI refers to, and in RDF you describe the thing referred to by the URI. Obviously
it is possible to describe everything, including the structure, contained text blocks, references,
etc. in RDF.
The big question of course is which part of this RDF data belongs to the standard. The kind of
entities in the XML document structure are often classified as follows:
Form
A law can be recognized by certain required phrases and formulas. These formal
requirements usually come from the constitution, administrative law, and guidelines
on legislative drafting. The formal requirements are influenced mostly by
considerations of consistency of language, ease of access for the reader, and giving
cues to the reader to help him position the document in relation to activities of public
bodies. The formal structure of the document provides a context for the interpretation
of the content of the document. For other legal resources, the structure may be less
formal and in the end only ordinary text structure elements may be applicable (e.g.
chapters, sections, paragraphs and sentences).
Role
Although we may look at the phrases and formulas in a written decision to classify a
document as a law, we know that it is not the structure of the document that makes it
a law, but the role the document plays in the activities of public bodies – most
importantly the activities that produced the document. This is often called metad data in
the narrow sense: it is not in the document, but describes the relation between the
document and its environment. The date of publication of a document is an example.
Content
Knowledge representation for knowledge-based systems and knowledge
management is concerned with the question what the text contained in the document
(interpreted in the context of form and role of the document) means for our activities.
Is it a source of constraints on your activities, or maybe an instrument for predicting
other people’s behaviour towards you, or making other people do desirable things for
you, or does it give you the right to do things you would otherwise not be allowed to
do?
Role is usually strictly considered to be in the domain of metadata, while content is
considered the domain of knowledge representation languages. This distinction between role
and content makes complete sense if you consider for instance a medical textbook: its
content is completely unrelated to contextual information describing its role in activities
involving the book like its publisher, author, date of publication, the schools that use it, etc.
There is no problem with using different standards for both.
In law this is different, and this is the main reason that more general standards often don’t
seem to apply to law. The content of one source of law may be the context in which the other
source of law is interpreted. A simple example is the modification of a source of law Sin
pursuant to a directive to modify it in the modifying source of law Strans, resulting in a modified
source of law Sout. We can conceptualize this as an action producing Sout, using Sin and Strans
as an instrument.
Alternatively we can conceptualize it as a process working on the normative system: Strans
causes a state transition from Sin to Sout. Let Strans state that at Ttrans, Sin will be replaced in the
normative system by Sout. Firstly, observe that the modification is achieved by Strans using the
same legislative instruments for working other effects: either by a directive or by a declaration.
If the legislator uses a directive, then it is possible (for some editor, or for the addressees who
have to make the modification for themselves) to violate it by not making the modification. If
the legislator declares it, it happens automatically as a delayed effect of the action of the
legislator.
The transforming action therefore breaks down the distinction between role and content. Also
observe that Ttrans – the timepoint at which the modification goes into effect – is context, and
therefore metadata, of Sin and Sout, but part of the content of Strans. Ttrans is therefore a property
of Sin (opening the time interval in which it exists) and Sout (closing the time interval in which it
exists), and is therefore described by the XML structures of Sin and Sout. The actual source of
T
trans is however Strans, and a change in Strans (before its one-shot execution) also changes
the metadata of Sin and Sout: for maintenance purposes it is therefore much more convenient
to keep the triple {Strans, Sin, Sout} together, and it is only natural to explicitly organize them by
their thematic roles in a description of the action itself. Hence the focus on actions.
This applies to all activities pertaining to the lifecycle of a source of law. This also applies to
all activities undertaken based on the competence to act attributed, or delegated, or
subdelegated, by a source of law. Attribution, delegation, and subdelegation of the
competence to legislate are themselves activities subject to explicit regulation. Another
example is the notion of applicability: (parts of) legislative documents may also set conditions
on the applicability of other (parts of) legislative documents.
Most of the specifically legal classifications we would otherwise be tempted to use as a
descriptive name of XML elements on law, or as a property of such an element, turn out to be
roles of the involved bibliographic entities is actions, in business processes, etc.
The CEN standard strips bibliographic entities used in law from their role. The content models
are very generic, but at the same time also slightly different from presentation-oriented
content models (XHTML, etc.) etc. in their choice of granularity. It focuses on the structure
that is relevant to and intended by the legislator, and not the editor of the specific
manifestation of the text we are looking at.
3.5 Content Models instead of Elements
A MetaLex XML element is characterized by a name, a content model, and zero or more
attributes.
According to the philosophy of descriptive markup (cf. [1]), the name of an XML element is
usually semantically-charged (i.e. it provides a hint as to the meaning of the text fragment, or
its role within the whole of the document). Additional information about the content of the
element (e.g. explanatory, parametric, collateral data) goes into attributes. The content model
is an algebraic expression of the elements that may (or must) be found in the content of the
element.
Generic elements, on the other hand, are named after the content model: they are merely a
label identifying the kind of content model. Generic elements can be reused in different
situations but they provide no description of their content and role. It is possible to add
specific attributes providing hints as to their meaning and role.
All XML vocabularies contain a mix of descriptive and generic elements, and, depending on
the foreseen uses of the documents, emphasize one of the approaches. For instance,
vocabularies with precise procedural semantics (e.g. XSLT, SVG) do not depend on generic
elements, while vocabularies intended for diverse content (for instance XHTML) employ
generic elements. Consider for instance that in XHTML 2.0 both and elements
are being replaced or phased out in favour of generic substitutes using attributes.
Current validation languages (e.g., XML Schema) do not allow validation rules to be
associated to attribute values, so element names are currently the only way to associate
validation rules to documents. This is a cause of pollution of principles, forcing semanticallycharged elements to assume a rigid content model, while generic elements take care of odd
situations that where not foreseen when the content models where designed.
Legislative documents are in a strange position with regard to standards. On the one hand,
legislative drafting technique has a long tradition, and often its own standards of what
legislative documents should look like. This makes descriptive markup combined with strict
content models very tempting. On the other hand, there are so many exceptions that can be
found in concrete examples throughout the legislative history of the average state that we
sometimes just want to give up on precise description altogether and resort to incredibly
generic elements, in particular because there should be not one iota of difference between
the original expression of the legislator and the XML manifestation of that expression.
If we are too normative we end up preventing the markup of a possibly large range of
documents, especially legacy documents. On the other hand, giving up on description of
elements we end up preventing the analysis of the content of legislative documents, and
permitting a chaotic and anarchist approach to legal document management that will prevent
any further application of sophisticated automated assistance.
To further add to the complexity of this issue we have the problem of multilingualism, that
guarantees that perfectly descriptive and appropriate element names in the language that the
proposed vocabulary is supposed to cater to are incomprehensible gibberish in all others.
The approach of the workshop is to provide for a complete and automatic interchangeability of
approaches, from generic to descriptive and vice versa. While locally an editorial staff can
enjoy the precision and naturalness of descriptive markup catering to a specific jurisdiction
and language, other users can obtain full and immediately understandable results using
another vocabulary.
This can be achieved by using two special attributes, name and type that provide information
about the meaning and the content model of the element. The values for these attributes can
be freely used as names for the elements. The name of the element must be identical to the
either the value of the attribute name or the value of the attribute type.
This approach is different from the language extensions (implemented using substitution
groups) of legacy MetaLex (1.3.1 and before): no central registry of extensions is necessary.
The MetaLex standard is based on a very limited set of content models. All elements having
the same content model must have the same value of the type attribute. For content model
there is a generic element with the same name.
Suppose for instance that we have an element with the name clause and the content model
container. The following elements are equivalent from the point of view of the standard:
1.
…
2. …
3. …
4. …
If either one of the two basic attributes is missing, the name of the element produces the
missing value.
4 Content Models and Attributes (normative)
4.1 Scope
This section is about the level of granularity of identification of the structure of legal and
legislative resources. The choice of a level of granularity should first and foremost make
unambiguous reference of text fragments possible. Secondly, it should allow the identification
of semantically coherent text fragments. Thirdly, the assignment of elements to text fragments
should be unambiguous: the same text should be marked up the same by different encoders.
Fourthly, it should make reproducing layout effects possible.
4.2 Namespace
MetaLex/CEN is the MetaLex norm agreed upon in the CEN Workshop Agreement. The
name MetaLex/CEN distinguishes the CEN/ISSS proposal from earlier versions of the
MetaLex schema. The namespace of MetaLex/CEN is:
http://www.metalex.eu/20061206/namespace. The names of elements and attributes in this
document are unqualified wherever ambiguity about namespaces does not exist. If ambiguity
could arise, the namespace of MetaLex is referred to by the qualified namespace metalex:
4.3 Attributes
Attributes give meaning to elements. Meaning in terms of semantics, roles, additional
information, metadata. This means than any element with any name, as long as it has the
correct set of attributes, can be placed in the document. This assures that conformance,
validity and interchange is based on attributes alone, and not element names.
Attribute names are fixed and required, element names are subject to localization, of both
language and jurisdiction.
The attributes are the following:
name
a semantically-charged name that identifies in a human-understandable way the
purpose and meaning and role of the element. This attribute is required for generic
elements, and optional for descriptive elements (but if present it must coincide with
the element name).
type
the name of one of the (few) content models approved for use in this schema. Of
course, the content model of the element must also be coherent with the content
model specified in the type attribute. Furthermore, this attribute is required for
descriptive elements, and optional for generic elements (but if present it must
coincide with the element name).
id
an unique id that identifies that element among all of the document. The syntax of the
value of the id attribute depends on the numbering attribute. All elements in the
document must have such an id except for globally and locally unique ones (where
they are optional).
xhtml:class
the name of a style class that can be found in a presentation package. Optional
attribute for all elements.
xhtml:style
a collection of (CSS) styles that need to be associated to the current element only.
Optional attribute for all elements.
date
all elements containing or referring to a date or a moment in time must provide a
normalized value for that date, conformant to the subset of ISO 860110 used in the
XML Schema language, that can be used regardless of understandability of the
element’s name or the ambiguity of the shown value.
4.3.1 Metadata attributes
For metadata, RDFa will be used (which is consistent with [2]). This leads to the following
attributes:
about
the subject (URI reference to an entity) of an RDFa statement;
property
the predicate of an RDFa statement whose object is a literal value;
rel
the predicate of an RDFa statement whose object is a URI reference to another
entity;
href
the object URI reference to another entity of an RDFa statement;
content
the literal value that is the object of an RDFa statement.
The only thing left is the showAs: we need a label for both the predicate and the object at
least. Labels are useful for applications that want to show the user a description of a relation
and target that is understandable (and not a URI or QName derived from a URI).
The XML schema of MetaLex/CEN is the normative source on the use of attributes, and the
values allowed.
4.3.2 xml:base
It must be possible to establish the base of an element, in conformance with the XML Base
11specification and IETF RFC 239612http://www.ietf.org/rfc/rfc2396.txt. The string concatenation
base+’#’+id should result in a valid URI, conformant to the addressing recommendations13
of W3C.
The easiest way to achieve this requirement is to always add an xml:base attribute in scope
of the element. The xml:base is in scope if it is on the element itself, or on one of its
ancestors.
4.4 Content Models
All content models are constrained to just 10 different abstract complex types, of which 5
fundamental (the patterns) and 5 specialized for specific purposes. Three more complex types are added for creating the hierarchy of derivation, but cannot be used for anything but
derivation. These are called ur types.
4.4.1 Ur Types
The three basic types of which all others are derived are:
urType
which specifies the basic attributes for all our elements;
10 http://www.w3.org/TR/NOTE-datetime
11 http://www.w3.org/TR/xmlbase/
12 http://www.ietf.org/rfc/rfc2396.txt
13 http://www.w3.org/Addressing/
urContentType
for the elements that contain content; and
urMetaType
for the elements that become metadata.
These types only distribute the correct attributes to the actual content models. All names of
these abstract types are prefixed with ur, to signal their abstractness. Abstractness in this
context means that they cannot be (directly) instantiated.
4.5 Presentation
The MetaLex schema provides no predefined support for presentation. Document publishers
may provide hints as to how the document should be presented. Similarly to the use of CSS
styles in HTML, this happens through the use of three different and complementary solutions:
element names, element classes and element styles.
Element names
Usually presentation is associated to element names. Since we have two issues in
MetaLex that affect element names, analogously we expect presentation agents to
provide support for both approaches. That is to say, for descriptive elements all CSS
styles or XSLT templates may be associated to either elements whose name is X, or
whose name attribute is X. Analogously, for elements whose name is not known, a
default behavior may be provided associated to the type, so default presentation
must be associated to elements whose name is equal to the type and the value
attribute is not known. Presentation engines will usually create their own instructions
for such elements.
Element classes
special presentation rules may be provided for all elements whose attribute class has
a certain value. This is similar to what is done in HTML/CSS: usually the presentation
rule is used for a number of similarly classed elements, and possibly in a number of
different documents. For these reasons, the presentation instructions are usually
external (i.e., stored in a separate document) and accessed similarly by all
documents that use the same set of classes. Presentation engines may use such
instructions, but they may also ignore them and replace them with their others, or no
presentation instructions at all.
Element styles
individual elements could require once-only presentation rules, to reproduce atypical
layout decisions in the source document. In this case it is inappropriate to use a
shared stylesheet, and the style may be used to store the presentation instruction
within the element. It is strongly recommended that presentation engines use style
instructions, but they may also ignore them.
4.6 Conformance of Elements to the Standard
To conform to the standard you may use generic elements defined by the standard. You may
also create new elements conforming to the standard.
4.6.1 Defined Elements
To create an element conforming to the st andard that can be used in XML manifestations of
sources of law, define a non-abstract complex type, and create an element belonging to the
substitution group of one of the abstract elements according to the subtype specified, as
follows:
The process of creating the concrete vocabulary of elements therefore works as follows:
1. You must use one of the abstract content models provided for your element;
2. You may define a restriction of the corresponding concrete type;
3. You may not define an extension to the content model of a concrete type;
4. You may define an extension of a concrete type for adding attributes;
5. You must define the elements as a substitution group of one of the abstract elements
and you must identify a type which is either one of the provided concrete types, or the restriction of the content model or extension of attributes of a concrete type that
you have defined.
5 References (normative)
This section is to be normative. It was struck on the meeting of December 6 2006. The text for
this section will be added on a later date, either in a new version of this document or in a
separate extension document, and resubmitted to the workshop.
6 Metadata (normative)
MetaLex metadata can be used to generate RDF triples. Entities are identified using URI.
Statements about entities are interpreted as subject, predicate, object triples. This
section decribes what counts as a MetaLex metadata statement, how it is stored inside a
MetaLex document, and what classes of entities and which predicates (properties) MetaLex
distinguishes.
Part of the Metalex standard is an OWL14 schema. The namespace of the first schema is:
http://www.metalex.eu/classes/20061115/metalex-cen.owl#
The namespace of the latest schema is: http://www.metalex.eu/classes/latest/metalexcen.owl#
The schema is not the object of the agreement of December 6 2006.
6.1 Scope
The MetaLex OWL schema defines:
bibliographic entities
content models, work, expression, manifestation, and item, and combinations of a
content model and bibliographic entity;
citation
reference between bibliographic entities;
activities
actions and thematic links, and thematic roles of bibliographic entities in at least the
actions creation, enactment, repeal;
agent and competence
the generic superclasses of jurisdiction-specific legislators and legislative
competences.
The description of classes in the MetaLex OWL schema is to be normative. The standard also
precribes a method for embedding metadata directly in MetaLex.
6.2 The Resource Description Framework
The Resource Description Framework (RDF)15 is a language for representing information
about resources in the World Wide Web. RDF is based on the idea of identifying things using
Uniform Resource Identifiers, or URIs, and describing resources in terms of simple
properties and property values. The URI identifies things, classes of things, properties of
things, and values of those properties. This enables RDF to represent simple statements
about resources as a graph of nodes and arcs representing the resources, and their
properties and values. RDF statements can be used by an RDF processor to generate RDF
14 http://www.w3.org/2004/OWL/
15 http://www.w3.org/TR/rdf-primer/
triples. RDF is well-supported by existing tools and server software like Aduna Autofocus and
Metadata Server, TopBraid Composer, Protégé, SemanticWorks, etc.
An RDF statement has the following parts:
subject
the thing the statement describes;
predicate
a specific property;
object
the thing the statement says is the value of the property, for the thing the statement
describes.
Refer to the RDF W3C Recommendation16 for more information about using RDF. RDF
SChema introduces the notion of the RDF Class. Resources may be classified into classes.
The members of a class are known as instances of the class. Classes are themselves
resources. They are identified by URI and may be described using properties, etc. The
rdf:type property may be used to state that a resource is an instance of a class. Web
Ontology Language (OWL)17 is an extension to RDF Schema that allows precise definition of
valid instances of a class (similar to the relation between content models and the XML
schema). We will refer to an RDF class defined in OWL as an OWL class.
All MetaLex metadata statements can be used to generate RDF triples. Any method of storing
RDF statements may be used to store MetaLex metadata. A MetaLex metadata statement is
a statement that has as its type a MetaLex class, or as its subject, predicate, or instance a
MetaLex class or an instance of a MetaLex class. MetaLex classes are defined in an OWL
schema.
6.2.1 Embedded Metadata: Elements and Attributes
MetaLex metalex:meta, and other elements derived from the metalex:urMetaType
type, are carriers of RDFa18 attributes, and are therefore RDFa statements. All elements
derived are also RDFa statements, but do note that the element name meta has a special
significance to RDFa processors, just like the name link. MetaLex metalex:meta elements
are used to embed metadata that can also be stored in the form of RDF in RDF documents;
RDF triples can be generated from RDFa statements. RDFa statements may be added to any MetaLex element if the content model allows it.
RDFa does not have its own namespace: the significance of XML elements and attributes to
RDFa processors is determined entirely by names. All URI references in attributes may be
relative to the the xml:base of the element. The object must be a URI: this is a restriction of
RDFa syntax19
.
An RDFa element is defined as any XML element that contains one or more RDFa attributes:
1. about,
2. property,
3. rel,
4. href,
5. content.
16 http://www.w3.org/2001/sw/RDFCore/
17 http://www.w3.org/TR/owl-features/
18 http://en.wikipedia.org/wiki/RDFa
19 http://www.w3.org/2001/sw/BestPractices/HTML/2005-rdfa-syntax
Processing proceeds by examining each RDFa element in turn. The RDFa element under
consideration at any time is the current statement, and its parent element is the context
statement. Note that the context statement does not need to be an RDFa element. RDFa also
includes a datatype attribute, that can be used to restrict the XML datatype of a literal object.
The presence of that attribute does not by itself designate an RDFa element.
The RDFa processor generates RDF triples from RDFa elements. There is exactly one triple
generated per rel or property attribute. RDFa also support a third mechanism using the
attribute rev. Thus, an RDFa element can generate at most 3 RDF triples, disregarding RDF’s
reification mechanism, one for each of those three attributes.
The predicate of a statement is specified using a property or rel attribute. A property
attribute indicates a new statement whose predicate is the value of that attribute. The subject
of the triple is decided using subject resolution. The object of the triple is decided using literal
object resolution. A rel attribute indicates a new statement whose predicate is the value of
that attribute. The subject of the triple will be decided using subject resolution. The object of
the triple is decided using URI reference object resolution.
The subject of a triple is usually indicated using the about attribute. If the RDFa element that
includes the predicate attribute does not have an about attribute, then the subject of the triple
is determined by about attribute of the first ancestor element that has an about attribute.
If an RDFa statement is generated by a predicate attribute of a meta or link element, and this
element does not contain an explicit about attribute, subject resolution is slightly different.
Only the immediate context statement is considered, regardless of whether or not it has its
own about attribute.
If the context statement is an element named meta or link itself, the RDFa statement
represented by the context statement is reified as the subject of this new RDFa statement. If
the context statement is named neither meta nor link, two cases should be considered. The
context statement may have an about attribute, in which case the RDFa statement’s subject
is resolved as the value of this attribute (exactly as if the current RDFa statement weren’t a
link or meta). However, if the context statement does not have an about attribute, the subject
of the current RDFa statement is the (URI of the) parent element itself. In the case of the default metalex:meta element, this is generally its containing metalex:mcontainer (or
metalex:absTmcontainer type) element. This is not the case for other elements derived
from the metalex:UrMetaType type: the special semantics are in this case strictly linked to
the name of the element.
The object of the statement can be set using one of the attributes content or href. If the
predicate was set using property then the object will be a literal, and its value will come from
the content attribute or the element content. The metalex:absTmeta type elemen may not
however contain element content. Without a datatype attribute, the object literal will either be
a plain literal or an XML literal, depending on whether the content attribute or element
content is used. The metalex:absTmeta type element may therefore only be used for plain
literal and datatyped values. If the predicate was set with the rel attribute, then the object will
be a URI whose value is obtained from the href attribute.
You may not use an attribute with the name rev on elements derived from any metalex type.
6.3 Events and Actions
The MetaLex OWL Schema defines a general framework for describing events and actions.
The basic categories are:
• Event
• Action
• Transaction
Each of these have participants in certain roles. MetaLex uses a classification in terms of
thematic role. The thematic role20 is the semantic relationship between a verb and an
argument (the noun phrases) of a sentence. It is important to realize that thematic roles are
based on linguistic criteria, and do not offer an ontologically sound criterium for classifying
entities. The classification is therefore somewhat arbitrary, but easy to remember and use.
In the CEN Workshop Agreement we propose to use a simple categorization of thematic roles
loosely based on Judith Dick’s (1991) representation of legal arguments (see also John
Sowa’s website21). Each occurrent has one or more participants (properties) that are either:
Immanent or determinant
a determinant participant determines direction, while an immanent participant is
passively present throughout.
Source or product
20 http://en.wikipedia.org/wiki/Thematic_role
21 http://www.jfsowa.com/ontology/thematic.htm
a source must be present at the beginning, but need not participate throughout, while
a product must be present at the end but need not participate throughout.
For event and action we recognize the following participants:
agent
is determinant and source of the action; a person or some organised group of
persons; only actions have an agent;
instrument
is immanent and source of the action, and is not changed during the action;
patient
is immanent and product of the action, and undergoes some structural change as a
result of the action; at the level of bibliographic entities this applies to the work;
recipient
is determinant and product of the action: the person towards whom the action was
directed; in the case of sources of law this is usually the addressee; only transactions
have a recipient;
result
is determinant and product of the action: a thing that was created by the action; at the
level of bibliographic entities this can apply only to the expression;
date
is immanent and product of the action: when it happened, which is in the domain of
legislation always a date.
The initial agreement covers three generic actions:
Creation
a bibliographic entity (result) is created by an author (agent), at a date. It is not
relevant whether the text is a verbatim copy or a modification on an earlier text by
another author: the identity of bibliographic entities does not depend on its content.
When a bibliographic entity is created, its parts are also created, but the parts can be
independently modified, resulting in a new creation. The expression of which an
element is the manifestation cannot be created before a containing expression
Enactment
The action of an agent with the competence (instrument) to enact by which an
expression enters into force. The trigger be the more or less autonomous execution
of an enactment provision (instrument) created by the agent before. The agent
responsible for the enactment provision can still be considered to be acting.
Repeal
The action of an agent with the competence (instrument) to repeal by which an
expression goes out of force. May be the more or less autonomous execution of an
repeal provision (instrument) created by the agent.
6.4 Conformance to the Standard
Any RDF statement may be made about a MetaLex entity. The definition of a MetaLex OWL
class may not be extended by any means, but only restricted. It is recommended to at least
embed information about the work and expression the XML structure is a manifestation of, the
author of the work, official designations (titles or other means for citation) for the work, and
publication, enactment, and repeal information. It is strongly recommended to refrain from
defining new OWL classes if a suitable MetaLex class already exists.
7 Extensions (informative)
These XML schema files are not normative.
An XML schema file providing MetaLex/CEN substitutions for MetaLex 1.3.1 (deprecated by
the CEN Workshop Agreement22) elements can be found at: not available yet
An XML schema file providing MetaLex/CEN substitutions for Akoma Ntoso23 elements can
be found at: http://svn.leibnizcenter.org/svn/MetaLexWS/branches/latest/akomantosoadapter-test.xsd (SVN path)
These examples demonstrate that files marked up in existing XML standards can mostly be
made conformant to MetaLex, provided that these standards allow the use of attributes from
the MetaLex/CEN namespace.
8 Schema
MetaLex/CEN is specified in an XML schema file. This XML schema forms a normative part of
this specification. The normative XML schema for content models can be found at: not
available yet. The XML schema file has been generated from a DTD++ file, which can be
found at: not available yet. Because the schema is generated from the DTD++ file,
conformance to the DTD++ file is considered an adequate alternative for conformance to the
XML schema file. The latest proposed XML schema for content models can be found at:
http://svn.leibnizcenter.org/svn/MetaLexWS/branches/latest/metalex.xsd (SVN path). The
XML schema file has been generated from a DTD++ file, which can be found at: not
available yet.
The latest proposed XML schema for references can be found at: not available yet. The XML
schema file has been generated from a DTD++ file, which can be found at: not available yet.
The normative OWL schema can be found at: not available yet. The latest proposed OWL
schema can be found at:
http://svn.leibnizcenter.org/svn/MetaLexWS/branches/latest/metalex-cen.owl (SVN path)
Retrieved from
http://www.metalex.eu/wiki/index.php/Workshop_Agreement_adopted_on_December_6_2006
22 http://svn.leibnizcenter.org/svn/MetaLexWS/branches/1.3.1/
23 http://www.akomantoso.org/
Source: Retrieved from
http://www.metalex.eu/wiki/index.php/Workshop_Agreement_adopted_on_December_6_2006
22 http://svn.leibnizcenter.org/svn/MetaLexWS/branches/1.3.1/
23 http://www.akomantoso.org/
Source: CEN Workshop on Open XML interchange format for legal documents – (WS/METALEX)
………………………….
Description of Legislation
For purposes of representation we distinguish three different viewpoints on the meaning of legal documents:
Form A legal document can usually be ‘recognized’ and classified by certain phrases and formulas. Formal
requirements on structure and phrasing mostly reflect considerations of consistency of language and
ease of access 6 for the reader, but it also provides a context for the interpretation of the content of the
document. This latter role is very specific for jurisdiction and timeframe and in many cases cannot be
part of the MetaLex schema. Structural requirements are defined in XML schemas where appropriate.
Role Although we may look at the phrases and formulas in a written decision to classify a document as a law,
we know that it is not the structure of the document that makes it a law, but the role the document plays
in the activities of public persons and bodies – most importantly the activities that produced the document.
Information about the document of this nature is captured in RDF statements ‘about’ the document.
Content
We also classify documents depending on what its content means: It represents a type of decision. If it
is just a public decision its meaning is limited to a particular occurrence or case. If it is a norm or policy
its meaning extends to general class of occurrences or cases and it postulates a value theory for making and judging decisions. This is captured in RDF statements ‘about’ this content: relating acts, norms ,
agents to (parts of) the document.
The MetaLex schema distinguishes publications and organic documents, and facilitates the connection of organic
documents (the latest version, for instance) to semi-permanent universal resource identifier (URI), similar to the
way in which the W3C makes its standard documents and schemata available. Most web sites that publish legislation
for free fail to qualify which version they offer. To make a correct citation to a part of an organic regulation identified
by a URI is still not trivial; index symbols usually suggest an ordinal relation between indices, but there is
no way to determine the size of the interval between for instance articles I and IV. A citation of the ‘second article’
is therefore not the same as a citation of ‘article 2’ because ‘article 1bis’ may be inserted later. 7
The importance of capturing the identity criteria for regulations is also made apparent by considering the requirements
for maintenance of a collection of organic regulations in time. Changes in laws are announced in separate decisions
and publishers must keep track of all documents from certain publication channels to be able to reconstruct what
the form of an organic regulation is at some time point. Similarly, if you find a written administrative decision on
your doormat its status changes when a new written decision retracting it follows two days later.
To keep track of versions MetaLex provides a number of attributes for every structural XML element in the document
that can be identified, selected, and thus changed; the date-publication of an element is the time the element is
officially published or announced. The date-enacted, the time the content becomes applicable in decision making,
is always later than or the same as date-publication, but before date-repealed, the time the content becomes inapplicable
in decisionmaking. Between date-enacted and date-repealed the element and its content is active, and
outside this interval it is inactive. Table Table 1 can be used to deduce active time intervals from the presence or
absence of these attributes. The date-version attribute represents the date the correctness of the content and other
dates of the XML element was last verified. The XML document looses its value as a normative reference as time
progresses and the time-interval between date-version and today increases.
date-publication date-enacted date-repealed active
???4. Jurisdiction and Language
To achieve independence of jurisdiction MetaLex has been limited to common requirements of structure, reference,
and identity. Specific legal jargon has been avoided as much as possible to reduce confusion between descriptive
and prescriptive use of concepts. The guidelines for legislative drafting (“Aanwijzingen voor Regelgeving”) in the
Netherlands for instance states that a ‘part’ (‘deel’) in a regulation consists of chapters, while a ‘section’ (‘afdeling’)
consists of paragraphs, articles, or one article indexed ‘only article’ (‘enig artikel’). Copying this vocabulary in
Dutch law for groupings of articles would suggest that such constraints apply, and make it impossible to translate
even trivial element names for chapter, section, paragraph (‘paragraaf’; always has a title in Dutch, because otherwise
it is obviously an ‘alinea’).
The jurisdiction-neutral vocabulary is specified in a simple descriptive English, so that it will be easy to map more
specific names to it. Chapter, section, part, paragraph, title, book as description for layered groupings of articles
are thus all translated to MetaLex element ‘part’, which groups one or more parts or articles.
The MetaLex standard supports multi-lingual documents in two distinct ways: through localization of XML elements
and by providing the means to maintain multiple language versions of the same document in one file.
Leave a Reply