good afternoon; > On 2017-05-13, at 13:23, [email protected] wrote: > > The rules for JSON-LD are not relevant, which is why neither Andy nor I > referred to them, and this is not a question of limitation in any models. > Jena itself deals in the generalized models [1] internally. The issue is the > burden placed on implementations, as was described.
we agree it is not a question of the "limitation in any models”. we disagree, as to whether the rules for encoding json-ld are relevant to the original question, which was > On 2017-05-12, at 21:24, Laura Morales <[email protected]> wrote: > >> JSON-LD is an RDF syntax for graphs and datasets so it will need to be a >> CONSTRUCT or DESCRIBE query. >> >> XML/JSON/CSV/TSV are result set format for SELECT. > > > OK perhaps this is a noob question, but I don't understand why there is this > distinction between formats... > If results are returned in the form of "s p o" triples anyway, regardless of > XML/JSON/CSV/TSV, why can't the same output be formatted as n-triples, > turtle, or json-ld? > the answers to "why there is this distinction between formats” and "why can't the same output be formatted as n-triples" were to the effect that it not possible to effect a json-ld encoding based on a solution sequence. the point of the analogy to construct encoding is, that claim is not correct and that the answer is to be found not in the nature of the models, but in the rules which the encoding applies to a given model. > I am not going to confuse this issue by extending this thread. If you want to > prolong your argument, I suggest you bring in a PR for Jena that demonstrates > it. i suggest no change to jena, just that the explanation follow from necessity not contingency. these threads end up being matter of record and are relevant beyond a given implementation, so they should not confuse current circumstances with necessity. best regard, from berlin, > > --- > A. Soroka > > [1] https://www.w3.org/TR/rdf11-concepts/#section-generalized-rdf > > james anderson wrote on 5/12/17 6:54 PM: >> >>> On 2017-05-12, at 23:56, [email protected] wrote: >>> >>> No. That portion of the specification permits a CONSTRUCT query to discard >>> inappropriate matches. In no way does it require implementations to do >>> format inference. >> >> yes. >> >> the point is that the issue of whether a term is permitted in a given form >> in a given encoding is not an inherent property of the model from which the >> encoding is generated, but an aspect of the encoding. >> in addition to the practical matter of how to accomplish json-ld in the >> current situation, the original question concerned why one cannot encode a >> solution sequence as json-ld - specifically a sequence of solutions of >> cardinality three, but in general of any cardinality. >> the answer is not to be found in the nature of an rdf graph as a solution >> sequence is not necessarily a graph. >> the answer is to be found in the rules for the encoding. >> as construct demonstrates. >> >> just as the process for encoding the response from a construct query >> recognizes and describes how to process cases where a term does not meet >> certain constraints, the encoding rules for json-ld could do the same. >> >> that the json-ld document’s descriptions of the algorithms do not comprehend >> this is neither inherent in the nature of json-ld nor in the nature of a ( >> three-term ) solution sequence, but rather a limitation in those algorithm >> descriptions. >> there is nothing inherent in the information present in the intermediate >> result of an arbitrary select query to preclude encoding it as json-ld. >> the current situation is a matter of implementation artefacts - that is, how >> they happen now to work, not of inherent limitations. >> >> best regards, from berlin, >> --- >> james anderson | [email protected] | http://dydra.com >> >> >> >> >> --- james anderson | [email protected] | http://dydra.com
