[rdfweb-dev] FOAF browsing and FOAFster

Dan Brickley danbri at w3.org
Tue Jul 8 13:31:56 UTC 2003


* Jim Ley <jim at jibbering.com> [2003-07-08 12:47-0000]
> "Danny Ayers" <danny666 at virgilio.it>
> > > In the foaf-world, I only "know" people who I've shared a drink
> > > with, online
> > > interaction isn't really enough, that doesn't mean there aren't people
> out
> > > there who I'd do much the same I would for a friend (trust an
> introduction
> > > from, do favours for etc.) but for me, I feel it's important to have
> > > actually met them.
> >
> > Initially I'd have gone along with this, but despite knowing about the
> > project since the early days, I think there is only one other FOAF'er I
> > could include based on this (Chaals - and even then I think I was the only
> > one with a drink ;-).
> 
> That's fine, you can think of knows however you want, I don't think it's
> desirable to constrain it into some tight definition, as I doubt with that
> definition I'd be willing to say I know anyone, or I know everyone.  An open
> definition is the best one, with finer grained detail coming from
> subProperties of knows.
> 
> danbri noted that foaf:knows is currently described as symmetric, I very
> much don't like this since it means I have to make claims about other
> people.

I over-stated the case, as I was considering the +/- of saying formally,
using OWL, that

 ?x foaf:knows ?y
implies
 ?y foaf:knows ?x

If you look at our current definition,
"A person known by this person (indicating some level of reciprocated 
interaction between the parties)" (from http://xmlns.com/foaf/0.1/) there
are several things worth noting. So just a quick brain dump here:

(1)
 foaf:knows relates people to people.
 so
 ?x foaf:knows ?y 
implies 
 ?x rdf:type foaf:Person
 ?y rdf:type foaf:Person

This is expressed in the RDF Schema, the domain and range bits:
[[
     <rdf:Property rdf:about="http://xmlns.com/foaf/0.1/knows" 
	rdfs:label="knows"
	rdfs:comment="A person known by this person (indicating some level of reciprocated interaction between the parties).">
         <rdfs:domain rdf:resource="http://xmlns.com/foaf/0.1/Person"/>
        <rdfs:range rdf:resource="http://xmlns.com/foaf/0.1/Person"/>
        <rdfs:isDefinedBy rdf:resource="http://xmlns.com/foaf/0.1/"/>
      </rdf:Property>
]]

(2) 
we don't currently use OWL to say that it is symetric.
However the definition does appeal to what I called "some level of 
reciprocated interaction". This clause was intended to indicate that, although
loose, foaf:knows is not so loose as to be fairly applicable to cases such 
as ?x "knowing of" ?y, for example one's knowledge of a pop star, or 
of famous figures from the past. 

I explicitly don't tie this to physical interaction, since the world is a 
richer place for the existence of phones, computer networks, and the 
postal service.

(3) 
Most of you won't remember, but the original version of FOAF was rather 
different, in that I tried to enumerate relationships such as:

 * foaf:knows
 * foaf:knowsWell
 * foaf:friend

It was deployment experience with these that led to the current design, where
FOAF -- despite the name -- doesn't have an explicit representation of 
friendship.

I simplified these because it became painfully clear that deploying the 
seemingly more sophisticated relations listed about would cause a lot 
of problems: how can you define 'knowing' vs 'knowing well'? When do you 
consider someone a friend? What if you say they're a friend, but they say 
they only 'knowsWell' you, and other such awkward situations.

So my first realisation was that FOAF could hurt people, and we need to 
proceed with a certain amount of care in these areas. The second was that
in many cases, it is more rewarding to have an RDF markup representation 
not of the fact of a friendship, but of the evidence left in the world 
of that friendship. From that twist comes the emphasis on 'fun' (some
see it as frivolous) stuff like photo metadata and co-depiction, as well 
as on markup for documenting professional collaborations, eg. use of DC to
describe that two people collaborated on a paper.

This fits quite nicely with another aspect of FOAF, the emphasis on 
relationships and data structures that can be represented using well known 
identifiers (URIs).

The FOAF way of saying that Libby and I both work at ILRT (not strictly 
true now as I am just a visiting fellow here, and work at W3C) is to 
say that both she and I have a 'foaf:workplaceHomepage' whose value 
is the URI 'http://www.ilrt.bris.ac.uk/'.

This immediately, if indirectly, puts a lot of flesh on the bones of 
foaf:knows. You can tell from the foaf:knows that we know each other, but that
is (by design) pretty vague. Now instead of providing a hundred different
extensions to foaf:knows, eg. foaf:knows_and_works_with or 
foaf:knows_and_worked_with_once (let's leave temporal logic for a 
separate thread!)... instead of this, we get an RDF representation of 
a different fact, the fact that we share(d) a workplaceHomepage.

So a design question looms: should we define FOAF properties such 
as foaf:colleague which are sub-properties of foaf:knows and whose 
meaning is fixed by reference to the existing FOAF vocab.

We might say, for example:

?x foaf:colleague ?y
is owl:SymettricProperty and is
implied by 
?x foaf:workplaceHomepage ?z
?y foaf:workplaceHomepage ?z
?x owl:differentIndividual ?x

ie. two people are colleagues if the homepage of a place they work 
is the same.

There are other examples like this, eg. family relations, collaborators
(co-authorship etc). We could very easily add a whole load of clutter, but
perhaps it would be useful.

OK end of rambling brain dump.

Basic idea is that foaf:knows and its elaborations are just the tip of the 
iceberg when thinking about the way people relate to one another in 
real life, and that much of the current FOAF design is about providing 
ways of documenting those other things -- shared photos, collaborations,
projects, workplaces, in a way which hopefully counterbalances the 
vague nature of 'knows'.

Gotta run to a meeting hope this makes some sense,

Dan




More information about the foaf-dev mailing list