Re: rel=type or rel=profile

On 01/15/2014 06:33 AM, Henry Story wrote:
>
> On 15 Jan 2014, at 10:43, Henry Story <henry.story@bblfish.net> 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.

> 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?

> 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.

> 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?

Alexandre.

>
>
> hope that helps,
>
>
>
> 	Henry
>
>
>>
>> Henry
>>
>> Social Web Architect
>> http://bblfish.net/
>>
>
> Social Web Architect
> http://bblfish.net/
>
>
>

Received on Wednesday, 15 January 2014 14:16:28 UTC