Add that all RDF representations should represent the same graph

[kjetilk]

I just occurred to me (in #305) that we do not seem to say that all RDF representations must represent the same graph, it seems to have been an implicit assumption. This is meant to make it explicit.

[csarven]

Perhaps an assumption to some but I felt that I had to regularly state/argue this in issues, e.g. #60 (comment) , many discussions including RDFa (somehow people wanted to classify RDFa as non-RDF, despite its name or in fact listed as a concrete RDF syntax in RDF 1.1 Concepts), or even whether LDP-RS description made any sense...

..which is also consistent with my comment in 305 re "RDF document".

/me takes a breath.

I don't object to including this statement in the PR but okay with it being included. I don't actually think it needs to be stated. It is a given if RDF 1.1 Concepts is used normatively in the Protocol - which it is.

[RubenVerborgh]

I need to vote against actually, for a major and a minor reason

1. major: content negotiation could happen in other dimensions (profile etc.), leading to representations of the same conceptual resource in different ontologies and/or shapes; these are different RDF graphs, but can still be valid representations. I also point here to a recent discussion where we were considering different representations for containers at some point, which would have contained different RDF graphs.
2. minor: if the resource has RDF 1.1 named graphs, it cannot be adequately represented in RDF 1.0 formats, so subsetting should happen.

[kjetilk]

I need to vote against actually, for a major and a minor reason

1. major: content negotiation could happen in other dimensions (profile etc.), leading to representations of the same conceptual resource in different ontologies and/or shapes; these _are_ different RDF graphs, but can still be valid representations. I also point here to a recent discussion where we were considering different representations for containers at some point, which would have contained different RDF graphs.

Right, there is some tension here. However, part of it is stretching the meaning of a representation. If profiles, Prefer headers, etc, select some subset of the resource, it is not a representation of the resource IMHO, in the same way that if the resource is a fruit basket, a picture of a banana is not a representation of that fruit basket. RFC7240 seems to support this view. IIRC, Fielding did not consider subsets in his REST definition, only conneg over full representations of the state resource.

A transformation is different, I can see that representing the graph in a different ontology could arguably be such a case. Pragmatically, would you actually do this? I could see a CONSTRUCT query being used for this purpose, but server side, that would be a different resource, and client side, it wouldn't matter. Perhaps it is in fact appropriate to say that this would be a different resource?

Now, the situation I'm trying to avoid here is that people write servers where the client has to update both the JSON-LD and the Turtle representation of the same resource. It is not sufficiently clear from the current spec that you shouldn't do that.

How would you formulate a requirement to resolve that problem?

2. minor: if the resource has RDF 1.1 named graphs, it cannot be adequately represented in RDF 1.0 formats, so subsetting should happen.

If that happens somewhere down the road, then the definition needs changing, but that would be a substantial change to Solid as currently defined, and should not be in scope for 1.0 IMHO.

[RubenVerborgh]

but server side, that would be a different resource

Perhaps it is in fact appropriate to say that this would be a different resource?

Not necessarily; if I define /foo/bar to be "Ruben Verborgh's profile", then many representations in many ontologies could be acceptable. If I define it as "Ruben Verborgh's profile in Schema.org", that's something else; and so is "Ruben Verborgh's profile in Schema.org in Turtle". Note that "being a representation of" is a relationship, not an absolute. See https://rubenverborgh.github.io/WebFundamentals/web-apis/#conceptual-resource, https://rubenverborgh.github.io/WebFundamentals/web-apis/#representations, and beyond (but yeah, those are written by me, so not the best source to back up my own point 🙂).

Now, the situation I'm trying to avoid here is that people write servers where the client has to update both the JSON-LD and the Turtle representation of the same resource.

Then write that, I would say. Updating one representation invalidates all others.

[kjetilk]

Not necessarily;

I'm certainly fully aware of that. There has always been room for a certain flexibility in this area, when should two language negotiated representations actually be different resources, etc. To make that not black and white, we have q factors and all that. Similarly, ontologies may have substantial alignment problems that would raise similar concerns. There is substantial room for pragmatism here, but perhaps that room should be restricted.

Now, the situation I'm trying to avoid here is that people write servers where the client has to update both the JSON-LD and the Turtle representation of the same resource.

Then write that, I would say. Updating one representation invalidates all others.

"Invalidate" would not be my favorite word to describe that, then we'd have to say what happens after invalidation, and we shouldn't need to get into implementation details. This would have to be formulated more generally, it goes for any serialization.

Alright, I hoped this was low-hanging fruit, lets leave it and get back to it in the ordinary process.

[kjetilk]

After discussing with @csarven , it is unlikely to be a practical problem in near future, so we don't need to prioritize this now.

[kjetilk]

This issue is itching me a bit. I think we need to define it.

A pragmatic problem is for example that a server applies a transformation to the FOAF data using some mechanism upon a GET request, and then the client PUTs that right back at the server. Then, suddenly, the ontology which you'd like to use for the representation of yourself has changed.

Then, what if your data initially included both foaf:givenName and foaf:familyName and then, what you get back is schema:name, so you had data loss. You could argue that this problem is unavoidable unless you implement input data (shape) validation, and yes that's true.

We could get into deeply philosophical arguments over whether a boat that has replaced all the planks is still the same boat. However, I'd like to keep it pragmatic, because I suspect the way that you'd do this is that there is an abstract representation (which is what your sensor returns or what you keep in your database or on file), but you allow people to read that representation in a variety of concrete syntaxes, and apply various queries and transformations over them. You allow writes using different concrete syntaxes to the same resource, but you don't really want clients to write back the result of the transformation to the resource.

You could, though, if that transformation had its own URI, so that's what I think we should be looking at. It is also an extension of the discussion of origin-form: #368 . If we did define (at least) the resources in terms of absolute-form, then, any transformation (e.g. using a different ontology over the same data), could return a response with a Content-Location header which may use origin-form to identify the actual representation?

Personally, I think I would make that representation read-only, but that could be left as an implementation detail. You could allow the server to transform back upon writes if you had an appropriate ontology alignment engine.

There is a lot of complexity that you could run into by keeping this too open an philosophical for little practical value, and I think therefore makes sense to constrain it to keep it pretty straightforward.

[kjetilk]

Actually, I think I'll close this and instead have a more generic discussion in #198 .