jsonld-java should probably deal with it although Jena can.
What about xsd:string?
Should that be skipped as well?
Andy
On 13/04/16 23:44, François-Paul Servant wrote:
However, this change would impact the output of existing applications, and
could break clients relying on the keys as they are produced today. So I don’t
know what Jena team will want to do.
fps
Le 14 avr. 2016 à 00:30, François-Paul Servant <[email protected]>
a écrit :
Hi,
I had opened an issue on jsonld-java:
https://github.com/jsonld-java/jsonld-java/issues/170
but I closed it, because it turns out that the problem is within jena (see
comments about the issue for an explanation), class JsonLDWriter, around line
150:
} else if ( o.isLiteral() ) {
String literalDatatypeURI = o.getLiteralDatatypeURI() ;
if ( literalDatatypeURI != null ) {
// add property as a typed attribute (the object is a
// typed literal)
Map<String, Object> x2 = new LinkedHashMap<>() ;
x2.put("@id", p.getURI()) ;
// Not setting the @type with literalDatatypeURI solves the problem
// At least, don’t do it when it is langString
if
(!RDF.langString.getURI().equals(literalDatatypeURI)) {
x2.put("@type", literalDatatypeURI) ;
}
ctx.put(x, x2) ;
} else {
// add property as an untyped attribute (the object is
// an untyped literal)
ctx.put(x, p.getURI()) ;
}
Best,
fps
