LegalHTML FAQ
In a world of multiple representation formats (e.g. think of content-negotation in linked open data), why developing a model centralizing structure, semantics and representation into a single document?
Well, the first answer, while being a tad provocative, summarizes everything into another question: "why not using a document format to represent...documents?". The many XML-based formats for representation of legal content are basically representing documents using a data-oriented syntax.
LegalHTML reverses the approach making it right: it uses a document format (HTML) and extends it (exploiting methods provided by HTML itself, so well within the standard) with additional information for representing the specific structure of legal documents. Semantics can then be added through different - again, standard - solutions for Web content such as embedded RDF and RDFa annotations.
So, while other legal document formats either are missing the information that is necessary for representation needs (thus requiring other documents for this aspect, which are hard to keep aligned with the XML one) or try to reinvent the wheel by defining a set of elements covering minimal representation needs (which are never as rich as HTML), LegalHTML guarantees the possibility to have a single master document keeping the information related to all of its aspects perfectly in sync.
Ok, but..does it mean that other formats and data sources should not be used? Absolutely not: LegalHTML documents can then be easily exported to other legal formats (e.g. Akoma Ntoso) or presentation formats (e.g. PDF). Furthermore, all of the data and metadata within the document, being natively represented in RDF, can be extracted through tools and services (e.g. those listed in RDFa tools) just following semantic standards and exported to semantic repositories as-is, without any need of elaborated and dedicated conversion procedures.