W3C home > Mailing lists > Public > public-webid@w3.org > May 2013

Re: Archaic HTTP "From:" Header

From: Kingsley Idehen <kidehen@openlinksw.com>
Date: Mon, 27 May 2013 10:30:36 -0400
Message-ID: <51A36E0C.10809@openlinksw.com>
To: public-webid@w3.org
On 5/27/13 10:10 AM, Nathan wrote:
> Henry Story wrote:
>> On 27 May 2013, at 14:29, Melvin Carvalho <melvincarvalho@gmail.com> 
>> wrote:
>>
>>>
>>>
>>> On 27 May 2013 14:17, mike amundsen <mamund@yahoo.com> wrote:
>>> Register "webid" as a Link Relation Value and ese the LINK header as in
>>> Link: <http://...." rel="webid">
>>>
>>> This will make sure you don't step on someone else's header, no-one 
>>> will step our yours. This will also allow you to include it in the 
>>> header and (when appropriate) include it within a message body.
>>>
>>> That could work so how about
>>
>> The text below looks good, but the question is what is the relation 
>> between the content sent and the WebID? A WebID is a URI denoting an 
>> Agent.
>>
>>  https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/identity-respec.html
>>
>> But what the rel=.... requires is what you need to define. "rel" stands
>> for _relation_ .
>>
>> You can use establised RDF relations such as
>>
>>   dc:author
>>   dc:contributor
>>   foaf:maker
>>   ....
>>
>> Using any of those in the link header comes down to saying respectively
>>
>> <> dc:author mywebid .
>> <> dc:contributor mywebid .
>> <> foaf:maker mywebid .
>>
>>
>> Or you could use the existing relations in the registry
>> http://www.iana.org/assignments/link-relations/link-relations.xml
>>
>> In short I don't think that WebID is a relation. It is a subset of URIs.
>
> Same thing. The set of all URIs which denote agents is created by 
> looking at those uris which are related to some things by a relation 
> which implies they are of that set.
>
> { ?x foaf:maker mywebid . } => { ?x a :Agent }
>
> +1 for mike's suggestion of a relation.

Why do we need to register a Relation when we already have those defined 
across a plethora of shared ontologies. There isn't a single canonical 
Relation here. Also note that "related" is already registered and that 
as generic a Relation that there is.

> It works, it's extensible, it can be sub classed, and it doesn't 
> encourage a plethora of additional headers which have no bearing on 
> the protocol (http). 

I think you mean using Link Relations which is workable today, but 
limited i.e., it fails to address the needs for those with R-D-F reflux 
syndrome :-)

> This is what Link was made for, it works and there's no technical 
> reason not to do it.

Link Relations via Link: headers works, it was made for extensibility 
etc.. But in our case, we just wanted to negate the need for full 
commitment to RDF semantics comprehension while also hooking in WebID. I 
am already resigned to the fact that this requires an alternative 
solution. One that I am working to get implemented as I type. I am 
simply going back to "just do it!" mode, since attempts to make non 
disruptive tweaks to existing specs is eternally bogged down by 
artificial control points and controllers (folks refusing to grok and 
accept the flaw in "From: ".

I am less frustrated when in "just do it!" mode, since attempts to share 
and cajole have failed me eternally, sadly etc.. So its back to 
implementation work, this whole thing will happen, and the controllers 
will eventually see the folly in their decisions. Sorry to be harsh, but 
the controllers are doing the broader community an utter disservice.

Never undermine the ingenuity of an engaged cognitive human being. 
That's the closest thing I know to an irrefutable fact :-)

>
>


-- 

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 Monday, 27 May 2013 14:31:05 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:54:43 UTC