You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jena.apache.org by François-Paul Servant <fr...@gmail.com> on 2016/04/14 00:30:49 UTC
small problem in the way jena generates the context for jsonld-java
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
Re: small problem in the way jena generates the context for jsonld-java
Posted by François-Paul Servant <fr...@gmail.com>.
Well, this JSON-LD doesn't really break - at least, I didn't see it (and
the JSON-LD playground doesn't complain in any way).
I think that this shows that it is important to give jena's user control
over the context that is passed to jsonld-java (at this time, it is
generated automatically by jena): if he were able to decide the context
that get passed, he could be sure that this kind of change wouldn't impact
the data that he produces. And that gives him free choice about the output:
for instance, he may want to use prefixed form for properties (eg. ex:p) in
some cases, and this is not possible right now.
fps
2016-04-14 12:56 GMT+02:00 Andy Seaborne <an...@apache.org>:
> On 14/04/16 10:55, François-Paul Servant wrote:
>
>> Andy,
>>
>> jsonld-java should probably deal with it although Jena can.
>>>
>>
>> I'm not sure jsonld-java should deal with it:Jena passes the context to
>> jsonld-java, more precisely to a method that takes a jsonld-java object as
>> argument (it is not a text input, but a json-ld java object: they may
>> expect that it is correct).
>>
>> here is a test to see what happens, depending on the literal. Look in the
>> output whether the keys are short or long. To answer your second question
>> xsd:string exhibits the same problem
>>
>> @Test public final void testLiteralVal() {
>> Model m = ModelFactory.createDefaultModel();
>> String ns = "http://www.a.com/foo/";
>> Resource s = m.createResource(ns + "s");
>> m.add(s,m.createProperty(ns + "plangstring"),"a langstring","fr");
>> m.add(s, m.createProperty(ns + "pint"), m.createTypedLiteral(42));
>> m.add(s, m.createProperty(ns + "pfloat"),
>> m.createTypedLiteral((float)
>> 1789.14));
>> m.add(s, m.createProperty(ns + "pdate"), m.createTypedLiteral(new
>> Date()));
>> m.add(s, m.createProperty(ns + "pstring"), m.createTypedLiteral("a
>> TypedLiteral atring"));
>> RDFDataMgr.write(System.out, m, RDFFormat.JSONLD) ;
>> }
>>
>> 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.
>>
>> I insist on this: if you make such a change, (I hope you will), you will
>> probably break the code of some client users. Of course, that will not
>> happen with client code that handles the output as RDF. But for those who
>> handles it as JSON...
>>
>> The kind of problems that people who produces/uses RDF only do not have
>> ;-)
>>
>
> It is right to worry about such changes.
>
> IMO It's not so bad in this case : the change is for rdf:langString making
> the output right for further JSON_LD processing. In that sense, it's a bug.
>
> For xsd:string, the RDF 1.1 spec advises outputting the plain form so this
> is again a bug fix, in a weaker sense.
>
> People who rely on the exact appearance may be affected but at the moment
> they are getting JSON-LD that breaks elsewhere. And small data changes can
> lead to big output changes due to all the internal hashmaps involved.
>
> Andy
>
> JENA-1163
>
>
>
>> Best,
>>
>> fps
>>
>>
>> 2016-04-14 10:27 GMT+02:00 Andy Seaborne <an...@apache.org>:
>>
>> 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 <
>>>>
>>>>> francoispaulservant@gmail.com> 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
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>
Re: small problem in the way jena generates the context for
jsonld-java
Posted by Andy Seaborne <an...@apache.org>.
On 14/04/16 10:55, François-Paul Servant wrote:
> Andy,
>
>> jsonld-java should probably deal with it although Jena can.
>
> I'm not sure jsonld-java should deal with it:Jena passes the context to
> jsonld-java, more precisely to a method that takes a jsonld-java object as
> argument (it is not a text input, but a json-ld java object: they may
> expect that it is correct).
>
> here is a test to see what happens, depending on the literal. Look in the
> output whether the keys are short or long. To answer your second question
> xsd:string exhibits the same problem
>
> @Test public final void testLiteralVal() {
> Model m = ModelFactory.createDefaultModel();
> String ns = "http://www.a.com/foo/";
> Resource s = m.createResource(ns + "s");
> m.add(s,m.createProperty(ns + "plangstring"),"a langstring","fr");
> m.add(s, m.createProperty(ns + "pint"), m.createTypedLiteral(42));
> m.add(s, m.createProperty(ns + "pfloat"), m.createTypedLiteral((float)
> 1789.14));
> m.add(s, m.createProperty(ns + "pdate"), m.createTypedLiteral(new
> Date()));
> m.add(s, m.createProperty(ns + "pstring"), m.createTypedLiteral("a
> TypedLiteral atring"));
> RDFDataMgr.write(System.out, m, RDFFormat.JSONLD) ;
> }
>
>>> 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.
>
> I insist on this: if you make such a change, (I hope you will), you will
> probably break the code of some client users. Of course, that will not
> happen with client code that handles the output as RDF. But for those who
> handles it as JSON...
>
> The kind of problems that people who produces/uses RDF only do not have ;-)
It is right to worry about such changes.
IMO It's not so bad in this case : the change is for rdf:langString
making the output right for further JSON_LD processing. In that sense,
it's a bug.
For xsd:string, the RDF 1.1 spec advises outputting the plain form so
this is again a bug fix, in a weaker sense.
People who rely on the exact appearance may be affected but at the
moment they are getting JSON-LD that breaks elsewhere. And small data
changes can lead to big output changes due to all the internal hashmaps
involved.
Andy
JENA-1163
>
> Best,
>
> fps
>
>
> 2016-04-14 10:27 GMT+02:00 Andy Seaborne <an...@apache.org>:
>
>> 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 <
>>>> francoispaulservant@gmail.com> 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
>>>>
>>>
>>>
>>
>
Re: small problem in the way jena generates the context for jsonld-java
Posted by François-Paul Servant <fr...@gmail.com>.
Andy,
> jsonld-java should probably deal with it although Jena can.
I'm not sure jsonld-java should deal with it:Jena passes the context to
jsonld-java, more precisely to a method that takes a jsonld-java object as
argument (it is not a text input, but a json-ld java object: they may
expect that it is correct).
here is a test to see what happens, depending on the literal. Look in the
output whether the keys are short or long. To answer your second question
xsd:string exhibits the same problem
@Test public final void testLiteralVal() {
Model m = ModelFactory.createDefaultModel();
String ns = "http://www.a.com/foo/";
Resource s = m.createResource(ns + "s");
m.add(s,m.createProperty(ns + "plangstring"),"a langstring","fr");
m.add(s, m.createProperty(ns + "pint"), m.createTypedLiteral(42));
m.add(s, m.createProperty(ns + "pfloat"), m.createTypedLiteral((float)
1789.14));
m.add(s, m.createProperty(ns + "pdate"), m.createTypedLiteral(new
Date()));
m.add(s, m.createProperty(ns + "pstring"), m.createTypedLiteral("a
TypedLiteral atring"));
RDFDataMgr.write(System.out, m, RDFFormat.JSONLD) ;
}
>> 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.
I insist on this: if you make such a change, (I hope you will), you will
probably break the code of some client users. Of course, that will not
happen with client code that handles the output as RDF. But for those who
handles it as JSON...
The kind of problems that people who produces/uses RDF only do not have ;-)
Best,
fps
2016-04-14 10:27 GMT+02:00 Andy Seaborne <an...@apache.org>:
> 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 <
>>> francoispaulservant@gmail.com> 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
>>>
>>
>>
>
Re: small problem in the way jena generates the context for
jsonld-java
Posted by Andy Seaborne <an...@apache.org>.
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 <fr...@gmail.com> 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
>
Re: small problem in the way jena generates the context for jsonld-java
Posted by François-Paul Servant <fr...@gmail.com>.
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 <fr...@gmail.com> 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