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

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

    [ https://issues.oasis-open.org/browse/LEGALRULEML-11?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=61196#comment-61196 ] 

Tara Athan commented on LEGALRULEML-11:
---------------------------------------

The attribute values that are in the form of a CURIE with empty prefix, i.e. start with ":", are (correctly) not evaluated during the preprocessing XSLT when there is no explicit prefix mapping for the empty prefix. However, these should be processed when converting to the RDF into same-document relative IRIs; that is, the leading ":" is replaced with "#".

> 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 or @xml:id 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.
> Input Preconditions
>   1. All CURIES have been processed into absolute IRIs
>      (e.g. using xslt as in https://apache.googlesource.com/stanbol/+/9b61625545e2ba6b903ea0752dcd20656bada822/enhancer/engines/xmpextractor/src/main/resources/xslt/rdfa.xslt)
>   2. The document is in the normalized form (e.g. after applying an XSLT normalizer.) 



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