Homepage of the open source development of a multi-lingual and multi-jurisdictional RDF Dictionary for the legal world

hosted by Lexml logo and SourceForge Logo

Sourceforge summary of the RDF Dictionary project

Latest version of the RDF Dictionary (not at the sourceforge site, as the ftp resource for some reason does not function yet. You may however browse the CVS repository on the sourceforge site. Take "dictionary", not "rdfictionary". I have been trying to remove "rdfdictionary" and its empty subdirectories, without succes sofar; help!?))

To take part in the general discussion you may subscribe to the mailinglist hosted by LEXM.nl. If you wish to belong to the community of actual developers, you should register with Sourceforge and apply to be added as a developer at rdfdictionary. You are recommended to then also subscribe to the developers mailinglist.

The starting document is "archetypes" in the file "vocabulary". The file "dtd" contains several DTD examples. These examples are linked to the archetypes by the documents in the file "interfaces". In the file "xlinkhubdocs" it is described what interfaces refer to each particular archetype, for instance which interfaces refer to the archetype "enforceable". The file "documents" contains several example application documents, marked up according to the example DTD`s. The file "stylesheets" contains stylesheets to support the output of example documents.

The mapping of a term like "judgement" appearing in a particular document  to, for instance, the German jurisdiction occurs as follows: 

  1. establish the DTD/Schema of the document (Doctype!)
  2. establish the interface of the DTD/Schema at the RDF Dictionary
  3. establish which interfaces have linked German DTD´s/Schemas to the same archetypes (xlink hub document!)
  4. establish the German term which has the same archetypes (if not all, show which differ)

The mapping capability is therefor provided by each DTD or Schema being added to the Dictionary, by defining an interface for that DTD/Schema. A dynamic process, instead of defining once and for all how a term maps from one jurisdiction and language to another. At this point most logic for automated translation can be handled by XSLT. The larger the corpus gets, the larger the need for other tools, like a database and a programming language, will be.

Path of development

I see as the (simultaneous) steps to be taken on basis of the first draft of the RDF Dictionary:

MM 31.5.2001