> On 2017-05-12, at 23:56, sorok...@gmail.com 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 | ja...@dydra.com | http://dydra.com
