Page tree
Skip to end of metadata
Go to start of metadata

Working Draft

Pre-Working Draft Notes

Restrictions on LDP 1.0

  • MUST support LDP-NR
  • MUST provide a LDP-RS describing LDP-NRs (LDP MAY becomes MUST)
    • MAY? RECOMMENDED? include a Link header of rel="describes" when requesting the LDP-RS created
  • MUST support PATCH with Accept-Patch (LDP 4.2.7 MAY becomes MUST)
    • LDP requires text/turtle on POST, if POST is supported per, is there an acceptable minimum?
  • SHOULD allow storage of RDF serializations as LDP-NR if client specifies LDP-NR interaction model
    • clarifies to include LDP-NR, should test in TCK

Original file names?

Container types?

  • No labels


  1. I think we can be confident that this has something to do with LDP.

  2. If "MUST support PATCH with Accept-Patch" but only "SHOULD support PATCH with SPARQL-PATCH", is there a canonical patch format we can require?

    1. 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.

      1. 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.

        1. +1 for SPARQL-UPDATE

  3. "Original file names?"

    No, that's metadata.

    1. Right, but do we think the minimal binary storage needs of a light repository can be met without respecting Content-Disposition on the request?

      1. 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.

  4. "Container types?"

    Well, as light as is feasible, of course. Can we say just "Basic"? I don't know. That's awfully simplistic.

  5. 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.

    1. Yeah, I get that. I'm saying we could further refine that with the specific format.

      1. Is the implication that the current SPARQL-UPDATE is unsatisfactory?

        1. 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.)

  6. "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.

    1. Header on LDP-RS

      Link: <http://localhost:8080/rest/some-ldp-nr>; rel="describes"

      Header on LDP-NR

      Link: <http://localhost:8080/rest/some-ldp-rs>; rel="describedby"
      1. Yeah, that's good. For the RS, do we not want to have a triple? That's important for "off-line" work.

        1. Hmm, the subject of all of the triples in the RS will be the NR. Is that not sufficient?

          1. 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.

            1. 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?

              1. 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.

          2. But that won't be true: there may be blank nodes. Presumably hash URIs.

            1. HOORAY FOR BLANK NODES!

              1. Is suspect some example RDF will help this discussion. Benjamin ArmintorA. Soroka?

                1. 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.

              2. 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 because the subject was not the LDP-NR, I would push back.

                1. 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?

                  1. I am suggesting that this behavior is an implementation concern, not an API concern.

                2. 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.

                  1. 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.

                    1. 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.

                      1. 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, and that is I think a significantly more distressing ambiguity than this.

                        1. 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.

                          1. 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. 

                            1. 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.

                              1. 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.

                                1. No, it does not specify enough to satisfy me, and I look forward to writing the language disallowing arbitrary triple subjects.

                                  1. +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.

        2. 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.

          1. Yeah, that tension is real. But don't you think our Prefer schemes mitigate the first side of the tug?

            1. 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.

              1. 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.

  7. "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.

    1. 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. 

      1. Okay, caution is good. Let's leave it alone for now.

  8. Status of PUT for create?

    Chris Beer seems to have opinions about this

    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.

    1. Chris Beer, can you say a little more about why you feel particularly concerned about this?

    2. 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?

      1. Given a container (of any type) at: 


        And a PUT request to:

        Some LDP implementations respond by adding new-resource to my-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.

        1. 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.

          1. 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:

            Either approach seems viable for Fedora, to me.

            1. 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.

          2. 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?

            1. I'm reluctant to have a heavy hand with containment, because it is one of the most opinionated parts of the LDP spec.

              1. I'm pretty sure we have to let people do either. To me, this question is about a default behavior.

            2. 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?

              1. 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.

                1. 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?

    3. 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.

      1. 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?

        1. 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.

          1. 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.


  9. Should the Spec have the opinion that all LDP-RSs are Containers, or is this a quirk of the reference implementation?

    1. 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".