[OASIS Issue Tracker] (LEGALRULEML-11) XSLT for Phase I conversion from LegalRuleML to RDF

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

Tara Athan created LEGALRULEML-11:
-------------------------------------

             Summary: XSLT for Phase I conversion from LegalRuleML to RDF
                 Key: LEGALRULEML-11
                 URL: https://issues.oasis-open.org/browse/LEGALRULEML-11
             Project: OASIS LegalRuleML TC
          Issue Type: New Feature
          Components: XSLT for conversion to RDF
            Reporter: Tara Athan


Phase I of transformation from LegalRuleML to RDF.

This stylesheet generates valid RDF/XML if the input meets the preconditions (later).
     There is no loss or ambiguity of information except:
     1. Attributes other than @index on edge elements with child or text content will be ignored. This is the desired behavior- ideally, the normalization transformation will not generate such attributes.
     2. In Phase I, RDF collections are not utilized for closing the membership of the LegalRuleML collections. This is intended to be accomplished in a second phase of the XSLT. The information is retained by making a negation-as-failure entailment on the RDF graph with respect to collection membership.
     3. The case of a Node element having a keyref attribute as well as other attributes or content is worked-around by transforming this to a "derivedFrom" child. In the case when properties are not functional, the assertions from the original and the explicit assertions in the clone are merged monotonically.
   In the case where properties are functional, such a merger would lead to inconsistency. For example, a ruleml:content property for ruleml:Time is functional. If we keyreference another ruleml:Time and also have a ruleml:content child, then this should be interpreted as asserting the explicit ruleml:content property *instead of* the ruleml:content property of the original ruleml:Time. Therefore the consequences of a ruleml:derivedFrom property may be non-monotonic, and these consequences must be either determined in a third phase of the XSLT and incorporated into the final RDF output, or the assertion must be treated as an XML Literal.



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)