There's not. LDPatch was developed with the possibility of filling this role, but didn't reach standardization.
I would suggest requiring SPARQL UPDATE (as the most supported option in RDF libraries across languages), and acknowledging that other options (SPARQL PATCH, LDPatch, ...) MAY be supported.
Well, yeah, I think so. But I'm not sure that I (or any of us) are totally solid on the use cases for a "light repository" yet, especially not a light Fedora repository. I do like that phrase "light repository". We need more light in a world of gathering darkness.
Not as such (although I think we can do better, which is to say, lighter). The question is as Benjamin Armintor perceived: if you have to do PATCH, but you don't have to do SPARQL, we should tell you what you do have to do. (What format is the one on which all Fedora client software can rely, at all times.)
I think we'll need to be very specific here-- not saying this is missing now, just making a note that we need to say exactly how you get from one to the other and back again.
No, I don't think so. That's implicit. But this may not be something we can really figure out, because it may come down to the same "What is the right subject for triples in a description of an NR?" dilemma that we already know hasn't go a nice answer.
My recollection was that we had those discussions and landed on "The right subject for triples in a description of an NR is the NR". Are you suggesting we once again revisit that?
No, I'm saying that was a compromise. There were reasons to do it one way and the other, and we chose as best we could in the knowledge that some cases were going to lose out.
No, I don't think we do need any examples. I think the answer is simply that we made a choice to use the NR as the subject, for good reasons, but that so doing closed off other doors for us, like having a good triple to point to the NR.
I'm just saying. If someone proposed that a conforming impl MUST (or even SHOULD) reject a request to update the description of a LDP-NR with a 4xx (pursuant to LDP 4.2.4.4) because the subject was not the LDP-NR, I would push back.
Benjamin Armintor, despite the hours of debate and final resolution, are you suggesting that the subjects of triples in descriptions of LDP-NRs should be allowed to be arbitrary?
If someone said that we should allow subjects that are not the NR, blank, or hashes after the NR's URI, I will throw the same -1 I did last time. Anything else should certainly throw a 4xx, because this is an object repository, not a triplestore.
That's fine for an implementation: It should have this behavior documented in its constraints; it should return a 4xx. I'm working on an implementation that is built on a triplestore, so my concerns are different. The common case is the client expectation.
The client should only have to expect that the server rejects updates it won't store. I'm not suggesting that the reference impl has to support this, only that the spec should not disqualify based on support for it. The closest analog from the LDP spec is the SHOULD NOT in 5.2.1.3, and that is I think a significantly more distressing ambiguity than this.
No, this is beyond scope creep, this is scope erosion. Triples are just a technique to publish and transmit object properties. Object properties are what Fedora is actually interested in. Any triple should be a clear, unambiguous translation of an object property. Period.
I am pleading, don't begin this argument again. We don't agree. I am proposing, here, to defer to the implementation. It's not scope creep to defer to the implementation via the existing spec, which included well defined ways to discover the constraints of the interaction.
Ben, you are beginning this argument again, and I am frankly stunned that you are. My opinion has not changed, and I will do what I can to prevent this going into the spec.
I want to reiterate: I am not advocating for anything but to say that LDP already specifies enough on the topic to satisfy us both, and that further specification is unnecessary. I don't think FCREPO 4's behavior should change.
I am of two minds about this mechanism generally: On the one hand, I think it is virtuous to minimize non-user data presented in LDPR GET response bodies. On the other, headers are harder to deal with in terms of caches and similar contexts as A. Soroka points out.
Sort of, but there are real limitations to what you can do there without inching along the road to named graphs (which some people will think are great), but is maybe not a useful thing to bake into a conformance spec. Again, two minds.
Hm. Well, the header is something. Let's leave it there for now. If I can think of a real strong use case for having the link in the body, I will offer it.
I want to think very carefully about where we promote from "not in a spec" to "MUST". I'm sympathetic to this, for what it's worth. But I am thinking that as a first pass we try to reserve MUST for restrictions/refinements.
I think it seems fine to let the LDP spec alone. If we're going to recommend PUT creation, I think we should have fairly strong requirements for containment behaviors of those requests.
Ah, okay. Agreed, that can't be left ambiguous. My sense is that the first option is what most people will want, but perhaps not. Perhaps we can offer one choice with an override via headers.
When I did RDF::LDP in Ruby, my feeling was that the uncontained approach was simpler and gave the client more flexibility about mapping containment structures to paths.
I don't think either approach is crazy. We'd like to be "ergonomic", so if we decide to do this (and even if we don't require PUT, I think we'll want to specify how you do PUT if you do support it in your impl, based on your remark above) maybe we can get some sense from the community what would be more convenient.
Well, for one thing, I think you want to have an override if you do offer the first approach as default, but otherwise, I think you may be right, which brings up a whole 'nuther question about exactly that: is it okay to have multi-rooted repositories?
This seems like the main issue, to me. If a "root container" in Fedora has significance beyond just being a container which happens not to be contained, then there might be a good reason to disallow PUT of free-floating resources in general.
See thread below re: PUT. I agree that this is the heart of this question, as well as of that one. Do we require that the repository graph be entirely connected via LDP containment?
The way the LDP test suite interprets this is to suggest that the semantics of PUT for create are identical to those of POST (slugs, etc). I find this approach suspect. And I agree that containment is unclearly defined for PUT otherwise. So, not sure we should do more than adopt LDP's punt.
That's right. Allowing create on PUT gets you a safe "create or update" operation. This is, perhaps, an argument for defaulting to containment on create.
Additionally, it gets you creation at arbitrary addresses, without need for a POST target. If desirable, this is an argument for no-containment.
I feel like there's a connection between this question and one above (can a Fedora repository have more than one root). Maybe we can factor out something underlying both? It has to do with the connectedness of the repository graph. Otherwise, I'm inclined to resolve the ambiguity in LDP's PUT one way or another, but not require service for PUT. So if a Fedora repository does service PUT, it does it in a well-defined way. Of course, if PUT is being advertised only through OPTIONS, it could vary across a repo. Le sigh.
I think this is a choice of the r. i. I think the long conversation we had in the community about that ended up with good use cases that could all be satisfied by containers-with-no-content (what I called pointlike containers), but we might want to revisit that in light of "SHOULD allow storage of RDF serializations as LDP-NR if client specifies LDP-NR interaction model".
, unless otherwise noted.
63 Comments
A. Soroka
I think we can be confident that this has something to do with LDP.
A. Soroka
If "MUST support PATCH with Accept-Patch" but only "SHOULD support PATCH with SPARQL-PATCH", is there a canonical patch format we can require?
tamsin johnson
There's not. LDPatch was developed with the possibility of filling this role, but didn't reach standardization.
I would suggest requiring SPARQL UPDATE (as the most supported option in RDF libraries across languages), and acknowledging that other options (SPARQL PATCH, LDPatch, ...) MAY be supported.
A. Soroka
That sounds reasonable to me. It would have been nice to use something simpler, but we gots what we got. Maybe we can revisit this as time goes by.
Andrew Woods
+1 for SPARQL-UPDATE
A. Soroka
"Original file names?"
No, that's metadata.
Benjamin Armintor
Right, but do we think the minimal binary storage needs of a light repository can be met without respecting Content-Disposition on the request?
A. Soroka
Well, yeah, I think so. But I'm not sure that I (or any of us) are totally solid on the use cases for a "light repository" yet, especially not a light Fedora repository. I do like that phrase "light repository". We need more light in a world of gathering darkness.
A. Soroka
"Container types?"
Well, as light as is feasible, of course. Can we say just "Basic"? I don't know. That's awfully simplistic.
Benjamin Armintor
Probably, but this is separated into two requirements such that the first is a restriction of LDP's MAY support PATCH, MUST Accept-Patch if so.
A. Soroka
Yeah, I get that. I'm saying we could further refine that with the specific format.
Andrew Woods
Is the implication that the current SPARQL-UPDATE is unsatisfactory?
A. Soroka
Not as such (although I think we can do better, which is to say, lighter). The question is as Benjamin Armintor perceived: if you have to do PATCH, but you don't have to do SPARQL, we should tell you what you do have to do. (What format is the one on which all Fedora client software can rely, at all times.)
A. Soroka
"MUST provide a LDP-RS describing LDP-NRs"
I think we'll need to be very specific here-- not saying this is missing now, just making a note that we need to say exactly how you get from one to the other and back again.
Andrew Woods
Header on LDP-RS
Header on LDP-NR
A. Soroka
Yeah, that's good. For the RS, do we not want to have a triple? That's important for "off-line" work.
Andrew Woods
Hmm, the subject of all of the triples in the RS will be the NR. Is that not sufficient?
A. Soroka
No, I don't think so. That's implicit. But this may not be something we can really figure out, because it may come down to the same "What is the right subject for triples in a description of an NR?" dilemma that we already know hasn't go a nice answer.
Andrew Woods
My recollection was that we had those discussions and landed on "The right subject for triples in a description of an NR is the NR". Are you suggesting we once again revisit that?
A. Soroka
No, I'm saying that was a compromise. There were reasons to do it one way and the other, and we chose as best we could in the knowledge that some cases were going to lose out.
Benjamin Armintor
But that won't be true: there may be blank nodes. Presumably hash URIs.
A. Soroka
HOORAY FOR BLANK NODES!
Andrew Woods
Is suspect some example RDF will help this discussion. Benjamin Armintor? A. Soroka?
A. Soroka
No, I don't think we do need any examples. I think the answer is simply that we made a choice to use the NR as the subject, for good reasons, but that so doing closed off other doors for us, like having a good triple to point to the NR.
Benjamin Armintor
I'm just saying. If someone proposed that a conforming impl MUST (or even SHOULD) reject a request to update the description of a LDP-NR with a 4xx (pursuant to LDP 4.2.4.4) because the subject was not the LDP-NR, I would push back.
Andrew Woods
Benjamin Armintor, despite the hours of debate and final resolution, are you suggesting that the subjects of triples in descriptions of LDP-NRs should be allowed to be arbitrary?
Benjamin Armintor
I am suggesting that this behavior is an implementation concern, not an API concern.
A. Soroka
If someone said that we should allow subjects that are not the NR, blank, or hashes after the NR's URI, I will throw the same -1 I did last time. Anything else should certainly throw a 4xx, because this is an object repository, not a triplestore.
Benjamin Armintor
That's fine for an implementation: It should have this behavior documented in its constraints; it should return a 4xx. I'm working on an implementation that is built on a triplestore, so my concerns are different. The common case is the client expectation.
A. Soroka
Right, and the client has no right to expect to jam arbitrary triples into something that is not a triplestore. That is a misshapen view of the world.
Benjamin Armintor
The client should only have to expect that the server rejects updates it won't store. I'm not suggesting that the reference impl has to support this, only that the spec should not disqualify based on support for it. The closest analog from the LDP spec is the SHOULD NOT in 5.2.1.3, and that is I think a significantly more distressing ambiguity than this.
A. Soroka
No, this is beyond scope creep, this is scope erosion. Triples are just a technique to publish and transmit object properties. Object properties are what Fedora is actually interested in. Any triple should be a clear, unambiguous translation of an object property. Period.
Benjamin Armintor
I am pleading, don't begin this argument again. We don't agree. I am proposing, here, to defer to the implementation. It's not scope creep to defer to the implementation via the existing spec, which included well defined ways to discover the constraints of the interaction.
A. Soroka
Ben, you are beginning this argument again, and I am frankly stunned that you are. My opinion has not changed, and I will do what I can to prevent this going into the spec.
Benjamin Armintor
I want to reiterate: I am not advocating for anything but to say that LDP already specifies enough on the topic to satisfy us both, and that further specification is unnecessary. I don't think FCREPO 4's behavior should change.
A. Soroka
No, it does not specify enough to satisfy me, and I look forward to writing the language disallowing arbitrary triple subjects.
tamsin johnson
+1 to writing this out with clear, normative language.
A non-normative preamble describing the goals of Fedora as an object repository and motivating the subject restrictions would be advisable, too.
Benjamin Armintor
I am of two minds about this mechanism generally: On the one hand, I think it is virtuous to minimize non-user data presented in LDPR GET response bodies. On the other, headers are harder to deal with in terms of caches and similar contexts as A. Soroka points out.
A. Soroka
Yeah, that tension is real. But don't you think our Prefer schemes mitigate the first side of the tug?
Benjamin Armintor
Sort of, but there are real limitations to what you can do there without inching along the road to named graphs (which some people will think are great), but is maybe not a useful thing to bake into a conformance spec. Again, two minds.
A. Soroka
Hm. Well, the header is something. Let's leave it there for now. If I can think of a real strong use case for having the link in the body, I will offer it.
A. Soroka
"MAY? RECOMMENDED? include a Link header of rel="describes" when requesting the LDP-RS created"
I would go straight to MUST. It shouldn't be hard, and it makes the relationship explicit in the exchange.
Benjamin Armintor
I want to think very carefully about where we promote from "not in a spec" to "MUST". I'm sympathetic to this, for what it's worth. But I am thinking that as a first pass we try to reserve MUST for restrictions/refinements.
A. Soroka
Okay, caution is good. Let's leave it alone for now.
tamsin johnson
Status of PUT for create?
Chris Beer seems to have opinions about this https://github.com/fcrepo4-labs/derby/issues/11
I think it seems fine to let the LDP spec alone. If we're going to recommend PUT creation, I think we should have fairly strong requirements for containment behaviors of those requests.
A. Soroka
Chris Beer, can you say a little more about why you feel particularly concerned about this?
A. Soroka
tamsin johnson, can you unpack what you mean by "containment behaviors"? Are you thinking of what kinds of containers could be created in this way?
tamsin johnson
Given a container (of any type) at:
And a PUT request to:
Some LDP implementations respond by adding
new-resourcetomy-container; others simply create the resource as uncontained.I can't see the point of requiring PUT if this sort of behavior is left undefined.
A. Soroka
Ah, okay. Agreed, that can't be left ambiguous. My sense is that the first option is what most people will want, but perhaps not. Perhaps we can offer one choice with an override via headers.
tamsin johnson
When I did RDF::LDP in Ruby, my feeling was that the uncontained approach was simpler and gave the client more flexibility about mapping containment structures to paths.
I chose to strictly respect Slug headers on POST, which seems to meet the PUT use case (see also: https://github.com/fcrepo4-labs/derby/issues/6).
Either approach seems viable for Fedora, to me.
A. Soroka
I don't think either approach is crazy. We'd like to be "ergonomic", so if we decide to do this (and even if we don't require PUT, I think we'll want to specify how you do PUT if you do support it in your impl, based on your remark above) maybe we can get some sense from the community what would be more convenient.
Benjamin Armintor
I think it is often what people want, but requiring it also means you can't create uncontained root nodes via the REST api, right?
Benjamin Armintor
I'm reluctant to have a heavy hand with containment, because it is one of the most opinionated parts of the LDP spec.
A. Soroka
I'm pretty sure we have to let people do either. To me, this question is about a default behavior.
A. Soroka
Well, for one thing, I think you want to have an override if you do offer the first approach as default, but otherwise, I think you may be right, which brings up a whole 'nuther question about exactly that: is it okay to have multi-rooted repositories?
tamsin johnson
This seems like the main issue, to me. If a "root container" in Fedora has significance beyond just being a container which happens not to be contained, then there might be a good reason to disallow PUT of free-floating resources in general.
A. Soroka
See thread below re: PUT. I agree that this is the heart of this question, as well as of that one. Do we require that the repository graph be entirely connected via LDP containment?
Benjamin Armintor
The way the LDP test suite interprets this is to suggest that the semantics of PUT for create are identical to those of POST (slugs, etc). I find this approach suspect. And I agree that containment is unclearly defined for PUT otherwise. So, not sure we should do more than adopt LDP's punt.
A. Soroka
I'm trying to think of what you can do with PUT that you can't do with some combination of other messages. Isn't PUT idempotent?
tamsin johnson
That's right. Allowing create on PUT gets you a safe "create or update" operation. This is, perhaps, an argument for defaulting to containment on create.
Additionally, it gets you creation at arbitrary addresses, without need for a POST target. If desirable, this is an argument for no-containment.
A. Soroka
I feel like there's a connection between this question and one above (can a Fedora repository have more than one root). Maybe we can factor out something underlying both? It has to do with the connectedness of the repository graph. Otherwise, I'm inclined to resolve the ambiguity in LDP's PUT one way or another, but not require service for PUT. So if a Fedora repository does service PUT, it does it in a well-defined way. Of course, if PUT is being advertised only through OPTIONS, it could vary across a repo. Le sigh.
tamsin johnson
Should the Spec have the opinion that all LDP-RSs are Containers, or is this a quirk of the reference implementation?
A. Soroka
I think this is a choice of the r. i. I think the long conversation we had in the community about that ended up with good use cases that could all be satisfied by containers-with-no-content (what I called pointlike containers), but we might want to revisit that in light of "SHOULD allow storage of RDF serializations as LDP-NR if client specifies LDP-NR interaction model".