Many thanks to Tara for the great work. Some more information that I hope could help the common understanding. About Akoma Ntoso URI: Some fragment of text coming from Fabio Vitali co-chair of LegalDocML and co-author of the Akoma Ntoso URI naming convention. About other URI naming convention in Legal Domain: Some examples from Monica. About the RDF representation: some comments from Monica. Cheers mp Il 09/07/2012 23:57, Tara Athan ha scritto: I have learned something new (to me) about the textual provision markup that will be referenced in LegalRuleML in order to define sources. A. Background: 1. URIs (from
http://tools.ietf.org/html/rfc3986 ) 4.1 URI-reference = URI / relative-ref A URI-reference is either a URI or a relative reference. If the URI-reference's prefix does not match the syntax of a scheme followed by its colon separator, then the URI-reference is a relative reference. *** Fabio and I support the thesis, shared with other in the Web Technology Community, that our naming convention is perfectly in line with the
http://tools.ietf.org/html/rfc3986 specifications. An URI-reference is an URI OR a relative-ref by definition. "4.1: URI-reference = URI / relative-ref" A relative-ref is a relative-part plus optionally query and fragment "4.2. Relative Reference A relative reference takes advantage of the hierarchical syntax (Section 1.2.3) to express a URI reference relative to the name space of another hierarchical URI. relative-ref = relative-part [ "?" query ] [ "#" fragment ] relative-part = "//" authority path-abempty / path-absolute / path-noscheme / path-empty The URI referred to by a relative reference, also known as the target URI, is obtained by applying the reference resolution algorithm of Section 5. A relative reference that begins with two slash characters is termed a network-path reference; such references are rarely used. A relative reference that begins with a single slash character is termed an absolute-path reference. A relative reference that does not begin with a slash character is termed a relative-path reference." In Akoma Ntoso we have: - the name of the legal resources in the block FRBR are URI like
http://www.resolver.it/path-absolute where the
http://www.resolver.it/ depends from the application layer (section 5) - the name of the legal resources linked to external references (normative references) are path-absolute 2. Akoma Ntoso identifiers (from
http://akn.web.cs.unibo.it/ and
https://www.oasis-open.org/apps/org/workgroup/legaldocml/email/archives/201207/msg00000.html ) Akomo Ntoso uses identifiers that are in the form of "absolute path relative URI references". An example is "/au/2012-05-30/C628:2012/eng@/main.xml" *** this is the MANIFESTATION "absolute path relative URI references" but we are using in the Akoma Ntoso normative links WORK or _expression_ for implementing dynamic link (dynamic navigation to the more updated version) or static link (dynamic navigation to a specific version in time: /au/2012-05-30/C628:2012/eng@/main#sec2.2" this is a static link to the sec2.2 original version; /au/2012-05-30/C628:2012/eng@2012-05-31/main#sec2.2" this is a static link to the sec2.2 version 2012 ). In the rules we would like to point to the _expression_ "absolute path relative URI references" because it is possible to detect in the net all the different manifestations available in the web concerning the same legal document (same I means under the legal point of view: e.g. Senate, Chamber and Gazette publish the same text equally legally valid). Some document are available in different format respect XML (e.g. html). So the correct URI (under the Akoma Ntoso perspective) to use in the rules is: "/au/2012-05-30/C628:2012/eng@correctVersion/main#sec2.2" In terms of AN this is considered a persistent identifier. However it is not a URI. According to W3C specifications, a relative URI reference is resolved to a URI by using the "base URI". One way to specify the base URI is to give it explicitly through an xml:base attribute, such as <... xml:base= "http://example.org/xyz/abc" > Then if the identifier "/au/2012-05-30/C628:2012/eng@/main.xml" was used within scope of this base URI, it would be resolved to "http://example.org/au/2012-05-30/C628:2012/eng@/main.xml" However, AN does not use the xml:base attribute. The W3C specifies in that case that the base URI is not specified by an xml:base attribute, then the base URI would be taken from other information in a hierarchical process (
http://tools.ietf.org/html/rfc3986#section-5.1 ). It could use the retrieval URI. In general, there are multiple servers that serve as mirrors for such files, so the URI would be resolved differently depending on which server it was obtained from. Further, the XML might not have been retrieved, as it might have been generated by software. The final fallback is a Default Base URI that is application dependent. Akoma Ntoso does not provide such a Default Base URI. Therefore neither "/au/2012-05-30/C628:2012/eng@/main.xml" nor any reasonable resolution of that string to a URI can be used directly as a persistent URI to identify the sources of a LegalRuleML rule. *** From Fabio email to the LegalDocML TC, 03/07/2012
https://lists.oasis-open.org/archives/legaldocml/201207/msg00000.html "I will try to provide an answer to the doubts expressed by Roger and Flavio. First of al, let me point out the obvious fact that an Akoma Ntoso document is an XML document, and as such is not immediately accessible through a browser. The most obvious use of an XML document is through one or more tools that provide context-dependent functional steps, for instance for rendering and semantics. For instance, the most obvious way to display an XML document is via an XSLT stylesheet that is often not specified in the document itself, but provided by the context. More generally we have the XML document, which is and should be context-independent (i.e., it should NOT contain information about the specific architecture and tools that are needed to make use of them, lest we restrict ourselves to these specific architecture and tools and limit the useful lifespan of the document), AND we also have many specific tools, such as document servers, URI resolvers, XSLT stylesheets, etc., that provide the specific context for a successful and interesting use of this document. THESE TOOLS are the ones that need to take care of handling the context-specific tasks for the use of the document, whose details may change over time because of advancements in the technology. <recap of URI theory, skip it if you are bored> In the terminology introduced by RFC 3986, "URI Generic Syntax",
http://tools.ietf.org/html/rfc3986 , an Akoma Ntoso URI is an "absolute path relative URI" (section 4.2). Given the similarity of this term with absolute URI (section 4.3), which is a completely different thing, it was decided long ago to keep the "absolute URI" as in 4.3, and rephrase "absolute path relative URI" as a "global URI" Let me give you a few examples: 1)
http://www.site.com/path1/path2/path3#fragment is an http-based absolute URI 2) urn:lex:part1:part2:part3:fragment is a urn-based absolute URI 3) /path1/path2/path3#fragment is (in RFC 3986) an absolute path relative URI reference, or (in AN) a global URI 4) path2/path3#fragment is (in RFC 3986) a relative path relative URI reference, or (in AN) a relative URI 5) #fragment is (in RFC 3986) a same-document URI reference, or (in AN) a local URI Of these types of addresses, the http-based absolute URI is the only that is (potentially) usable by the browser to access the document, a process called dereferencing. All other addresses require an intermediate step, called resolution, meant to generate the corresponding http-based absolute URI from the given address. The resolution process is basically identical in all cases. yet, please note that even http-based absolute URIs may require a resolution process, e.g., whenever they do not specify the physical address of the requested resource, as in our case, because legal references are usually to abstract (Work-level or _expression_-level) conceptualizations of a document, and almost never to (Item-level) physical files. But regardless of whether they represent the physical address of the resource or the address of the engine that provides the resolution, http-based absolute URIs DO CONTAIN parts that provide information about architecture and/or tools needed to resolve them, and as such provide a strong constraint to the generality and useful lifespan of the address. On the other hand, ALL the other URI do not contain architecture-dependent information, and can survive arbitrarily radical modification in the tools provided to access them. This is, in my point of view, absolutely good. </recap> I would be strongly against using http-based absolute URIs for Akoma Ntoso, as this would imply providing a specific resolution engine and blessing for all time as the only one allowed to provide an interpretation of the actual meaning of the URI. This is not the right way to provide long-lasting, multi-national solutions to these problems. For different reasons, I would be strongly against using urn-based absolute URIs, as we would gain nothing in terms of flexibility and generality, and would loose much in terms of usability and compatibility of the addresses. I believe that the only reasonable choice is to go with global URIs, that have the same characteristics as http-based absolute URIs except the address of the resolution engine, that needs to be provided from the context of use. As Roger mentioned during the call, this leaves an open issue as to where to place the missing context-dependent bits, e.g., the domain name of the resolution engine, since they are necessary to make the system work, yet are impermanent and may change over time and jurisdictions and even personal tastes. The answer, as I tried to explain, has to be found in the context of use: this is never empty. Even in situations where we have no document server, where the XML document has been transmitted as an attachment via mail, or found in a USB thumbdrive, the context-dependent set of tools is never empty: at the very least there must be an XSLT stylesheet to convert AKoma Ntoso into aX(HTML). This is where the domain name of the resolution engine, as well as any additional information regarding the context of use of the document, need to reside. Putting this kind of information in the document is wrong and temporally restricting. Putting ONE additional line in the XSLT stylesheet, as follows: <xsl:template match="akomaNtoso"> <html> <head> <base href= class= moz-txt-link-rfc2396E href=
http://www.resolution.com/ >"http://www.resolution.com/" /> ... </head> <body> ... </body> </html> </xsl:template> is more than adequate for the task and does NOT pollute the XML file with context-dependent information. I hope this satisfies you all. Ciao Fabio" B. Impact for LegalRuleML Because LegalRuleML must accept the syntax of the textual provision markup as is, we therefore need a way of representing a source that has an identifier that is not a URI. However, we would need to also specify the identifier system so it could be properly interpreted. (I do not know if there are other syntaxes for textual provision markup that also use non-URI identifiers, but it is certainly possible that new ones could be introduced in the future.) By considering an RDF representation of this information, we can examine the issue independent of the LegalRuleML syntax that would be used to represent it. I will use the NTriple syntax because it is very clear as to what is a URI and what is a literal. There is one triple per line, URIs are enclosed in <>, blank nodes start with _:, and data literals are enclosed in "". If the reference was to a URI we could use a set of 4 triples with 1 blank node. (I use XML entites to represent the as yet unknown parts of the URIs. This is not strictly correct NTriple syntax.) First, all text/rule links can be considered to be members of a named collection of source/target pairs, and then this collection of pairs forms the "sources" portion of the context (&this;#ruleInfo1). <&this;#ruleInfo1> <&lrml;sources> <&this;#sourceBlock1> <&this;#sourceBlock1> <&lrml;member> _:1 _:1 <&lrml;target> <&this;#rule_1a> _:1 <&lrml;source> <http://example.org/xyz> However, with the non-URI Akoma Ntoso identifier we must use a different approach, such as ***From Monica: This method to name and to refer to legal resource, so called by Tara "non-URI", is quite used in by several Legal XML schemas over the world, so it is really a requirement of LegalRuleML to manage it: - Metalex/CEN ( ftp://ftp.cen.eu/CEN/Sectors/List/ICT/CWAs/CWA15710-2010-Metalex2.pdf ) - URN naming convention for legal resources in Europe (
http://www.ietf.org/id/draft-spinosa-urn-lex-06.txt ) - in Italy, NormeInRete
http://www.digitpa.gov.it/standard-normeinrete - in the COUNCIL OF THE EUROPEAN UNION with the ELI naming convention
http://legalinformatics.files.wordpress.com/2012/03/st17554-en11.pdf - the Official Gazette in Europe use this URI format OJ:C:2011:127:0001:0007:EN:PDF the link is made by application side because the documen is a PDF. It is
http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:C:2011:127:0001:0007:EN:PDF - ECLI naming convention for accessing to the Case-Law: ECLI:country:court:year:number - US GPO (Government Print Office)
http://frwebgate.access.gpo.gov/cgi-bin/getdoc.cgi?dbname=browse_usc&docid=Cite:+18USC47 - FindLaw URI -
http://codes.lp.findlaw.com/uscode/18/I/3/47 - Cornell University LII
http://www.law.cornell.edu/wiki/lexcraft/section_identifiers_lii etc. This for saying that LegalRuleML should to manage all the plurality of naming convention in the market: URI, non-URI, semi-URI, Option 1. <&this;#ruleInfo1> <&lrml;sources> <&this;#sourceBlock1> <&this;#sourceBlock1> <&lrml;member> _:1 _:1 <&lrml;target> <&this;#rule_1a> _:1 <&lrml;source> _:2 _:2 <&lrml;akomaNtoso2.0-2011-10ID> "/au/2012-05-30/C628:2012/eng@/main.xml" This option is not so good because if a new release of Akoma Ntoso comes out, then the LegalRuleML syntax becomes out of date. Further if a new syntax for textual provisions comes out which also uses non-URI identifiers, then the LegalRuleML syntax also becomes out of date. Option 2. <&this;#ruleInfo1> <&lrml;sources> <&this;#sourceBlock1> <&this;#sourceBlock1> <&lrml;member> _:1 _:1 <&lrml;target> <&this;#rule_1a> _:1 <&lrml;source> _:2 _:2 <&lrml;sourceID> "/au/2012-05-30/C628:2012/eng@/main.xml" _:2 <&lrml;sourceType> "AkomaNtoso2.0-2011-10" This is less dependent on modifications to AkomaNtoso or the release of new syntaxes, but still the content model for the object of the last triple cannot be enumerated without risking obsolesence, and so it would have to have a content model of xs:string. From our point of view the sourceID is a pointer to an ID representing a fragment of the document /au/2012-05-30/C628:2012/eng@/main.xml#sec2.2 Secondary we would like to maintain in a unique place all the "so called non-URI" of the legal resources for not duplicate them in the rules: Subject - predicate - object <&this;#ruleInfo1> <&lrml;sources> <&this;#sourceBlock1> <&this;#sourceBlock1> <&lrml;member> _:1 _:1 <&lrml;target> <&this;#rule_1a> _:1 <&lrml;source> _:2 _:2 <&lrml;sourceID> <&this;#referenceID> _:2 <&lrml;sourceType> "AkomaNtoso2.0-2011-10" Only one time we have this RDF assertion: <&this;#referenceID> <&lrml;legalText> <&resolver;/au/2012-05-30/C628:2012/eng@/main#sec2.2> It may be beneficial to maintaining a clear picture if we develop informal "types" (in the sense of "rdfs:Class") for the entities referenced here. For example: URI or bnode Type &this;#ruleInfo1 Context &this;#sourceBlock1 Collection _:1 Source/Target Pair _:2 Textual Manifestation *** Textual _expression_ not Manifestation at least in Akoma Ntoso, better to say Textual Provision &this;#rule_1a Legal Rule --------------------------------------------------------------------- To unsubscribe, e-mail:
legalruleml-unsubscribe@lists.oasis-open.org For additional commands, e-mail:
legalruleml-help@lists.oasis-open.org . -- =================================== Associate professor of Legal Informatics School of Law Alma Mater Studiorum Università di Bologna C.I.R.S.F.I.D.
http://www.cirsfid.unibo.it/ Palazzo Dal Monte Gaudenzi - Via Galliera, 3 I - 40121 BOLOGNA (ITALY) Tel +39 051 277217 Fax +39 051 260782 E-mail
monica.palmirani@unibo.it ==================================== LA RICERCA C’È E SI VEDE: 5 per mille all'Università di Bologna - C.F.: 80007010376
http://www.unibo.it/5permille Questa informativa è inserita in automatico dal sistema al fine esclusivo della realizzazione dei fini istituzionali dell’ente.