Open slorber opened 10 years ago
yes, the code should already do that. Each resource should contain a link to the parent with
<parent> ldp:created <>
It may be better to move this relation to HTTP with a link header, rather than placing it in the body.
Note: The LDP WG is about to vote on the ldp:contains
relation to replace the ldp:created
relation.
From http://www.w3.org/DesignIssues/CloudStorage.html
In our Stample model, stamples are containers which can have child stamples. A bit like an unix filesystem.
When you access a stample resource, you should be able to:
Imagine the following unix filesystem:
When accessing dir2, you should be able to know that dir1 is the parent (which maybe also have parents), and you should be able to know that it contains dir4, file1 and file2
So what is the way to handle reverse linking? Is there some convention for LDPC based on the resource URI? I mean if URI is /dir1/dir2, then dir1 is implicitly a parent of dir2?
On some over pages I can't find anymore, TimBL mention the fact that reverse linking is useful for navigation but this duplicates the information. This means that we can have inconsistencies. dir2 can say it has dir4 as a child, but dir4 says it has dir1 as parent. How can we deal with such inconsistencies?
So according to the navigation constraints on Stample, we should think of an elegant way to create reverse linking between stamples and their childs.
Any idea?