[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [legalruleml] Re: Defeasibility example
|
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.*** 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 *** 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"
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*** 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" ***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, 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> *** Textual _expression_ not Manifestation at least in Akoma Ntoso, better to say Textual Provision &this;#rule_1a Legal Rule -- =================================== 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 ====================================
Questa informativa è inserita in automatico dal sistema al fine esclusivo della realizzazione dei fini istituzionali dell’ente. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]