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: [legalruleml] LegalRuleML-TC-2012-07-11v1.doc (97K) Minutes


Hi Adrian,
I can add in the next TC minutes your comment as an integration. No problem.
In the text my comments.
Yours,
mp

Il 25/07/2012 21:39, Adrian Paschke ha scritto:
Hi,

I just read the minutes.

Adrian propose three kind of attributes like in Reaction Rule: key, iri, node with different meaning. This for taking also in consideration the >computational side effect on the Xpaht manipulation.
My remarks were not about computational side effects and XPath manipulation. My issues are:

1. The semantics of xs:key-xs:keyref and node are different. To distinguish both RuleML 1.0 and Reaction RuleML 1.0 replaced the old <oid> element which was used for both. The attribute “node” replaced the <oid> element in RuleML 1.0 and is intended for a RDF like “about” description. “xs:key-keyref” attributes, as used in Reaction RuleML, is used for modularization of a distributed knowledge base in order to refer between corresponding elements in a modular knowledge base. While “node” does not follow a unique name assumption, xs:key ensures a unique identifier and additionally can validate the correctness of references using a standard XML validator. The semantics of both should not be mixed as this would violate referential transparency.
1. you use three different annotations for expressing the same semantical concept (iri, node, key) you are making a difference depending to the location of the sources. This choice make your annotation depending to the physical files organization. Under my point of view the real thing that we need is to preserve the semantic references to the legal resources (legal resources like official gazette XML files, etc.) that are independent by the physical files, but they are based on the FRBR model. In such way I can change in the future the physical organization of the files and the rules will continue to work well.
2. xs:key as well as other XML identifier (id-idref) only work on one XML instance, but not on multiple different XML instance. Reaction RuleML uses XIncludes for including distributed instances into one XML instance.
2. If I have different authorities in charge of the legal rules, divided for their legal competences, I CAN'T, under the legal point of view, include files in a unique one, especially if the files are signed with digital signature from the authorities for fixing trustiness, provenience and legality.
3. If we additionally introduce XSLT as a kind of “pre-processor” before Legal RuleML documents can be processed/validated by standard XML validators, we introduce an additional mandatory tool layer - an XSLT transformation pre-processor, which has many drawbacks.
3. any reasoner need to use a mid-layer for processing the rules, so Drools for instance could make this check internally.

I hope to have provided more element for our discussion.
Cheers,

Adrian

---------------------------------------------------------------------
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-mailmonica.palmirani@unibo.it ====================================



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