- From: David Wood <david@3roundstones.com>
- Date: Tue, 14 Oct 2014 16:30:12 -0400
- To: Sandro Hawke <sandro@w3.org>
- Cc: "henry.story@bblfish.net" <henry.story@bblfish.net>, Linked Data Platform WG <public-ldp-wg@w3.org>, James Leigh <james@3roundstones.com>
Hi Sandro, Please let me know if any of this should be duplicated or moved to public-ldp-comments. On Oct 13, 2014, at 16:37, Sandro Hawke <sandro@w3.org> wrote: > [moved to the WG mailing list, since we're all in the WG.] > > On 10/13/2014 03:26 PM, David Wood wrote: >> Um, I believe that Callimachus now passes all the Indirect Container tests. We submitted a revised implementation report that hasn’t been posted yet. >> >> Please don’t remove Indirect Containers. > > David, I'm wondering if you can make the case to me and the other doubters in the WG for Indirect Containers. I haven't heard any stories yet of people wanting to make and use LDP containers full of Non-Information-Resources (ie using Indirect Containers). My instinct is that doing so is more of an intellectual exercise than something which practical software engineers would have reason to do. My instinct is also that it's conceptually rather more complicated to work with than one would want in a production deployment. We have an existing implementation that we are migrating to support LDP. Others who are not producing a green fields implementation will have the same problem. Some of our implementation decisions have included the need to expose stable URLs and URL patterns. We owe it to our user base not to radically change them because that would break people’s scripts, backups, etc. That means we have a problem when we try to handle LDP URLs since operations on them don’t always map 1:1 with Callimachus URLs and operations. Callimachus is likely to always support more types of operations than LDP. Thus, we have a mismatch between some of our URLs and the Callimachus operations on them and the LDP URLs and operations. For example, we have a Callimachus folder, which is conceptually just like an LDP container. However, the operations don’t align. So, we have made a new thing in Callimachus that is an LDP container that has a new URL and operations assigned to it. A triple (foaf:primaryTopic) links a container to a folder. You can see the triples for a typical folder/container relationship at: http://callimachusproject.org/?describe A recent side conversation with James Leigh produced this useful quote from him. I hope you consider it or at least add it to the LDP Next wiki page: [[ Since the WG admits to needing two different URLs for media, one would think they could have also come to the same conclusion with non-information-resources, like we did for callimachus. It's interesting that their LDP-RS discovery method from LDP-NR is almost identical to callimachus', which is to use Link header rel describedby. I just wish LDP-RS had the same indirection from its containment/membership triples as LDP-NR. ]] > I know you and your team are, in fact, practical software engineers who work in a production environment, so I'm hoping you can share your reasoning/experience here. What classes of resources do you put in Indirect Containers? The important thing to realize here is that Callimachus is triples all the way down. However, we don’t want just anyone fiddling with triples that are core to how our system operates. Thus, we restrict access to some parts. The direct answer to your question is that the following resource types are stored and manipulated as RDF, but are not allowed to be manipulated directly as RDF by users. They are non-information resources for the purposes of LDP. - SKOS Concepts - OWL Classes - user accounts that have a local representation (those using HTTP Digest authentication) - groups of users - folders (which have a reverse foaf:primaryTopic relationship to our implementation of LDP containers) - user profiles (in Callimachus Enterprise only) All of these have RDF descriptions in Callimachus, but they are not treated by us as information resources. Instead, they have representations in the user interface but are not directly manipulatable via our REST API or LDP’s. Although they are really RDF, you need to go through our interfaces (either our REST API or our UI, with some restrictions for some types) in order to modify them. In fact, all of our resources, information resources or non-information resources, are put into the same IndirectContainers. This is because Callimachus folders have been modified to have LDP containers. > What ldp:insertedContentRelation predicates have you been using? foaf:primaryTopic > What are the application semantics to being in the container? (IE, how do applications respond when the triples change as they do in response to an HTTP DELETE of the resource, etc.) A DELETE causes the deletion of both in and out relationships to the deleted resource. Our PROV bundles are stored in separate named graphs, so they are not deleted at that time. They are deleted on a separate schedule. We use a GRAPH to represent a PROV bundle in our operations so concurrent changes go into the same graph. Most of our other operations are driven by SPARQL queries at runtime, so they pick up changes as necessary when cache is invalidated. Regards, Dave -- http://about.me/david_wood > > Thanks! > > -- Sandro > > >> Regards, >> Dave >> -- >> http://about.me/david_wood >> >> >> >> On Oct 13, 2014, at 14:40, henry.story@bblfish.net wrote: >> >>> There was a discussion today that the Indirect Containers may be removed because >>> the 2 implementations don't pass all the tests. >>> >>> Which tests do they not pass? >>> Do those implementations think they'll get it done in the next week? If not when? >>> >>> Henry Story >>> >>> Social Web Architect >>> http://bblfish.net/ >>> >>> >> >> > >
Received on Tuesday, 14 October 2014 20:30:39 UTC