Clarify requests with N3 document in server-representation-turtle-jsonld

[csarven]

This PR is a https://www.w3.org/2023/Process-20230612/#class-3 change in the specification updating the requirement #server-representation-turtle-jsonld .

The current requirement ( #server-representation-turtle-jsonld ) only mentions the case where an RDF document is used to create a resource and then having representations of the resource available in at least JSON-LD and Turtle.

The Solid Protocol currently only specifies updating resources using HTTP PATCH requests with N3 document using the N3 Patch format ( #n3-patch ). The specification does not require the use of N3 document and with #n3-patch to create resources.

There are some implementations that already create resources with PATCH using N3 document and #n3-patch. However, there are no known (Solid) implementations creating resources with PATCH in either RDF document or N3 document with a particular format (besides #n3-patch). This is based on anecdotal evidence, some citations / test results supporting, conflicting, or clarifying this further would be great.

What's currently implied in #server-representation-turtle-jsonld in the context of PATCH and creating resources is using an RDF document-based patch format, e.g., LDP Patch. In other words, PATCH requests with N3 or SPARQL Update are not even covered. Currently implementations based on N3 or SPARQL Update to create resources with PATCH are not conflicting with the current specification, but there is no interoperability based off such conformance on paper.

The proposed change in this PR clarifies ambiguity in that when N3 documents are used to create resources, the server should respond in the same way as it does for RDF documents.

Existing implementations that accept PATCH with N3 document using N3 Patch are still conforming. This PR acknowledges their behaviour and specifies it. Implementations that do not accept N3 documents to create resources are not required to do anything and they do not become non-conforming. The behaviour is quite literally when a server accepts N3 document to create a resource, they must do as follows.

This change intentionally leaves the specific format of the N3 document unspecified at the level of creating a resource (whether with POST, PUT or PATCH):

• So that "N3 document" is specified on the same level as "RDF document";
• It allows servers and the "market" to experiment, adopt alternative approaches, and have reasonable variations if they choose to use different N3 formats.
• If N3 Patch changes or gets removed from the Solid Protocol in favour of another N3-based format, the general conformance to creating resources with PATCH need not be updated. Aside: if SPARQL Update makes a come back, it would need to be added to this requirement ( #server-representation-turtle-jsonld ).

---

Preview | Diff

[gibsonf1]

Right now TrinPod supports SPARQL Update, but we have not looked at the newer N3 spec yet.

[damooo]

🔗
When a server creates a resource on HTTP PUT , POST or PATCH requests such that the request’s representation data encodes an RDF document [ RDF11-CONCEPTS ] or an N3 document [ N3 ] (as determined by the Content-Type header), the server MUST accept GET requests on this resource when the value of the Accept header requests a representation in text/turtle or application/ld+json [ Turtle ] [ JSON-LD11 ]. [ Source ] Source ] [ Source ] [ Source ]

This may be is problematic. The clause "request's representation data", is not correct. http requests contain some "content", that is not required to be that of target resource's representation. PATCH is an example case. Here the request's content is not representation data, but of a document encoding "patch directives".

It was so happened that protocol defined a specific patch named "solid:InsertDeletePatch", in n3's logic language to encode patch instructions over rdf resources.

But that doesn't prevent us from defining another patch type that operates over non-rdf resources (LDP-NR), also encoded as n3 document. Say a "solid:JsonPatch", which contain instructions on how to patch/create a json document. Or some patch to do image crop/rotate/resize/effect operations expressed in n3 directives.

The patch document only carries some instructions to process target resource. The instruction-carrier content type has no correspondence with target resource's content-type. A json can be used to describe patch on LDP-RS, and an n3-doc can be used to describe patch on image/* resources, etc.

We can instead say, if a resource is determined as LDP-RS (however it got created), then it should conneg successfully over turtle, json-ld. LDP-RS is defined by LDP spec.

[jeff-zucker]

[🔗](https://services.w3.org/htmldiff?

The patch document only carries some instructions to process target resource. The instruction-carrier content type has no correspondence with target resource's content-type.

I agree in the case of existing resources - an N3-Patch on a Turtle document should result in a Turtle document. But what about the case, which I think this PR is meant to address where we create a new document with n3-patch. Is that resulting document text/n3 ? I'm not sure what else it could be. So we need to ensure that even though it has a content-type of text/n3 it should still be available as text/turtle and json-ld.

[damooo]

I agree in the case of existing resources - an N3-Patch on a Turtle document should result in a Turtle document. But what about the case, which I think this PR is meant to address where we create a new document with n3-patch.

Here, there is a conflation with terms n3-doc, n3-patch-doc. The term n3-patch is collaquial, and we are using it to refer a special patch of class solid:InsetDeletePatch` which happened to be encoded in n3, and operates over rdf resources, or create an empty rdf resource. But that doesn't prevent us from defining new classes of patches (like ex:JsonPatch for eg.), also encoded in n3, but operates on non-rdf resources.

Thus the the patch-carrier document's content-type has no essential meaning vis-a-vis the target resource's representation content type. Only patch directives can conclusively define.

[elf-pavlik]

The spec should define it in the way that already covers the SPARQL update which uses application/sparql-update

[michielbdejong]

I see what you're trying to do here but I think the mention of N3 documents in general can add confusion. Instead of inserting:

    or an <em>N3 document</em> [<cite><a class="bibref" href="#bib-notation3">N3</a></cite>]

Maybe you can insert:

    or (e.g. for the purpose of <em>N3 Patch</em>) an <em>N3 document</em> [<cite><a class="bibref" href="#bib-notation3">N3</a></cite>]

[michielbdejong]

This PR is on the agenda for the 17 January CG Call

[michielbdejong]

Or instead of

the request’s representation data encodes an RDF document

say:

the request creates or updates an RDF resource

[elf-pavlik]

Wouldn't it be better to have separate requirements for

1. Creating RDF resources
2. Serving RDF resources

?

I'm thinking of a case where data gets imported to storage. In that case, the RDF resource wasn't created by HTTP
request but still needs to be served correctly.

[csarven]

@michielbdejong @elf-pavlik , Ack'ing your suggestions in #608 (comment) , #608 (comment) and #608 (comment) . I updated the suggestion to use and refer to RDF source.

I'm support merging this PR at this point. I am also okay with the consideration split the requirement but would like to doublecheck priors discussion on this before doing so, e.g., #119 and there are a number of other older PRs touching on this. There were considerations around Accept / content-negotiation that we touched on in the past. Just let me verify...

[elf-pavlik]

LGTM and I see no problem with merging it right away