Re: An IRC discussion with Alexandre Bertails re SSUE-19:

On 6 Jun 2013, at 02:10, Alexandre Bertails <> wrote:

> Hi Henry,
> On 06/05/2013 05:39 PM, Henry Story wrote:
>> On 5 Jun 2013, at 20:26, Alexandre Bertails <> wrote:
>>> On 06/05/2013 02:05 PM, Henry Story wrote:
>>>> Well, I just proved it from basic principles. You can decide not to
>>>> be convinced, but that is beyond the reaches of reason then. If you
>>>> explained what did not convince you then one could progress.
>>> Henry, I just wanted to make clear that I didn't agree that you proved
>>> anything. The same questions remain: text/turtle does not tell you
>>> that you can infer the interaction with a resource by looking at its
>>> RDF type.
>> Whoever told you that a mime type should tell you anything about how
>> to interact with a resource?
> The answer starts with the Media Types specification [1]. It tells you
> what you should do when you find text/turtle. Basically, you have to
> consult the central registry. The current one for Turtle is at [2] and
> refers to the Team Submission at [3]. I guess it will point to the
> Recommendation when the spec reaches that stage (I don't know the full
> process).
> In other terms, text/turtle is just Turtle, which is just a
> serialization for RDF among others. And to find out what I can do with
> Turtle, one just has to read the Turtle specification, which itself
> refers to RDF.
> That's basically what happens all the time on the Web. Other people
> will follow the same path. And that's why my recurring question is:
> where can somebody find the interactions defined by LDP (or even the
> SPARQL Graph Store protocol) when reading those specs?
> Webarch [4] also recalls this scenario.
> [1]
> [2]
> [3]
> [4]

Well that's my point: mime types are not the place to look
at to find interaction patterns with web resources! That is
not at all what they are designed for. 

>> The role of the mime type is just to tell
>> you what the type of the bytes in the body that constitute the
>> representation returned by the resource are. That and a few other
>> headers will allow you to parse those bytes to reconsitute the media
>> sent to you.
> That's right: text/turtle just tells me that I have some RDF
> serialized as Turtle. Nothing more.


>> Where do you get the idea that mime types should do anything else? (spec
>> text to  support your point of view would be helpful here).
>> Put it another way: if you did put the information in the mime type that
>> the resoure was an LDPC, using your hypothetical
>>    text/turtle+ldpc
> I agree that this approach would not work. And that's why we were
> proposing application/ldp+turtle instead! By the way, if you read the
> Media Types specification, you'll learn about the meaning of text and
> application as top-level media types.
> The specification that speaks about the suffixes is at [5]. Basically,
> we would just need a new entry for +turtle at [6].
> [5]
> [6]

But that makes no difference to my point. You are trying to 
make media types give you interaction semantics with resources,
when they are not designed to do that. 

Remember your main question in the transcribed IRC session, which you
repeat below was: how do I know that the content sent to me by the
resource is correct? Well my argument here is that even if you COULD express
the type of the resource with the Content-Type, it would in no way help 
you with that problem since the Content-Type could also be erroneous.  

>> why would that be any more reliable about  the resource being an LDPC
>> than the content of a text/turtle graph just containing the triple
>>   <> a ldp:Container .
> Let's say that looking at the RDF types is the way to go, just for a
> moment:
> * how do I know that <foo> is an LDPR?
> * how do I know that <foo> is neither an LDPC nor an LDPR?
> * how do I know that I can interact with <foo> using the SPARQL Graph Protocol?
> * if I find out that <foo> a ldp:Container while looking at <bar>,
>  should I consider this information as authoritative?

Knowledge of some proposition requires at the very least that the proposition
be true. So consider the proposition { ldpr a ldp:Resource } 
It does not matter how you arrived at the proposition, perhaps God whispered
it into your ear. Perhaps you deduced it from first principles on the basis
of your new conception of physics, and your knowledge of the state of the universe
at the Big Bang. Or perhaps you just did an HTTP GET on ldpr and it returned a
graph containing { <> a ldp:Resource }.

So what does it mean for that proposiation to be true? The RDF semantics
spec tells you that the above is true if the subject is a member of the 
set of objects referred to by ldp:Resource.

What is the set of ldp:Resources? Well that is what the LDP spec 
is meant to tell us. It gives us the criteria for what it is to be an LDPR. 

( My feeling is that  the following should be criteria for being an LDPR:

1. perhaps we should extend ISSUE-79 and require that LDPRs should return 

  <.> ldp:contains <> .

And ISSUE-73 the LDPC referred to above as <.> SHOULD contain

  <> ldp:contains <ldpr> .

2. ISSUE-50 on intutitive containers 
  would meant that POSTing a resource to an LDPC would return a short name

3. an LDPR must be PATCHable, or failure to do so must be an access control

4. if you DELETE an LDPR it is removed from its ldpc which you can discover 
   through the { <> ldp:contains <ldpr> } relation 

Whatever the criteria the LDP spec ends up defining, they will tell us what 
it is to be an LDPR.

Next your question is epistemological: how do we know it is true? So this
is one step further. Robert Nozick's defintion of knowledge was that

S knows that p if and only if
 (1) p
 (2) S believes that p
 (3) If p were not the case then S would not believe that p

So here there are many ways of knowing that some resource is a LDPR.
The most direct way is to write the software that runs your server and to
have run all the tests required by the LDP spec on it.

More indirectly most clients will only ever find it easy to find out
when something wrongly claims it is an LDPR when they fail to interact
with it in the correct way.

>> After all mime types could also be wrong ( especially as you are adding
>> semantic information now to the mime type, rather than syntactic
>> information ! )
> You're not supposed to override the semantics for a mime-type. The
> only exception that I know of is HTML5 which defines sniffing.

That's why we suggest you stick to text/turtle. You don't need 
anything else. Anything else, is confusing syntax with semantics frankly.

>> So text/turtle+ldpc does not give you any more reliable information that
>> putting the information in the body.
>> If you want it in the header than just use the Link header to put that.
> The Link header is used to describe the relationship with other
> resources and that's another use-case. See [7].
> [7]

The link header allows you to relate the resource to the type ldp:Resource.
If you do that then you can say that the resource is an ldpr in the header.

Link: <>; rel=""

>> The mime type is to describe the type of the body of the HTTP message.
>> But what we need to do is describe the resource which we are going to interact
>> with. That is what Resource Description Framework is for.
> I'd be happy to be pointed at the spec that explains how this works
> in our case.

Just Read the RDF Semantics spec. It tells you what it is for an RDF
statement to be true. So if some resource tells you that another or itself
is an ldp:Resource then it is true if that resource acts the way the ldp
spec says it MUST .

> Alexandre.
>> Henry
>>> Alexandre.
>>>> Social Web Architect
>> Social Web Architect

Social Web Architect

Received on Thursday, 6 June 2013 04:08:02 UTC