OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

legalruleml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: Defeasibility example

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

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


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


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


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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]