Hello Andy

Le lun. 22 avr. 2024 à 21:03, Andy Seaborne <[email protected]> a écrit :

>
> On 22/04/2024 08:02, Thomas Francart wrote:
> > Hello
> >
> > This is 3.17.0. Pretty old, due to other dependency with TopQuadrant
> SHACL
> > API.
>
> It's not perfect in 5.0.0 either.
>
> TopQuadrant SHACL is now 4.10.0. It would be good to upgrade because of
> XML security issue fixes around Jena 4.3.2.
>
>
> It is being rejected because it is not legal RDF 1.0. At 1.0, the
> lexical space had restrictions (XML exclusive canonicalization) where
> <symbol/> is not allowed. It has to be <symbol></symbol> -- there are
> various other rules as well.
>

Thank you, I wasn't aware of this.


>
> (The DOM wasn't standardized at the time of RDF 1.0 IIRC)
>
> The definition of rdf:XMLLiteral changed at RDF 1.1 to one where any XML
> document fragment string is valid.
>
> Seems not all places got updated. Partially, that is because it was
> depending on the specific implementation of the Jena RDF/XML parser.
>
> https://github.com/apache/jena/issues/2430
>
>
> Do you happen to have the SPARQL queries? That part of your report is
> related to the value space of RDF XML Literals.
>

Yes, the query is using the "=" operator :

ask {
  ?uri a <http://exemple.com/MyClass> .
  ?uri <http://exemple.com/MyProperty> ?x, ?y.
  filter (?x != ?y)
}

But then using the sameTerm function we don't get the error:

ask {
  ?uri a <http://exemple.com/MyClass> .
  ?uri <http://exemple.com/MyProperty> ?x, ?y.
  FILTER ( !sameTerm(?x, ?y) )
}


>
> A proper update to RDF 1.1 may change the value object class (it is
> "string" for RDF 1.0, it is, by the spec, DocumentFragment for RDF 1.1;
> it could be kept at document fragment toString() in jena. I'd like to
> understand the usage to see which change is best).
>
>      Andy
>
> BTW It's rdf:parseType="Literal" -- Jena 5.0.0 is not tolerant of lower
> case "literal"
>

Thanks !

Thomas


>
> >
> > Thomas
> >
> > Le sam. 20 avr. 2024 à 18:06, Andy Seaborne <[email protected]> a écrit :
> >
> >> Hi Thomas,
> >>
> >> Which version of Jena is this?
> >>
> >>       Andy
> >>
> >> On 19/04/2024 17:18, Thomas Francart wrote:
> >>> Hello
> >>>
> >>> The RDF/XML parsing of the following succeeds:
> >>>
> >>> <rdf:Description>
> >>>
> >>> <epvoc:decisionAboutId rdf:parseType="literal"><am><reference><symbol
> >> href="
> >>> https://xx.xx.xx/PC"/></reference></am></epvoc:decisionAboutId>
> >>>
> >>> </rdf:Description>
> >>>
> >>> while the RDF/XML parsing of this gives an error : in that case the XML
> >> has
> >>> simply be encoded with &lt, and &gt; and the rdf:datatype has been
> >>> explicitly set to XMLLiteral :
> >>>
> >>> <rdf:Description>
> >>>
> >>> <epvoc:decisionAboutId rdf:datatype="
> >>> http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral
> >> ">&lt;am&gt;&lt;reference&gt;&lt;symbol
> >>> href="https://xx.xx.xx/PC
> >>> "/&gt;&lt;/reference&gt;&lt;/am&gt;</epvoc:decisionAboutId>
> >>>
> >>> </rdf:Description>
> >>>
> >>>
> >>> The error is
> >>>
> >>> 13:08:04.742 WARN  org.apache.jena.riot - Lexical form
> >>> '<am><reference><symbol href="https://xx.xx.xx/PC"/></reference></am>'
> >> not
> >>> valid for datatype XSD XMLLiteral
> >>>
> >>> and then further down in SPARQL queries:
> >>>
> >>> 13:08:04.775 WARN  o.apache.jena.sparql.expr.NodeValue - Datatype
> format
> >>> exception: "<am><reference><symbol href=\"https://xx.xx.xx/PC\
> >>> "/></reference></am>"^^rdf:XMLLiteral
> >>>
> >>> The encoded XML is however valid.
> >>>
> >>> Is it possible to explicitely create literals with XMLLiteral datatype
> in
> >>> RDF/XML by setting this datatype explicitely ?
> >>>
> >>> Thanks
> >>> Thomas
> >>>
> >>>
> >>
> >
> >
>


-- 

*Thomas Francart* -* SPARNA*
Web de *données* | Architecture de l'*information* | Accès aux
*connaissances*
blog : blog.sparna.fr, site : sparna.fr, linkedin :
fr.linkedin.com/in/thomasfrancart
tel :  +33 (0)6.71.11.25.97, skype : francartthomas

Reply via email to