Re: [foaf-dev] FOAF 1.0 Planning Doc

Le 13 juin 2012 =E0 22:20, Ed - 0x1b, Inc. a =E9crit :

>> Vcard "parameters types" approach [3] is to define several types to desc=
ribe your resource, so regarding Kjetl's "foaf:personal_phone" property, th=
is can be done by combining two classes (v:Home and v:Tel in the vcard exam=
ple).
>> Supporting this logic, classes such as foaf:Personal or foaf:Private cou=
ld be added to avoid creating countless personal_skypeID, personal_mbox , e=
tc
>> =

>> Regarding all the protocol/brand specific properties ("skypeID", "openID=
", "jabberID"), one should be able to re-use another RDF Class, and just ad=
d it to its "foaf:OnlineAccount" or "foaf:ContactMedium" resource to descri=
be it more precisely.
>> =

> =

> Would this be handled differently if it were a direct claim to an
> encryption based identity (aka WebID)  - I would think the lack of
> inter-mediation (no CA) make "foaf:OnlineAccount" a contradiction?
> ContactMedium doesn't really speak to the making of such an assertion
> in my mind, but would that be the best place to put a WebID RDF
> stanza?

In the WebID world, your WebID =3D=3D your URI, =

you just add in your FOAF file a cert:RSAPublicKey linked by a cert:key fro=
m your foaf:Person URI

So your plain old URI becomes a verifiable, "accountable" URI, so all the t=
hings asserted can be verified using a TLS handshake.

OnlineAccount are most of the time URLs to a public profile page (twitter, =
fb)
So linking to them from your WebID-enabled URI just validate your claim it'=
s your profile.
With WebID becoming mainstream, we can have online services provide linked =
data such as "here's the WebID linked to this public profile", so we can co=
mpare or look for a sameAS statement to verify the 'hasAccount" claim from =
both parts.


--
Dominique Guardiola, QUINODE
=95 http://www.quinode.fr/
=95 Tel : 04.27.86.84.37
=95 Mob : 06.15.13.22.27