-
Notifications
You must be signed in to change notification settings - Fork 46
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add that all RDF representations should represent the same graph #309
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I need to vote against actually, for a major and a minor reason
- 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.
- minor: if the resource has RDF 1.1 named graphs, it cannot be adequately represented in RDF 1.0 formats, so subsetting should happen.
Right, there is some tension here. However, part of it is stretching the meaning of a representation. If profiles, 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 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?
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. |
Not necessarily; if I define
Then write that, I would say. Updating one representation invalidates all others. |
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
"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. |
After discussing with @csarven , it is unlikely to be a practical problem in near future, so we don't need to prioritize this now. |
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 Then, what if your data initially included both 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 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. |
Actually, I think I'll close this and instead have a more generic discussion in #198 . |
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.