[foaf-protocols] using windows to mint web id credentials,
kidehen at openlinksw.com
Sun Nov 27 00:29:32 CET 2011
On 11/26/11 5:42 PM, Henry Story wrote:
> On 26 Nov 2011, at 23:18, Kingsley Idehen wrote:
>>> I think the rdfa/microformat debate is not finished either even in
>>> the HTML5 working group.
>> Is this a debate?
>> You just don't want to visit the reality that we should encourage
>> people to use EITHER! Since this is how you bootstrap. I do not have
>> time for another useless 12+ year odyssey. I just don't!
> Before you encourage people to use either, perhaps we could start with
> the one we have implemented.
Sorry, but you are deflecting. And this deflection is detracting from
the big picture at hand.
> Especially when you are speaking to Peter Williams who finally just
> managed to get a WebID we could work with.
Hmmm. You think the WebID is the big deal for Peter? Seriously now?
There is a dimension to this endeavor you refuse to understand. Why that
is I am yet to fathom.
> As you see I am keeping it short. RDFa/Microformats is going to be won
> on the html5 mailing list not here.
I don't give a darn about syntax! I only give a darn about concepts!
> We have started
> by choosing one here.
And their lies your artificial blindness.
> We can add the other later, since you claim they are interoperable.
> But perhaps there are other more
> fun things to do.
These others happen to be whom exactly? Are you interested in millions
of WebIDs or not? Or as you interested in a little clubby research
project under a W3C banner?
Now lets get real.
Given a blogspot.com post (with an html+microdata based structured data
island) with URL based permalink:
1. SPARQL Protocol based Query Results URL (deliberately in SELECT mode
to show effects of query against the Blog Post URL): http://goo.gl/DaKIv .
2. SPARQL Endpoint's HTML based Query Editor URL: http://goo.gl/U5WW9 .
Repeating this exercise using the same blogspot.com hosted blog, but
this time using RDFa for the embedded structured data island:
1. SPARQL Protocol based Query Results URL: http://goo.gl/8Qv2j
2. SPARQL Endpoint's HTML based Query Editor URL: http://goo.gl/Jud6y .
Note re. examples above: you only need the "DEFINE get:soft "replace"
pragam one time since this is how the HTTP GET is performed as per
earlier comments re. SPARQL and FROM.
As you can see, we get the same effect using RDFa or Microdata based
structured data islands within blogspot.com posts.
We don't need to extend a silly syntax war to WebID. Let's keep WebID in
the conceptual realm. It components boil down to:
1. structured data for representing claims that consist of EAV/SPO triples
2. PKI -- which is driven by proof of key ownership
3. specific trust logic -- which is based on "mirror claims" between an
x.509 cert. and an Identity Provider space
4. de-referencable URI used in the SAN of an x.509 cert. that resolves
to an Identity Provider space that hosts the "mirrored claim" or the
critical parts of it e.g., modulus + exponent and/or fingerprint and/or
DER representation of the Certificate
5. relying agents or delegates being able use the URI in SAN as a WebID
watermark by performing a lookup the "mirrored claim" by de-referencing
the URI(s) in SAN.
AWWW allows all of this to happen without RDF or SPARQL specificity.
Same applies to representation of the "mirrored claims" as RDFa,
Microdata, RDF/XML, other EAV/SPO based directed graph based
representations of said claims.
AWWW is about openness. It isn't about myopia. Let's not compromise the
underlying design that makes this all possible.
WebID should be a politics free zone. Introduce politics and it will die
an unnecessary death, by stagnation.
I want WebID adopted at massive scales. I am not interested in a toy
> Social Web Architect
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
-------------- next part --------------
An HTML attachment was scrubbed...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 1625 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.foaf-project.org/pipermail/foaf-protocols/attachments/20111126/d783deb6/attachment-0001.bin
More information about the foaf-protocols