On 21/12/12 12:00, Sebastian Schaffert wrote:
Hi Andy,
I see a fundamental discussion here. As soon as you work with Linked Data
(in any kind, not only containers) your point of view automatically gets
"resource centred" while most triple stores are purely "triple centred": in
a triple store, the existance of a resource depends on the existance of at
least one triple, while in Linked Data it is in principle possible to have
a resource with no triple at all (even though this is probably not a very
interesting case - a bit like the empty set in maths, not really useful but
constantly getting in the way ;-) ). And if you connect this with content
management, this actually can make sense (e.g. a page in a semantic wiki
does not need to have a triple initially).
I agree - the problem is that a mathematical graph is a set of nodes and
a set of edges. RDF dropped the explicit set of nodes - or made it all
possible URIs - and sometimes this shows up. It did when defining
SPARQL property paths - you have to talk about the node set of the graph.
In the LMF, we therefore had implemented a triple store with a separate
notion of "resource". You could create and delete resources independently
from triples. Since I wanted to be able to use different (more scalable,
better tested) triple stores as backend, I am now trying to think of ways
how to "weave" this resource concept into the existing APIs. But I admit it
makes the data model a whole lot more complicated, especially if you also
want to think about which container a resource belongs to, who "owns" a
resource, etc.
The LDP people apparently have found a way that tries to bridge the two
concepts by introducing containers, where each resource has at least one
triple relating it to the container it refers to. Personally, I am not a
big fan of this approach, because it looks a bit like a "hack". I can also
imagine that the strong containment notion comes from REST, it would fit
the REST approach (with hierarchical URIs) very well. However, I agree with
you that the strong containment is not a convincing solution.
The more I delve into this , the less I like strong containment. Seems
better just to use a garbage collector if resource reclamation is needed.
Containers are doing something else as well, which is POST-create-name.
That allocates a name - some of the more interesting examples
associate a URI template with a container:
/report has a template of /bug/{N}
POST /reports
... ...
->
Location: /bug/12
Things do trip up over the use of <> in the posted content by my strict
reading of HTTP 2616 but I see the use of <> to mean the new location as
a useful "wilful violation" (aka do the right thing).
Somehow I also wonder how the LDP containers relates to the concept of
named graphs as originally found in SPARQL but now also implemented in
several of the triple stores (Sesame has it in the API directly).
When working on Marmotta, I think that we do not need to strictly limit
ourselves to the LDP recommendation. If we think that there are worthwhile
extensions to the recommendation, we can offer them. If there are
restrictions (like strong containment) that we think are inappropriate for
many use cases, we can make them optional/configurable. In the end, the
project is mostly about usable software ;-)
I believe the LDP spec is going to be minimal - any real system which
implements it is going to have to add a lot more and quite possible
interpret the spec.
Andy
I like your playlist example, btw. Another example would be groups/roles of
a user. ;-)
Greetings,
Sebastian
2012/12/20 Andy Seaborne <[email protected]>
What do people think about LDP Containers?
The LDP-WG has debating "containers" for ages and it is still going on.
At the face-to-face they decided on "strong containment" meaning if you
delete the container, then the resources in the container also gets
deleted. That is, there is management of resources.
Links to un-managed things don't fit this model very well, if the links
are in the same LDP platform.
(think of playlists with songs from your music library in them)
Any insights here?
Andy
