Re: [foaf-dev] FOAF 1.0 Planning Doc

Le 13 juin 2012 =E0 15:44, Dan Brickley a =E9crit :

>>> Current notes are at
>>> https://docs.google.com/document/d/18sktpEWqREts-IjtrWU6eFXiR_VR3GVX9HP=
dlazOC0o/edit
>> =

>> I had no feedback at all about this foaf:Contact idea
>> in a word : a Class that could act as a superclass for any "mean of cont=
act" RDF class, supposing the need I exposed (linking metadata to a phone n=
umber or an email address without using blank nodes) is shared by others.
> =


> It makes perfect sense and has been proposed in various guises over the y=
ears. There is something similar in schema.org/ContactPoint ...

yes, I looked at schema's ContactPoint before, but it represents rather an =
Agent than a pure single "Contact information" thing. =

We have enough classes for Agent (foaf:Agent, foaf:Person, foaf:Organizatio=
n, org:Organization...)

The name "Contact" is too ambiguous.
More explicit description of the concept : Communication Medium, Communicat=
ion Channel
If we look at it from the economic view (your phone number depends also on =
a service provider) view, it could just be named "foaf:Account".

In fact it's described in Semantic desktop ontology [1] as nco:ContactMediu=
m, but with a restricted domain, nco:Role, not easily re-usable as FOAF is.=
..

The goal would be to have a class working for a fax number AND for an onlin=
e account, to be able to add metadata and privacy options along with the nu=
mber or account ID itself (rdf:value is used in vcard just for this goal)

<http://example.org/cid/34> a foaf:ContactMedium, v:Cell ;
	rdf:value <tel:+3361513227>;  # using a tel URI[2]
	rdfs:comment "Do not call after 8PM"@en
	rdfs:comment "Ne pas d=E9ranger apr=E8s 20h"@fr
	dct:modified "2012-05-23"^^xsd:date
	.

<http://www.example.org/pp2> a ppo:PrivacyPreference;
	ppo:appliesToResource <http://example.org/cid/34>;
	.

foaf:OnlineAccount permits this needed class wrapping, it only suffers from=
 a "geeky" bias : why should Online Accounts have classes while phone numbe=
rs are "just" properties ?


> I think for this rev we should focus on convergence with other vocabs, ev=
en if some duplication; which means looking at poco, vcard, hcard etc as we=
ll. I like idea of representing contact points explicitly - once we figure =
out the interplay with OnlineAccount etc.



Yes, nothing prevents us from already using some vcard classes with FOAF pr=
operties :

<http://example.org/#me> foaf:mbox <http://example.org/cid/44> .
<http://example.org/cid/44> a v:Email;
	rdf:value <mailto:[email protected]>;
	.

Vcard "parameters types" approach [3] is to define several types to describ=
e your resource, so regarding Kjetl's "foaf:personal_phone" property, this =
can be done by combining two classes (v:Home and v:Tel in the vcard example=
). =

Supporting this logic, classes such as foaf:Personal or foaf:Private could =
be added to avoid creating countless personal_skypeID, personal_mbox , etc

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


Finally...
This superclass could also be the superclass of foaf:OnlineAccount, like vc=
ard:Tel is the superclass of vcard:Cell.

----------------
Other comments :

+1 on simplifying accountServiceHomepage + accountName =3D accountURL
Furthermore with decentralized/self-hosted microblog services like StatusNe=
t, an accountURL (or just rdf:value ...) would be sufficient.

+1 for updating "member" to "hasMember"


[1] http://www.semanticdesktop.org/ontologies/2007/03/22/nco/#ContactMedium
[2] http://www.ietf.org/rfc/rfc3966.txt
[3] http://www.w3.org/TR/vcard-rdf/#Param

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