W3C home > Mailing lists > Public > public-ldp-wg@w3.org > January 2014

Re: rel=type or rel=profile

From: Alexandre Bertails <bertails@w3.org>
Date: Wed, 15 Jan 2014 09:17:04 -0500
Message-ID: <52D69860.20907@w3.org>
To: Henry Story <henry.story@bblfish.net>, "Linked Data Platform (LDP) Working Group" <public-ldp-wg@w3.org>
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.


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


> 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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:17:47 UTC