Container URLs should end in /

[Robert Sanderson]

Extending Adam's distinction between non-containers and removing the subject restriction on triples:

3)  Fedora4 treats the URIs .../x and .../x/ as identifying the same resource.  

Containers need to end in / otherwise relative URIs don't resolve correctly.  As all Fedora rdf resources are currently containers, it is my contention that they should all end in /. 

Otherwise, if the container was .../x and you posted content with a relative URI to it say <y>, the resolution rules would require the resolution to be .../xy and not .../x/y.

This will be more apparent if 1) is accepted, as /x should then be a vanilla LDPR, and /x/ would be a container.  I expect there would be a restriction that both /x and /x/ cannot co-exist as separate resources, which should be documented and referenced in the constraints link.

Rob

--

Rob Sanderson

Information Standards Advocate

Digital Library Systems and Services

Stanford, CA 94305

[Benjamin Armintor]

Would it be reasonable to suggest that, creating a container Slug: x, you get

</x> a ldp:RdfSource, ldp:describes </x/>

</x/> a ldp:Container

or just a 404 for /x? Or possibly even a 410?

- Ben

--
You received this message because you are subscribed to the Google Groups "Fedora Tech" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fedora-tech...@googlegroups.com.
To post to this group, send email to fedor...@googlegroups.com.
Visit this group at http://groups.google.com/group/fedora-tech.
For more options, visit https://groups.google.com/d/optout.

[Robert Sanderson]

Or just a redirect from /x to /x/ for containers (assuming that we get non-containers as well)

I don't mind the distinction between /x and /x/ as different resources, but it could be confusing for existing adopters, and might be tricky to implement (if I understand correctly from Chris)

Rob

[aj...@virginia.edu]

I agree that the distinction might be confusing (at least at first) but I can think of some possible utility.

For example, Fedora users are used to being able to record the collection-common metadata describing things in a collection by attaching assertions to a "collection object". For some situations in Fedora 4, the natural translation of a "collection object" will be a resource that directly contains the members of the collection by using the repository's administrative hierarchy. Then one could make "heritable" assertions on the slash-end URI and "non-heritable" assertions on the "non-slash-end" URI, or use some similar system.

Generally, I'm disinclined to collapse distinctions like this one unless we actually hear of real confusion being experienced in the field.

---
A. Soroka
The University of Virginia Library

[David Moles]

Speaking as a relative newcomer, I find the idea of /foo and /foo/ referring to different resources -- potentially arbitrarily different resources -- deeply, deeply, deeply counterintuitive. 

From a different domain, the Internet Archive's Archive-It service treats URLs with trailing slashes differently for purposes of determining crawl scope, and it's causing no end of trouble as we try to migrate our users to it from a system that makes them state their intentions explicitly.

I certainly wouldn't count on any user entering such a URL in a UI to enter it correctly (or even count on a UI developer not to munge it), and I wouldn't count on them publishing it in any human-readable form correctly, either. The web's established a norm that if your URL should end in a slash, but doesn't, you'll be cheerfully redirected; this might not be the most correct behavior (and I'm old enough to remember, twenty years ago, trying to conscientiously include those in order not to hammer people's Sun pizza boxes with redirects), but it's what people are used to.

[aj...@virginia.edu]

I don't think anyone is arguing that what you describe shouldn't be available as a choice to Fedora sites. The question is whether Fedora should disallow any other possible pattern.

In some ways, this is a case of tension between URL-as-identifier and URL-as-pointer. That's something that comes up a lot in Linked Data work, because a great deal of the power of a Linked Data approach arises from that exact conflation.

---
A. Soroka
The University of Virginia Library

[David Moles]

Then it would be good, at minimum, to have an option to auto-redirect as Robert suggests. (And personally I think it should be the default, but as I said I'm new here -- it's possible the use cases for distinguishing /x and /x/ are much more frequent than I'm assuming they are.)

—
David Moles
UC Curation Center
California Digital Library

[aj...@virginia.edu]

I'm suggesting that such an auto-redirect facility (or any provision for making this particular choice) is not the job of the repository. It's the job of web machinery around the repository, akin to functions like caching or proxying.

---
A. Soroka
The University of Virginia Library

[David Moles]

Maybe it's URL-as-identifier vs URL-as-pointer again, but if you really do
want to treat /x and /x/ as identical I don't think that solves it. It's
fine if /x (or /x/) is the request URI, but what if it's the object of a
triple? You're now creating data that only makes sense in the context of
your redirecting web machinery.

And actually, on further reflection, I think redirects pose that problem
whether it's the web machinery or the repository doing the redirects. It's
not redirection, it's canonicalization. But maybe that's out of scope,
too, I don't know.

‹

David Moles
UC Curation Center
California Digital Library

>You received this message because you are subscribed to a topic in the

>Google Groups "Fedora Tech" group.

>To unsubscribe from this topic, visit
>https://groups.google.com/d/topic/fedora-tech/OjLO4XOkbPI/unsubscribe.
>To unsubscribe from this group and all its topics, send an email to

[aj...@virginia.edu]

I agree that we are talking about canonicalization, and that's yet another reason I don't think this is a good job for a content repository. This is indeed important stuff, but it belongs in a different area of the semantic tech ecosystem, perhaps a good triplestore or the like.

---
A. Soroka
The University of Virginia Library

[Andrew Woods]

Hello All,

This topic has been raised a few times on list, in person, at meetings (e.g. LDCX), and again in today's Fedora Tech call [1]. Typically, the topic is couched in the context of LDP best practices [2], and relative URIs, specifically. This current thread teases out some of the potential benefits as well as pitfalls of distinguishing between resources with (/x/) and without (/x) the trailing slash. 

All that said, I wanted to summarize the current position on the subject from today's Fedora Tech call participants, which is that there is no clear and overwhelming motivation to enforce trailing slashes on container resources at the moment. That may certainly change in the future. But for now, the associated ticket [3] will be on hold.

Regards,

Andrew

[1] https://wiki.duraspace.org/display/FF/2015-04-09+-+Fedora+Tech+Meeting

[2] http://www.w3.org/TR/ldp-bp/#include-a-trailing-slash-in-container-uris

[3] https://jira.duraspace.org/browse/FCREPO-1410

[Benjamin Armintor]

I'm still chewing on this. Hash URIs should also have containment, right? This would seem to require either bare container URIs or two terminal characters, and the former allows for both use cases, right?

[aj...@virginia.edu]

In this context, Ben, what do you mean by "containment"? Do you mean that the lifecycle of a hash-URI resource is contained within the lifecycle of the resource with the non-hashed URI?

---
A. Soroka
The University of Virginia Library

[Benjamin Armintor]

I am thinking about vocabulary authorship. If a resource has a relative URI of #Collection, it seems clear that it is contained.

[aj...@virginia.edu]

I'm sorry, I'm still confused: contained in what?

---
A. Soroka
The University of Virginia Library

[Benjamin Armintor]

Let's say that I'm pushing some RDFSources into Fedora.  One of them is a set of types:

<http://fedora.info/fedora-system:def/model> a ldp:DirectContainer.

There is a type defined in this set:

<http://fedora.info/fedora-system:def/model#Datastream> a ldp:RdfSource.

If we are supporting relative URIs, I should be able to:

POST /fedora-system:def/model HTTP/1.1

Host: http://fedora.info

Accept: text/turtle

Content-Type: text/turtle

@prefix ldp: <http://www.w3.org/ns/ldp#>.

<#Datastream> a ldp:RdfSource.

and assume that:

<http://fedora.info/fedora-system:def/model> ldp:contains <http://fedora.info/fedora-system:def/model#Datastream>

[aj...@virginia.edu]

So you mean contained in the LDP sense? Okay, but isn't your example assuming support for relative URIs that we don't actually offer?

I'm just trying to understand whether you are offering support for the "slashed approach" or a "slashless approach" or neither…

---
A. Soroka
The University of Virginia Library

[Benjamin Armintor]

Yes, I mean contained in the LDP sense. And my understanding of the supporting argument for terminal slashes on containers is that it centers on clarifying URI construction of contained resources, and what types of relative URIs might be supported.

[aj...@virginia.edu]

Hm. My understanding of the desire for terminal slashes is that they are claimed to look more like what most people expect on the Web. I haven't yet heard about use cases for relative URIs. Perhaps David Moles could speak to that?

---
A. Soroka
The University of Virginia Library

[Benjamin Armintor]

I don't think that is the claim, and the email originating this thread is about relative URIs.

[Robert Sanderson]

It does support relative URIs when creating resources.

If you POST to /rest with a Slug header of foo, the implication is you want /restfoo created.

The behavior (as of 4.1.1, grabbed today) is different for these operations:

$ curl -X POST -H "Content-Type: application/turtle" -H "Slug: foo" --data @temp.ttl http://localhost:8080/rest/

http://localhost:8080/rest/foo

$ curl -X POST -H "Content-Type: application/turtle" -H "Slug: foo" --data @temp.ttl http://localhost:8080/rest

http://localhost:8080/rest/f4/f0/6c/46/f4f06c46-9e99-4f1d-a908-d8f34c31a8f0

And conversely different for:

$ curl -X POST -H "Content-Type: application/turtle" -H "Slug: bar" --data @temp.ttl http://localhost:8080/rest/foo/

http://localhost:8080/rest/foo/3a/7b/ab/67/3a7bab67-81bb-439a-bd3c-797a2c58c636

$ curl -X POST -H "Content-Type: application/turtle" -H "Slug: bar" --data @temp.ttl http://localhost:8080/rest/foo

http://localhost:8080/rest/foo/bar

(Where the contents of temp.ttl is just a single triple "<> a oa:Annotation ." with appropriate @prefix in all cases)

Surely these operations should be consistent if the trailing / is *not* significant?

Rob

[aj...@virginia.edu]

Right. This is why I said it does _not_ support relative URIs. That doesn't look anything like a consistent pattern of support to me. That looks like a series of accidents. {grin}

> Surely these operations should be consistent if the trailing / is *not* significant?

I don't disagree with that. I would disagree that there is consensus that the repository should decide whether a trailing / is significant.

---
A. Soroka
The University of Virginia Library

[Benjamin Armintor]

Just as a sidenote: When I was testing Hydra against Lyo, I had to rely on a similar POST with Slug: to get containment to work the way the Hydra test suite expected it to, which was iirc no terminal slash, but the contained resource was slash-delimited.

I agree that the behavior should be consistent *somehow*, I'm just suspicious of a mandatory terminal slash. I'd probably feel better saying that it's incumbent on the client to Slug or relativize as ./foo or #foo, because it jibes better with what I *think* is our PUT expectation that

PUT /foo/bar

results in </foo> ldp:contains </foo/bar> (if /foo exists) and </> ldp:contains </foo/bar> if it doesn't? This was something I struggled with in the Lyo tests.

Making it the client's responsibility also makes it possible to transition from RdfSource to Container, and doesn't encode non-containment resource attributes in the URI - I think both of those would be virtues.

Just to be clear, though: The behavior Rob is documenting is a mess, and he is absolutely right that it needs to be fixed. Given the current state, we ought arguably to be 403 for relative subject URIs right now. 

- Ben

[Andrew Woods]

Hello Rob,

I just ran your example POST requests locally. The behavior you are seeing has nothing to do with slashes or no-slashes. It has to do with POSTing a resource with a slug when such a resource already exists.

For your first case of POSTing against: http://localhost:8080/rest[/]

* The first POST successfully creates a resource named /foo because none exists. You should see this same behavior with or without a slash after "rest".

* The second POST ignores the slug (per http://www.w3.org/TR/ldp/#h-ldpc-post-slug) and auto-generates a resource path because a "/rest/foo" resource already exists.

For your second case of POSTing against: http://localhost:8080/rest/foo[/]

* I am not able to replicate what you seem to be observing, assuming that the order of your two requests are as indicated in the email.

* What I see is the exact behavior as in the first example.

* Could you please re-verify your second example and provide more detail to help me do the same?

Thanks,

Andrew

[aj...@virginia.edu]

> I'm just suspicious of a mandatory terminal slash. I'd probably feel better saying that it's incumbent on the client to Slug or relativize as ./foo or #foo

+1. It does not seem feasible to me to make a really good universal choice on this question at the level of a content repository.

---
A. Soroka
The University of Virginia Library

[Robert Sanderson]

Yup, my fault for forgetting to delete the resource between requests!  Trying again with clean containers and different slugs each time worked as expected.

Apologies :)

Rob