Re: Expected behavior when serializing named graphs using a format that does not support named graphs

Only the statements in the default graph are asserted. Sure, dropping the named graphs when serializing to a format that can only express a single graph is a loss, but it's better to lose data, than to imply that the potentially contradictory statements of the various named graphs are asserted by the dataset.

And if the intent is to assert all the statement in the named graphs, have the default graph be the union graph.

May 21, 2023 4:36:48 PM Iwan Aucamp <aucampia@gmail.com>:

>> but the sentiment remains the same: follow the expressed intent.
> I would agree with this, but I guess the real challenge is, what is the expressed intent with code like this:
> 
> dataset = Dataset()
> # add some named graphs and triples inside them
> dataset.serialize(format="turtle")
>  
> To me, it is not clear that the intent is to serialize a subset of the RDF Dataset. I would rather say that the expressed intent seems to be to serialize the whole Dataset. One could argue that in this case, the caller asking for Turtle format it seems clear they just want to serialize a subset, but if this is being passed as a variable this no longer holds.
> 
> And after all, there are easy ways in which users can much more explicitly say that they want to serialize the default graph alone, and in those cases, the intent is much clearer.
> 
> /*From*/: James Anderson <anderson.james.1955@gmail.com[anderson.james.1955@gmail.com?Subject=Re%3A%20Expected%20behavior%20when%20serializing%20named%20graphs%20using%20a%20format%20%20that%20%20does%20not%20support%20named%20graphs&In-Reply-To=%3CD010D2F3-2B55-4353-86E1-FF6A5BFA676D%40gmail.com%3E&References=%3CD010D2F3-2B55-4353-86E1-FF6A5BFA676D%40gmail.com%3E]>
> /*Date*/: Sun, 21 May 2023 10:16:18 +0200
> /*To*/: public-rdf-dev@w3.org[public-rdf-dev@w3.org?Subject=Re%3A%20Expected%20behavior%20when%20serializing%20named%20graphs%20using%20a%20format%20%20that%20%20does%20not%20support%20named%20graphs&In-Reply-To=%3CD010D2F3-2B55-4353-86E1-FF6A5BFA676D%40gmail.com%3E&References=%3CD010D2F3-2B55-4353-86E1-FF6A5BFA676D%40gmail.com%3E]
> /*Message-Id*/: <D010D2F3-2B55-4353-86E1-FF6A5BFA676D@gmail.com>
>> good morning; in the context of the original question, the closer analogy might be to CONSTRUCT { ?s ?p ?o} WHERE { GRAPH ?g { ?s ?p ?o } } but the sentiment remains the same: follow the expressed intent. 
>>  
>>> On 21. May 2023, at 10:07, Reto Gmür <reto@factsmission.com[reto@factsmission.com?Subject=Re%3A%20Expected%20behavior%20when%20serializing%20named%20graphs%20using%20a%20format%20%20that%20%20does%20not%20support%20named%20graphs&In-Reply-To=%3CD010D2F3-2B55-4353-86E1-FF6A5BFA676D%40gmail.com%3E&References=%3CD010D2F3-2B55-4353-86E1-FF6A5BFA676D%40gmail.com%3E]> wrote:
>>>
>>> Good morning.
>>>
>>> I'd recommend to be consistent with CONSTRUCT { ?s ?p ?o} WHERE { ?s ?p ?o } and to serialize the default graph by default.
>>>
>>> May 21, 2023 6:48:19 AM James Anderson <anderson.james.1955@gmail.com[anderson.james.1955@gmail.com?Subject=Re%3A%20Expected%20behavior%20when%20serializing%20named%20graphs%20using%20a%20format%20%20that%20%20does%20not%20support%20named%20graphs&In-Reply-To=%3CD010D2F3-2B55-4353-86E1-FF6A5BFA676D%40gmail.com%3E&References=%3CD010D2F3-2B55-4353-86E1-FF6A5BFA676D%40gmail.com%3E]>:
>>>
>>>> good morning;
>>>>
>>>> the issue is similar for graph store protocol put and post operations and for sparql update load and insert operations.
>>>> the insert operation is the only one which is explicit about the consequences of the various combinations.
>>>> if one takes it as the precedent, the effect should be to do what the operation variant says to do.
>>>> in this case, drop the graph.
>>>>
>>>>> On 21. May 2023, at 00:16, Iwan Aucamp <aucampia@gmail.com[aucampia@gmail.com?Subject=Re%3A%20Expected%20behavior%20when%20serializing%20named%20graphs%20using%20a%20format%20%20that%20%20does%20not%20support%20named%20graphs&In-Reply-To=%3CD010D2F3-2B55-4353-86E1-FF6A5BFA676D%40gmail.com%3E&References=%3CD010D2F3-2B55-4353-86E1-FF6A5BFA676D%40gmail.com%3E]> wrote:
>>>>>
>>>>> Hi
>>>>>
>>>>> I would like some feedback on what people think the right behaviour should be when serializing named graphs using a format that does not support named graphs like Turtle or N-Quads.
>>>>>
>>>>> These are :
>>>>> •
>>>>> Raise an error: Indicate to the caller that the requested operation cannot be completed successfully. The output in this case is somewhat open-ended, in case of streaming there could be some output, though I would expect the output to be a subset of #2, not of #3.
>>>>> • Only output triples from the default graph, but don't output triples from named graphs without raising an error.
>>>>> • Output triples from the named graphs without a graph label without raising an error.
>>>>>
>>>>> To me, #1 seems right - though Python RDFLib does #3 and Jena does #2.
>>>>>
>>>>> Two GitHub issues related to this are:
>>>>>
>>>>> - <https://github.com/RDFLib/rdflib/issues/2393>: Formats that don't support named graphs serialize Datasets and ConjunctiveGraphs with non-default graphs without raising any errors
>>>>> - <https://github.com/apache/jena/issues/1873>: Using riot with N-Quads input with named graphs and N-Triples/Turtle output silently drops part of the input #1873
>>>>>
>>>>> Regards
>>>>> Iwan Aucamp
>>>>
>>>> ---
>>>> james anderson | james@dydra.com | https://dydra.com[https://dydra.com/] --- 
>> james anderson | james@dydra.com | https://dydra.com[https://dydra.com/] 
> --
> Iwan Aucamp