Re: JSON-LD: 1.0 or 1.1
Given the input so far, it seems JSON-LD 1.1 should be the default for both parsing and writing in the next release (Jena 4.5.0). Written JSON-LD would not include a @content entry "@version" - that breaks JSON-LD 1.0 processing. Andy On 11/03/2022 10:38, Andy Seaborne wrote: Jena has both JSON 1.0, provided by jsonld-java, and JSON-LD 1.1, provided by Titanium. What should the default settings be? For parsing that means what is bound to "application/ld+json" and file extension .jsonld. For writing, it means what is setup for Lang.JSONLD. This is two decisions - parsing and writing can be different.
Re: JSON-LD: 1.0 or 1.1
True On Mon, Apr 25, 2022, 5:36 AM Andy Seaborne wrote: > (this isn't a JSON-LD 1.0 vs 1.1 issue) > > On 24/04/2022 18:49, Dan Davis wrote: > > The dependency exists whether it is explicit or not, because the > ecosystem > > of packages that validate JSON documents revolves around JSON Schema, and > > is not as mature for JSON-LD, at least in my limited experience. I > mostly > > lurk here because I maintain https://id.nlm.nih.gov/mesh/, which is > MeSH in > > RDF. Because it is just a representation in RDF, it is not truly Linked > > Data. I keep wanting them to extend it to MEDLINE or link more > > thoroughly to PubChem in RDF, but I am the implementer/maintainer. So, > it > > is on life support. > > > > However, when we worked with the Cedar/BioPortal team it was very clear > > that I would need to use JSON schema packages for Java to validate that a > > JSON document matches JSON-LD. It wasn't only for me a format for > output - > > I needed to be able to validate that my instance was a valid instance > > before submitting it to Cedar in code, because only the Cedar GUI did so. > > > > So, aside from specmanship, I guess my question is how to validate that a > > JSON documented matches JSON-LD for a particular ontology. > > Sounds like you want to validate the RDF triples (SHACLC, ShEx) against > the ontology. It can be more complicated and deeper validation than just > validating the JSON input syntax - it's the triples that matter to MeSH. > Checking the syntax of the input is useful and this isn't an either-or. > Checking errors early can get them fixed more easily. > > Andy > > > On Sun, Apr 24, 2022 at 1:23 PM Andy Seaborne wrote: > > > >> > >> On 24/04/2022 12:05, Dan Brickley wrote: > >>> On Sun, 24 Apr 2022 at 11:12, Andy Seaborne wrote: > >>> > >>>> Hi Dan, > >>>> > >>>> Could you point to this dependency in the specs because I can't find > >>>> mention of JSONschema. > >>>> > >>>> "schema" mentions are schema.org (for examples), XMLSchema (for > >>>> datatypes) and RDF schema for termninology. > >>> > >>> > >>> I (a different Dan) dug around out of curiosity. I could not find a > >> formal > >>> dependency in the W3C standard but there does seem to have been some > >>> communication and collaboration between JSON Schema and JSON-LD teams, > eg > >>> to characterise (subsets of) the former using the latter. > >>> > >>> Dan > >>> > >> > >> Hi danbri, > >> > >> Thanks for the research. That would place the interaction at the > >> writing/framing point of an output pipeline. Sounds interesting; > >> presentation of JSON-LD driven by domain-specific forms is more of a > >> "business logic layer" issue. > >> > >> The Jena default output, as would be experienced from Fuseki, is > >> currently compacted, using prefixes as @context from the RDF data, and > >> has @version added. It is an JSON object, not an array, and carries the > >> information in the RDF data (triples and prefixes/@vocab). i.e. it > >> round-trips. > >> > >> In the trade-off between better presentation, and switching over at the > >> next version, I think delays in switching 1.1 is delayed will slowly > >> becoming more painful and complicated for users to navigate mixed forms. > >> > >> A hybrid JSON 1.1 input with JSON 1.0 output hasn't worked out. > >> > >> Andy > >> > >>>> > >>>> > >>>>Andy > >>>> > >>>> On 23/04/2022 20:21, Dan Davis wrote: > >>>>> It has always bothered me that JSONSchema is not an official standard > >> in > >>>>> the way that XML and RDF/XML are. I know that JSON-LD 1 and 2 are > more > >>>>> standardized under W3C, but they depend so much on JSONSchema. Last > I > >>>>> checked, JSON Schema DRAFT 4 was the closest to a schema. Is the > story > >>>> any > >>>>> better now? > >>>>> > >>>>> On Sat, Apr 23, 2022 at 2:40 PM Paul Tyson > >>>> wrote: > >>>>> > >>>>>> > >>>>>> > >>>>>>> On Apr 23, 2022, at 12:16, Andy Seaborne wrote: > >>>>>>> > >>>>>>> What should the default settings be JSON-LD 1.0 or 1.1? > >>>>>>> > >>>>>> 1.1 would better meet my use cases. > >>>>>> > >>>>>> Thanks, > >>>>>> —Paul > >>>>>> > >>>>>> > >>>>> > >>>> > >>> > >> > > >
Re: JSON-LD: 1.0 or 1.1
(this isn't a JSON-LD 1.0 vs 1.1 issue) On 24/04/2022 18:49, Dan Davis wrote: The dependency exists whether it is explicit or not, because the ecosystem of packages that validate JSON documents revolves around JSON Schema, and is not as mature for JSON-LD, at least in my limited experience. I mostly lurk here because I maintain https://id.nlm.nih.gov/mesh/, which is MeSH in RDF. Because it is just a representation in RDF, it is not truly Linked Data. I keep wanting them to extend it to MEDLINE or link more thoroughly to PubChem in RDF, but I am the implementer/maintainer. So, it is on life support. However, when we worked with the Cedar/BioPortal team it was very clear that I would need to use JSON schema packages for Java to validate that a JSON document matches JSON-LD. It wasn't only for me a format for output - I needed to be able to validate that my instance was a valid instance before submitting it to Cedar in code, because only the Cedar GUI did so. So, aside from specmanship, I guess my question is how to validate that a JSON documented matches JSON-LD for a particular ontology. Sounds like you want to validate the RDF triples (SHACLC, ShEx) against the ontology. It can be more complicated and deeper validation than just validating the JSON input syntax - it's the triples that matter to MeSH. Checking the syntax of the input is useful and this isn't an either-or. Checking errors early can get them fixed more easily. Andy On Sun, Apr 24, 2022 at 1:23 PM Andy Seaborne wrote: On 24/04/2022 12:05, Dan Brickley wrote: On Sun, 24 Apr 2022 at 11:12, Andy Seaborne wrote: Hi Dan, Could you point to this dependency in the specs because I can't find mention of JSONschema. "schema" mentions are schema.org (for examples), XMLSchema (for datatypes) and RDF schema for termninology. I (a different Dan) dug around out of curiosity. I could not find a formal dependency in the W3C standard but there does seem to have been some communication and collaboration between JSON Schema and JSON-LD teams, eg to characterise (subsets of) the former using the latter. Dan Hi danbri, Thanks for the research. That would place the interaction at the writing/framing point of an output pipeline. Sounds interesting; presentation of JSON-LD driven by domain-specific forms is more of a "business logic layer" issue. The Jena default output, as would be experienced from Fuseki, is currently compacted, using prefixes as @context from the RDF data, and has @version added. It is an JSON object, not an array, and carries the information in the RDF data (triples and prefixes/@vocab). i.e. it round-trips. In the trade-off between better presentation, and switching over at the next version, I think delays in switching 1.1 is delayed will slowly becoming more painful and complicated for users to navigate mixed forms. A hybrid JSON 1.1 input with JSON 1.0 output hasn't worked out. Andy Andy On 23/04/2022 20:21, Dan Davis wrote: It has always bothered me that JSONSchema is not an official standard in the way that XML and RDF/XML are. I know that JSON-LD 1 and 2 are more standardized under W3C, but they depend so much on JSONSchema. Last I checked, JSON Schema DRAFT 4 was the closest to a schema. Is the story any better now? On Sat, Apr 23, 2022 at 2:40 PM Paul Tyson wrote: On Apr 23, 2022, at 12:16, Andy Seaborne wrote: What should the default settings be JSON-LD 1.0 or 1.1? 1.1 would better meet my use cases. Thanks, —Paul
Re: JSON-LD: 1.0 or 1.1
The dependency exists whether it is explicit or not, because the ecosystem of packages that validate JSON documents revolves around JSON Schema, and is not as mature for JSON-LD, at least in my limited experience. I mostly lurk here because I maintain https://id.nlm.nih.gov/mesh/, which is MeSH in RDF. Because it is just a representation in RDF, it is not truly Linked Data. I keep wanting them to extend it to MEDLINE or link more thoroughly to PubChem in RDF, but I am the implementer/maintainer. So, it is on life support. However, when we worked with the Cedar/BioPortal team it was very clear that I would need to use JSON schema packages for Java to validate that a JSON document matches JSON-LD. It wasn't only for me a format for output - I needed to be able to validate that my instance was a valid instance before submitting it to Cedar in code, because only the Cedar GUI did so. So, aside from specmanship, I guess my question is how to validate that a JSON documented matches JSON-LD for a particular ontology. On Sun, Apr 24, 2022 at 1:23 PM Andy Seaborne wrote: > > On 24/04/2022 12:05, Dan Brickley wrote: > > On Sun, 24 Apr 2022 at 11:12, Andy Seaborne wrote: > > > >> Hi Dan, > >> > >> Could you point to this dependency in the specs because I can't find > >> mention of JSONschema. > >> > >> "schema" mentions are schema.org (for examples), XMLSchema (for > >> datatypes) and RDF schema for termninology. > > > > > > I (a different Dan) dug around out of curiosity. I could not find a > formal > > dependency in the W3C standard but there does seem to have been some > > communication and collaboration between JSON Schema and JSON-LD teams, eg > > to characterise (subsets of) the former using the latter. > > > > Dan > > > > Hi danbri, > > Thanks for the research. That would place the interaction at the > writing/framing point of an output pipeline. Sounds interesting; > presentation of JSON-LD driven by domain-specific forms is more of a > "business logic layer" issue. > > The Jena default output, as would be experienced from Fuseki, is > currently compacted, using prefixes as @context from the RDF data, and > has @version added. It is an JSON object, not an array, and carries the > information in the RDF data (triples and prefixes/@vocab). i.e. it > round-trips. > > In the trade-off between better presentation, and switching over at the > next version, I think delays in switching 1.1 is delayed will slowly > becoming more painful and complicated for users to navigate mixed forms. > > A hybrid JSON 1.1 input with JSON 1.0 output hasn't worked out. > > Andy > > >> > >> > >> Andy > >> > >> On 23/04/2022 20:21, Dan Davis wrote: > >>> It has always bothered me that JSONSchema is not an official standard > in > >>> the way that XML and RDF/XML are. I know that JSON-LD 1 and 2 are more > >>> standardized under W3C, but they depend so much on JSONSchema. Last I > >>> checked, JSON Schema DRAFT 4 was the closest to a schema. Is the story > >> any > >>> better now? > >>> > >>> On Sat, Apr 23, 2022 at 2:40 PM Paul Tyson > >> wrote: > >>> > >>>> > >>>> > >>>>> On Apr 23, 2022, at 12:16, Andy Seaborne wrote: > >>>>> > >>>>> What should the default settings be JSON-LD 1.0 or 1.1? > >>>>> > >>>> 1.1 would better meet my use cases. > >>>> > >>>> Thanks, > >>>> —Paul > >>>> > >>>> > >>> > >> > > >
Re: JSON-LD: 1.0 or 1.1
On 24/04/2022 12:05, Dan Brickley wrote: On Sun, 24 Apr 2022 at 11:12, Andy Seaborne wrote: Hi Dan, Could you point to this dependency in the specs because I can't find mention of JSONschema. "schema" mentions are schema.org (for examples), XMLSchema (for datatypes) and RDF schema for termninology. I (a different Dan) dug around out of curiosity. I could not find a formal dependency in the W3C standard but there does seem to have been some communication and collaboration between JSON Schema and JSON-LD teams, eg to characterise (subsets of) the former using the latter. Dan Hi danbri, Thanks for the research. That would place the interaction at the writing/framing point of an output pipeline. Sounds interesting; presentation of JSON-LD driven by domain-specific forms is more of a "business logic layer" issue. The Jena default output, as would be experienced from Fuseki, is currently compacted, using prefixes as @context from the RDF data, and has @version added. It is an JSON object, not an array, and carries the information in the RDF data (triples and prefixes/@vocab). i.e. it round-trips. In the trade-off between better presentation, and switching over at the next version, I think delays in switching 1.1 is delayed will slowly becoming more painful and complicated for users to navigate mixed forms. A hybrid JSON 1.1 input with JSON 1.0 output hasn't worked out. Andy Andy On 23/04/2022 20:21, Dan Davis wrote: It has always bothered me that JSONSchema is not an official standard in the way that XML and RDF/XML are. I know that JSON-LD 1 and 2 are more standardized under W3C, but they depend so much on JSONSchema. Last I checked, JSON Schema DRAFT 4 was the closest to a schema. Is the story any better now? On Sat, Apr 23, 2022 at 2:40 PM Paul Tyson wrote: On Apr 23, 2022, at 12:16, Andy Seaborne wrote: What should the default settings be JSON-LD 1.0 or 1.1? 1.1 would better meet my use cases. Thanks, —Paul
Re: JSON-LD: 1.0 or 1.1
On Sun, 24 Apr 2022 at 11:12, Andy Seaborne wrote: > Hi Dan, > > Could you point to this dependency in the specs because I can't find > mention of JSONschema. > > "schema" mentions are schema.org (for examples), XMLSchema (for > datatypes) and RDF schema for termninology. I (a different Dan) dug around out of curiosity. I could not find a formal dependency in the W3C standard but there does seem to have been some communication and collaboration between JSON Schema and JSON-LD teams, eg to characterise (subsets of) the former using the latter. Dan > > > Andy > > On 23/04/2022 20:21, Dan Davis wrote: > > It has always bothered me that JSONSchema is not an official standard in > > the way that XML and RDF/XML are. I know that JSON-LD 1 and 2 are more > > standardized under W3C, but they depend so much on JSONSchema. Last I > > checked, JSON Schema DRAFT 4 was the closest to a schema. Is the story > any > > better now? > > > > On Sat, Apr 23, 2022 at 2:40 PM Paul Tyson > wrote: > > > >> > >> > >>> On Apr 23, 2022, at 12:16, Andy Seaborne wrote: > >>> > >>> What should the default settings be JSON-LD 1.0 or 1.1? > >>> > >> 1.1 would better meet my use cases. > >> > >> Thanks, > >> —Paul > >> > >> > > >
Re: JSON-LD: 1.0 or 1.1
Hi Dan, Could you point to this dependency in the specs because I can't find mention of JSONschema. "schema" mentions are schema.org (for examples), XMLSchema (for datatypes) and RDF schema for termninology. Andy On 23/04/2022 20:21, Dan Davis wrote: It has always bothered me that JSONSchema is not an official standard in the way that XML and RDF/XML are. I know that JSON-LD 1 and 2 are more standardized under W3C, but they depend so much on JSONSchema. Last I checked, JSON Schema DRAFT 4 was the closest to a schema. Is the story any better now? On Sat, Apr 23, 2022 at 2:40 PM Paul Tyson wrote: On Apr 23, 2022, at 12:16, Andy Seaborne wrote: What should the default settings be JSON-LD 1.0 or 1.1? 1.1 would better meet my use cases. Thanks, —Paul
Re: JSON-LD: 1.0 or 1.1
FWIW, 1.1 works better for my use cases which are currently all Linked Art centric. https://linked.art Dave Beaudet On Apr 23, 2022 13:16, Andy Seaborne wrote: What should the default settings be JSON-LD 1.0 or 1.1? It is not a simple choice. There is slightly pretty writing of JSON-LD 1.1 now - prefixes and native types. A new issue is e.g. https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fjena%2Fissues%2F1254data=05%7C01%7C%7Ce588fae0f1d04750bb1a08da254cf794%7C53f6461e95ad4b08a8da973e49ae9312%7C0%7C0%7C637863309768468706%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=z%2F8C6g5neNKttkS6e2ssOpUjH2dlMSLbU8Nwe0Lh314%3Dreserved=0 JSON-LD 1.1 is not completely backwards compatible with JSON-LD 1.0. Current status: There are two JSON-LD subsystems with their own language and format constants as well as terms for the system "JSON-LD" settings. API code can choose which it wishes to use. All the previous features of JSON-LD 1.0 writing are available this way. The decision is what are the defaults for application/ld+json. This affects Fuseki users where where isn't scope to have a switch between 1.0 and 1.1. In issues/1254, the reading client software isn't Jena so the conservative choice of writing 1.0 while reading 1.1 does not really work out. The decision for Jena is when to switch. JSON-LD 1.1 is becoming the norm. It isn't practical to remain at JSON-LD 1.0 indefinitely. I think we're at the point where we ought to switch reading and writing to JSON-LD 1.1 unless we have examples/evidence where this is a problem. Andy >> On Fri, Mar 11, 2022 at 11:39 AM Andy Seaborne wrote: >>> >>> Jena has both JSON 1.0, provided by jsonld-java, and JSON-LD 1.1, >>> provided by Titanium. >>> >>> What should the default settings be? >>> >>> For parsing that means what is bound to "application/ld+json" and file >>> extension .jsonld. >>> >>> For writing, it means what is setup for Lang.JSONLD. >>> >>> This is two decisions - parsing and writing can be different. >>> >>> >>> But. >>> >>> It is not so simple: >>> >>> 1/ For Java11, the default settings for java.net.http can't contact >>> schema.org. This seems to only affect on a few (maybe one) Java 11 build version. The latest Java11 available on Ubuntu works. >>> 2/ Jena is writing JSON-LD 1.1 without much in the way of transformation >>> nor creating a @context from the RDF data. It prints full URIs; numbers >>> aren't abbreviated etc etc. so it not very pretty. There is slightly pretty writing of JSON-LD 1.1 now - prefixes and native types. So there is "plain", no prefixes, no native types (and hence completely faithly RDF), and "pretty" (JSON numbers). Add issue 3: JSON-LD 1.1 is not completely backwards compatible with JSON-LD 1.0. e.g. https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fjena%2Fissues%2F1254data=05%7C01%7C%7Ce588fae0f1d04750bb1a08da254cf794%7C53f6461e95ad4b08a8da973e49ae9312%7C0%7C0%7C637863309768468706%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=z%2F8C6g5neNKttkS6e2ssOpUjH2dlMSLbU8Nwe0Lh314%3Dreserved=0
Re: JSON-LD: 1.0 or 1.1
It has always bothered me that JSONSchema is not an official standard in the way that XML and RDF/XML are. I know that JSON-LD 1 and 2 are more standardized under W3C, but they depend so much on JSONSchema. Last I checked, JSON Schema DRAFT 4 was the closest to a schema. Is the story any better now? On Sat, Apr 23, 2022 at 2:40 PM Paul Tyson wrote: > > > > On Apr 23, 2022, at 12:16, Andy Seaborne wrote: > > > > What should the default settings be JSON-LD 1.0 or 1.1? > > > 1.1 would better meet my use cases. > > Thanks, > —Paul > >
Re: JSON-LD: 1.0 or 1.1
> On Apr 23, 2022, at 12:16, Andy Seaborne wrote: > > What should the default settings be JSON-LD 1.0 or 1.1? > 1.1 would better meet my use cases. Thanks, —Paul
Re: JSON-LD: 1.0 or 1.1
What should the default settings be JSON-LD 1.0 or 1.1? It is not a simple choice. There is slightly pretty writing of JSON-LD 1.1 now - prefixes and native types. A new issue is e.g. https://github.com/apache/jena/issues/1254 JSON-LD 1.1 is not completely backwards compatible with JSON-LD 1.0. Current status: There are two JSON-LD subsystems with their own language and format constants as well as terms for the system "JSON-LD" settings. API code can choose which it wishes to use. All the previous features of JSON-LD 1.0 writing are available this way. The decision is what are the defaults for application/ld+json. This affects Fuseki users where where isn't scope to have a switch between 1.0 and 1.1. In issues/1254, the reading client software isn't Jena so the conservative choice of writing 1.0 while reading 1.1 does not really work out. The decision for Jena is when to switch. JSON-LD 1.1 is becoming the norm. It isn't practical to remain at JSON-LD 1.0 indefinitely. I think we're at the point where we ought to switch reading and writing to JSON-LD 1.1 unless we have examples/evidence where this is a problem. Andy On Fri, Mar 11, 2022 at 11:39 AM Andy Seaborne wrote: Jena has both JSON 1.0, provided by jsonld-java, and JSON-LD 1.1, provided by Titanium. What should the default settings be? For parsing that means what is bound to "application/ld+json" and file extension .jsonld. For writing, it means what is setup for Lang.JSONLD. This is two decisions - parsing and writing can be different. But. It is not so simple: 1/ For Java11, the default settings for java.net.http can't contact schema.org. This seems to only affect on a few (maybe one) Java 11 build version. The latest Java11 available on Ubuntu works. 2/ Jena is writing JSON-LD 1.1 without much in the way of transformation nor creating a @context from the RDF data. It prints full URIs; numbers aren't abbreviated etc etc. so it not very pretty. There is slightly pretty writing of JSON-LD 1.1 now - prefixes and native types. So there is "plain", no prefixes, no native types (and hence completely faithly RDF), and "pretty" (JSON numbers). Add issue 3: JSON-LD 1.1 is not completely backwards compatible with JSON-LD 1.0. e.g. https://github.com/apache/jena/issues/1254
Re: JSON-LD: 1.0 or 1.1
On 15/03/2022 18:13, Martynas Jusevičius wrote:
Hi,
Are the output "flavors" for JSON-LD 1.0 only then?
https://jena.apache.org/documentation/io/rdf-output.html#json-ld
Yes.
On Fri, Mar 11, 2022 at 11:39 AM Andy Seaborne wrote:
Jena has both JSON 1.0, provided by jsonld-java, and JSON-LD 1.1,
provided by Titanium.
What should the default settings be?
For parsing that means what is bound to "application/ld+json" and file
extension .jsonld.
For writing, it means what is setup for Lang.JSONLD.
This is two decisions - parsing and writing can be different.
But.
It is not so simple:
1/ For Java11, the default settings for java.net.http can't contact
schema.org.
This is not a problem with Titanium.
See example code that uses only the plain java.net.http package.
https://issues.apache.org/jira/browse/JENA-2306
HTTP/2 works for java 17.0.2, but does not work for java 11.0.14.
And that means { "@context": "https://schema.org/; } does not work.
(http: redirects to that as well)
This _may_ be:
https://bugs.openjdk.java.net/browse/JDK-8218546
in which case it is fixed in java 11.0.15.
In my testing, it wasn't just google HTTP/2 sites.
** Please try the example code and report the Java version and what happens.
2/ Jena is writing JSON-LD 1.1 without much in the way of transformation
nor creating a @context from the RDF data. It prints full URIs; numbers
aren't abbreviated etc etc. so it not very pretty.
Or should Jena only write some plain output and expect the application
to further transform it?
Even for this, it needs some improvement so that there is a @context to
work from.
** Can you contribute here? The code is in JsonLD11Writer.java.
https://issues.apache.org/jira/browse/JENA-2153
Andy
Re: JSON-LD: 1.0 or 1.1
Hi,
Are the output "flavors" for JSON-LD 1.0 only then?
https://jena.apache.org/documentation/io/rdf-output.html#json-ld
On Fri, Mar 11, 2022 at 11:39 AM Andy Seaborne wrote:
>
> Jena has both JSON 1.0, provided by jsonld-java, and JSON-LD 1.1,
> provided by Titanium.
>
> What should the default settings be?
>
> For parsing that means what is bound to "application/ld+json" and file
> extension .jsonld.
>
> For writing, it means what is setup for Lang.JSONLD.
>
> This is two decisions - parsing and writing can be different.
>
>
> But.
>
> It is not so simple:
>
> 1/ For Java11, the default settings for java.net.http can't contact
> schema.org.
>
> This is not a problem with Titanium.
>
> See example code that uses only the plain java.net.http package.
>
>https://issues.apache.org/jira/browse/JENA-2306
>
> HTTP/2 works for java 17.0.2, but does not work for java 11.0.14.
>
> And that means { "@context": "https://schema.org/; } does not work.
>
> (http: redirects to that as well)
>
> This _may_ be:
> https://bugs.openjdk.java.net/browse/JDK-8218546
>
> in which case it is fixed in java 11.0.15.
>
> In my testing, it wasn't just google HTTP/2 sites.
>
> ** Please try the example code and report the Java version and what happens.
>
> 2/ Jena is writing JSON-LD 1.1 without much in the way of transformation
> nor creating a @context from the RDF data. It prints full URIs; numbers
> aren't abbreviated etc etc. so it not very pretty.
>
> Or should Jena only write some plain output and expect the application
> to further transform it?
>
> Even for this, it needs some improvement so that there is a @context to
> work from.
>
> ** Can you contribute here? The code is in JsonLD11Writer.java.
>
> https://issues.apache.org/jira/browse/JENA-2153
>
> Andy
JSON-LD: 1.0 or 1.1
Jena has both JSON 1.0, provided by jsonld-java, and JSON-LD 1.1,
provided by Titanium.
What should the default settings be?
For parsing that means what is bound to "application/ld+json" and file
extension .jsonld.
For writing, it means what is setup for Lang.JSONLD.
This is two decisions - parsing and writing can be different.
But.
It is not so simple:
1/ For Java11, the default settings for java.net.http can't contact
schema.org.
This is not a problem with Titanium.
See example code that uses only the plain java.net.http package.
https://issues.apache.org/jira/browse/JENA-2306
HTTP/2 works for java 17.0.2, but does not work for java 11.0.14.
And that means { "@context": "https://schema.org/; } does not work.
(http: redirects to that as well)
This _may_ be:
https://bugs.openjdk.java.net/browse/JDK-8218546
in which case it is fixed in java 11.0.15.
In my testing, it wasn't just google HTTP/2 sites.
** Please try the example code and report the Java version and what happens.
2/ Jena is writing JSON-LD 1.1 without much in the way of transformation
nor creating a @context from the RDF data. It prints full URIs; numbers
aren't abbreviated etc etc. so it not very pretty.
Or should Jena only write some plain output and expect the application
to further transform it?
Even for this, it needs some improvement so that there is a @context to
work from.
** Can you contribute here? The code is in JsonLD11Writer.java.
https://issues.apache.org/jira/browse/JENA-2153
Andy
