W3C home > Mailing lists > Public > public-ldp-wg@w3.org > November 2012

Re: Creation of Containers

From: Henry Story <henry.story@bblfish.net>
Date: Thu, 8 Nov 2012 00:27:32 +0100
Cc: nathan <nathan@webr3.org>
Message-Id: <3D63C8F2-64EB-44D4-B9D4-6F763E69BDC7@bblfish.net>
To: Erik Wilde <Erik.Wilde@emc.com>, public-ldp-wg@w3.org

On 8 Nov 2012, at 00:12, "Wilde, Erik" <Erik.Wilde@emc.com> wrote:

> hello all.
> 
> On 2012-11-07 14:54 , "Henry Story" <henry.story@bblfish.net> wrote:
>> What we seem to have here is a problem of distinguishing content from
>> metadata, or rather knowing what the server is saying and what someone
>> else has published on the server.
> 
> that's what on the web media types are doing. i know that this is way
> outside of the scope of this group, but since we're saying REST in the
> charter, this is what we would be doing in a RESTful design: design a
> media type that represented the concepts we're building interactions
> around, and then making the distinction you're pointing out is done by
> virtue of the media type.

I think you are trying to put too much in the media types. The Media type
is just a way to interpret a document - i.e. to extract its semantics. 

> 
>> So either the server MUST parse RDF representations and take PUTs of
>> documents stating the resource is a container as orders to make that
>> resource a container, or one would have to specify that a resource is a
>> container, by placing such information elsewhere - in the header for
>> example, where it can be argued that the server is making the statement.
> 
> yup, and that would be the header signaling the media type.

As said above that would be like saying that servers MUST speak a different
language from the other documents they are serving, which seems arbitrary.

The real issue is that we just need to be able to distinguish when
the server is saying something from when someone else is saying 
something. Since the server Srv is responsible for creating resources knowing 
that it is saying C is a collection is a lot different from knowing Srv 
is publishing a document written by some agent A saying C is a collection.

In the OS we get the same. When I type 

$ pwd
/Users/hjs/Programming/Scala/scalaz-test
$ ls -l
total 16
-rw-r--r--  1 hjs  admin   50 20 Sep 13:26 README.md
-rw-r--r--  1 hjs  admin  491 29 Sep 17:18 build.sbt
drwxr-xr-x  4 hjs  admin  170 19 Sep 14:37 project
drwxr-xr-x  3 hjs  admin  102 19 Sep 14:49 src
drwxr-xr-x  4 hjs  admin  170 30 Sep 14:58 target

I know that the OS is giving me those answers

If I then copy that output to a file

$ ls -l > ~/out.txt
$ cd ~
$ cat out.txt

then I am just reading the contents of a file, which I created - that will have the same contents
as the results above, but it is said by a completely different agent. In one case an agent responsible for making resources and in the other case me.


> 
>> Perhaps there are ways to distinguish when the content is server
>> generated - such as a directory listing which is server generated.
>> Perhaps this could be done by giving the server a name and putting that
>> information in the header... Not sure...
> 
> i think this is where we run into the fundamental problem that we're
> trying to build a protocol without using the proper mechanisms, which on
> the web are media types.

Media types are not the only mechanism. They kind of get it right, because they are
looking to put information in the header. But the real issue is who is making the statement.

> i do realize that it is way outside our charter
> to solve this issue, since it is a general RDF issue and has nothing to do
> specifically with LDP. but this issue does pop up in a variety of places
> where people try to build protocols around RDF, and maybe we could ask the
> RDF working group about some guidance. so far i've seen little
> understanding of the problem and little willingness to fix it, but maybe
> at least they have some hacks we can reuse.
> 
> cheers,
> 
> dret.
> 

Social Web Architect
http://bblfish.net/



Received on Wednesday, 7 November 2012 23:28:11 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:11:42 UTC