Re: rel=type or rel=profile

On 15 Jan 2014, at 15:17, Alexandre Bertails <> wrote:

> On 01/15/2014 06:33 AM, Henry Story wrote:
>> On 15 Jan 2014, at 10:43, Henry Story <> wrote:
>>> Hi,
>>> The request to change from rel=type to rel=profile should really
>>> be a new issue. Could the person asking for this open a new one,
>>> then we can gather the arguments for it and I can respond to them
>>> ( or agree with them of course ).
>> Ah sorry, it does have an issue. Issue-92.
>> The Issue says:
>> "Indeed, until we closed action-122 the spec even said these were notionally equivalent."
>> I am not sure why that was removed if it was. The resolution was that "for an LDPC the link header is
>> type=LDPC". There are many reasons to put this in the header:
>>   the client does not need to read through the whole document to find out if the resource is an LDPC/LDPR
>>   (similarly if the client sends the header in a POST this allows the server not to have to read the whole body before
>>    deciding if the resource is of one form or the other )
>>   a reason to place this in the header is that it is the server making a statement about the
>>   resource, and so this is best placed in the metadata ( the space where the server makes statements
>>   about the content ). If we think of it that way, then it makes sense that if a server makes a statement
>>   about a resource being an LDPC then this outweighs statements made in the document.
> You say here that it's ok for protocol-related data (or server-managed
> metadata) to be sent through the HTTP headers (which I agree with) but
> you still try to make the case for rdf:type in the rest of your email.

Well I am waiting for an argument against rdf:type that stands up to reason.
The status quo is rdf:type in the header for ldp:Resource for quite a while,
and for ldp:Container now.

>> None of this requires one to come to the conclusion that the set of things that are LDPCs are not resources
>> for which particular interaction models are defined. The whole LDP spec descriptes these LDP Resources and their
>> interaction models.
> [snip]
>> Now my question is: why would ldp:ContainerInteractionType not just be the ldp:Container class?
>> And if it were not, then you'd still end up with a class, namely ldp:ContainerInteractionType, which would
>> be the class of all things that had ldp:Container Interactions. So that the relation of an individual
>> to a class can define its interactions. QED.
> I may want to POST { <> a ldp:ContainerInteractionType } and still not
> want the LDPC interaction, so how would it change the problem?

Well that is my point! :-)  If you remember the ldp:ContainerInteractionType
was defined by starting off from the relation that you are suggesting should
be the one replacing rdf:type in the header. This could be the "profile" 
relation or some other type. I suggested calling it ldp:interactionRelation 
for the sake of argument. Then from such a relation one could always define
a new type which I called ldp:ContainerInteractionType by the simple
owl statement below you snipped:

ldp:ContainerInteractionType a owl:Class;
   owl:equivalentClass [ a owl:Restriction;
                 owl:hasValue ldp:Container;
                 owl:onProperty ldp:interactionRelation ] .

In SPARQL this would amount to something like the following

CONSTRUCT { ?ldpr a ldp:ContainerInteractionType }
 ?ldpr ldp:interactionRelation ldp:Container .

So creating a new relation ( profile or ldp:interactionRelation ) won't change your 
so called problem: you'll always end up with some class of resources which can be 
interacted with  using the LDP protocol, and your argument will then have to be 
applied to that class of  resources.  As you point out whether you name 
the class of these resources ldp:Container or ldp:ContainerInteractionType
you have the same issues. 

So either the problem you are defending is correct and it is insolvable, or 
it is incorrect and everything is fine. I'd suggest going for the second one :-)

In short: the argument that rdf:type is problematic does not hold.

Now above you lay out a different issue. You want to post a content containing 

 <> a ldp:ContainerInteractionType

but you do not want the server to have the ldp:Container interactions 
with that resource. Note that this same argument could be made in terms
of the relation ldp:interactionRelation: You could ask what should happen
if you POST 

 <> ldp:interactionRelation ldp:Container .

to an LDPC? Or what about POSTing a graph containing

 <> x:profile ldp:Container .


 (Apart from this being a weird use case for which I don't think a good 
enough case has been made.) there seem to be parallel  answers to the server 
interaction scenario that could be made. For example the server could decide 
to treat the created resource as an LDPR only if the POST header contained 
the following relation:

Link: <...#Container>; rel=type

in the header. Why would that not work? And how would swithching to a relation
other than rdf:type such as ldp:interactionRelation make any improvement 

>> Furthermore  one has to understand that statements on the web can be false.
>> For example in Example 5 of our current spec we have the </netWorth/nw1/> resource
>> make a statement about two LDPCs <assetContainer/> and <liabilityContainer/> , and
>> that these are LDPCs. Say someone deletes those two, and that there is a bug in the system,
>> or a delay somehow. Then the </netWorth/nw1/> could be describing those resources as LDPCs
>> falsely. Well that's just one type of bug: a false description of the world.
> Or we could also make the statement true only and only if one sees the
> "Link <...#Container>; rel=profile" when she does a GET/HEAD on the
> resource... I don't think we have to go that far.

The current state of the spec is that when a server makes a statement
in the header of a HEAD, GET, OPTIONS of a resource that

Link: <...#Container>; rel=type

then this is a statement by the server about the interaction types of the
resource. Clearly if the server does not then offer the interactions then
well the server is broken, and it is time to report a bug on the server 

>> There are a number of further arguments I could make, but I think this will do for the moment.
> I don't see any argument against the proposal (going from rel=type to
> rel=profile), does it mean that you won't oppose to it next time?

I don't see any good arguments against rdf:type. The argument made
against rdf:type that I have heard would be so strong as to invalidate
any argument for another  relation such as "profile" or a hypothetical 
ldp:interactionRelation as shown above. You need to give a reason against
rdf:type that does not simultaneously invalidate the solution you want to
introduce as an antidote. :-)


> Alexandre.
>> hope that helps,
>> 	Henry
>>> Henry
>>> Social Web Architect
>> Social Web Architect

Social Web Architect

Received on Wednesday, 15 January 2014 15:07:41 UTC