Re: a totally minimal RDFa doc, please

> On 14 Apr 2011, at 18:03, Kingsley Idehen wrote:
>
>>> On 14 Apr 2011, at 17:41, Kingsley Idehen wrote:
>>>
>>>>> (I generated the page from the second tab of http://x509.me
>>>>> The test a certificate option. My cert was generated of the first page (optional). My cert had a SAN pointing to a blank page to start with. Press the test button on the second tab. It fails as it was a blank page and spits out the rdfa required for it to pass. Cut, copy, paste.)
>>>>>
>>>> I just tested the service above.
>>>>
>>>> Results:
>>>>
>>>> 1. HTTP scheme WebIDs - Pass
>>>> 2. Non HTTP scheme WebIDs - Fail .
>>>>
>>>> WebID is not about HTTP scheme WebIDs, solely. Courtesy of WWW ubiquity, HTTP scheme WebIDs are a very cost-effective *option*. Important downside: they are unintuitive.
> [WebId's are no less unintuitive that webfinger, not when they are hidden in a certificate. In both cases point an click a cert selector and you are done. But let's discuss that another time.]

My key point (very very important): verification shouldn't be scoped to 
HTTP scheme based WebIDs. If a service takes that position it has to 
make it crystal clear. Failure to do this simply reeks of coercsion.

As I've stated already, HTTP scheme URIs are cost-effective, naturally, 
due to WWW ubiquity. That still doesn't justify specificity when dealing 
with WebID.

Of course, we can (right now) decide that WebID is about HTTP scheme 
URIs as WebIDs, no problem, but lets be crystal clear about these 
matters right now.

mailto: and acct: scheme URIs are more intuitive than HTTP scheme URIs 
becuase of user history. Most important of all, we want to WebIDs to 
spread via minimal disruption to what's already out there (physically 
and mentally).
>>>> Basically, the problem addressed by WebFinger and Fingerpoint. Thus, we must stick to URI scheme agnosticism re WebID verification.
>>> yes, but not everybody has time to implement all the other schemes, which have not yet undergone the same level of scrutiny. Let us get the test cases and documentation for https webid's under our belt, then we can move to the other schemes.
>> Henry,
>>
>> You know that comment above just isn't right.
> How? Many of us have not had time to implement other schemes than https, and even for https webids we don't have good test cases yet where we can clearly affirm we are all compatible.

That isn't the point. You are speaking as a programmer. I am talking 
about architecture.

>   This is very clear from the e-mail on this list recently to do with issues on X509 certificates, issues on profiles, and so on.
>
>> You're making an excuse for specificity that's tainting the job at hand, potentially. Of course, if WebID == HTTP scheme based Agent URIs, solely then fine, let's be very clear and upfront about it from the onset.
> We don't close any doors, you know that.

I don't think so anymore, seriously.  I find myself pounding the door 
reminding folks to stick to openness of core architecture at little too 
often these days :-(

Again, specificity has to be advertised rather than disguised when the 
encompassing architecture is supposed to be inherently open.

I've done a zillion iterations of this over the years, and I am 
concerned about this turn of events.

Example:
ODBC Drives were supposed to be RDBMS agnostic. We ended up with a flood 
of RDBMS specific ODBC Drivers or generically useless ODBC drivers, net 
effect, the standard stood on week foundation re. market longetvity.

What we are doing here is no different to ODBC Drivers, we just aren't 
talking to DBMS engines, instead we are dealing with Identity and 
Identity verification via an Identifier mechanism and a lookup oriented 
protocol.
> But this is a W3C group here. We should  have a spec written out clearly with test cases so that people can claim to implement it, otherwise it's just hot air.
> Given that we have to start off somewhere let's do what we have the most implementations for, which is https.

Test cases shouldn't encourage coercion (deliberate or inadvertent).
> As soon as we have that we can move to the next issues. This should not take so long to do. It's just a bit tedious. It'll get faster as soon as we are done.
>
>> The path to NetID is a no-brainer for me if we want to play around with labels, syntax, and semantics :-)
> I am not restricting how webid works. Just what we can concentrate on first.

Who is "we" ? You are kinda speaking for everyone when you say that.

>   Don't forget how this thread started. You were telling Akbar Hossain off for only supporting only one scheme.

I wasn't telling him off, I was asking (in shock): why is WebID now 
having undesired specificity. Why did I have to test a comination of 
certificates (time consuming++ due to lousy brower handling of SSL/TLS) 
to realize that HTTP scheme specificity was the issue.

>   I think Akbar having done openid4.me is very aware that other protocols have their role to play.
>

Am I missing something here re. WebID protocol. Is it supposed to be 
scoped to WebID URI scheme or not? It just might be that I am completely 
misunderstanding the protocol etc..

Again, more then anything else, I seek clarity.

Basically, is this about HTTP scheme URIs solely or not? There's no 
right or wrong answer here, I just need to know what the position is. I 
like to be crystal clear when travelling the murky waters of "openness" .

>> Why do you think we're spending time on all of these protocols?
> We have been talking a lot and working at the human knowledge level. Now we need to automate these tests, so that we can move onto other topics - such as webfinger for example.

Not WebFinger, but URI scheme agnosticism, assuming that fits into what 
WebID is about. At this juncture, seriously now, I am very unsure. Note, 
being unsure has nothing to do with my committment to WebID, its has 
everything to do we me being 100% clear about what this effort is about.

I already have massive headaches with Linked Data != RDF. I don't need 
another re. Scheme agnostiscm and WebID.


Kingsley
> Henry
>
>>
>> Kingsley
>>>> -- 
>>>>
>>>> Regards,
>>>>
>>>> Kingsley Idehen	
>>>> President&    CEO
>>>> OpenLink Software
>>>> Web: http://www.openlinksw.com
>>>> Weblog: http://www.openlinksw.com/blog/~kidehen
>>>> Twitter/Identi.ca: kidehen
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>> Social Web Architect
>>> http://bblfish.net/
>>>
>>>
>>
>> -- 
>>
>> Regards,
>>
>> Kingsley Idehen	
>> President&   CEO
>> OpenLink Software
>> Web: http://www.openlinksw.com
>> Weblog: http://www.openlinksw.com/blog/~kidehen
>> Twitter/Identi.ca: kidehen
>>
>>
>>
>>
>>
> Social Web Architect
> http://bblfish.net/
>
>
>


-- 

Regards,

Kingsley Idehen	
President&  CEO
OpenLink Software
Web: http://www.openlinksw.com
Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca: kidehen

Received on Thursday, 14 April 2011 17:31:33 UTC