Re: Defeasibility example

[Tara Athan <taraathan@gmail.com>]

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.

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"

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.


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

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.

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
&this;#rule_1a      Legal Rule