W3C home > Mailing lists > Public > public-ldp-wg@w3.org > June 2013

Re: Discovery/Affordances (Issue-32/Issue-57)

From: Kingsley Idehen <kidehen@openlinksw.com>
Date: Tue, 11 Jun 2013 16:41:29 -0400
Message-ID: <51B78B79.6040604@openlinksw.com>
To: public-ldp-wg@w3.org
On 6/11/13 4:06 PM, Henry Story wrote:
>
> On 11 Jun 2013, at 21:42, Arnaud Le Hors <lehors@us.ibm.com 
> <mailto:lehors@us.ibm.com>> wrote:
>
>> [snip]
>>
>> I already explained why I'm proposing to use a Link header with an 
>> LDP profile and discussed what this would entail. It is as simple as 
>> one can hope for. All it means is that if a response you get from a 
>> server contains a link to that profile you can expect the server to 
>> be LDP compliant.
>
> What does the "server" have to do with this? LDP describes resources ( 
> LDPRs ) not servers. A server could
> have just one LDPR in it or one LDPC with a few LDPRs, in a sea of 
> HTML resources. When you get
> HTTP headers on a HEAD, GET, etc... these are only valid for that 
> resource, not for the entire web site.
>
> So what you really want is a way to describe that an LDP Resource is 
> an LDPR, or an LDPC an LDPC.
>
> Now you want to do this with a header
>
>   Link: <http://www.w3.org/ns/ldp#Resource>; rel=profile
>
> which would be the equivalent semantically to
>
> <> ldp:profile <http://www.w3.org/ns/ldp#Resource>
>
>
>> Isn't that something you can live with?
>
> Is that what you want?  The proposal has not been made clear yet.
>
> How is that such a great improvement over
>
>  <> a ldp:Resource .
>
> ie:
>
>   Link: <http://www.w3.org/ns/ldp#Resource>; rel=type
>
> What is the difference?
>
> Or is it that the spec author for RFC6906 would like us just to
> mention his spec in our spec?
>
> Social Web Architect
> http://bblfish.net/
>

Arnaud,

What Henry is painstakingly explaining to you is the fact that we have 
arrived at the same destination. We've had a massive debate that has 
simply ended at the very same place i.e., if this is about RDF and 
Linked Data then should that be the mechanisms that drive the system? 
The semantics of RDF have nothing to do with Media Types, the profile 
solution demonstrates that in the clearest way.

You are supporting the use of a Link: header. The Linked: header is 
basically an RDF triple, it carries all the semantic prowess of RDF, it 
just happens at the HTTP level. Using Link: relations to express RDF 
semantics is something we added to DBpedia eons ago as part of an effort 
to also get RDF community members to understand and appreciate the 
distinction between Semantics and Notation Syntaxes for expressing 
and/or encoding RDF data.

Do you really consider it appropriate to treat people that are going to 
immense lengths to protect the integrity of this effort, in this manner?

All Erik does is point to informative (mostly) specs that just add loops 
to the same debate. If I recall, this is a W3C effort and it was/is 
supposed to be based on RDF and Linked Data. Instead, it continues to 
feel like an effort that (at best) presumes RDF is a format (like XML) 
while Linked Data is nothing more than an alluring buzz-phrase.

RDF and Linked Data have meaning. Their greatest prowess lie in the fact 
that this entire thread could be compressed down to a debate about the 
entity relationship semantics described by the LDP vocabulary. That's it.

Henry has never inferred that the semantics couldn't be surfaced at the 
HTTP level. He has simply sought to ensure the semantics are intact.

Links:

1. http://bit.ly/11UrvYW -- URI Debugger output for a DBpedia Linked 
Data URI
2. http://bit.ly/13lcdAM -- DBpedia URI passed through Vapour (a Linked 
Data URI verifier).

-- 

Regards,

Kingsley Idehen	
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen







Received on Tuesday, 11 June 2013 20:41:54 UTC

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