[foaf-dev] Group vs Class

Dan Brickley danbri at danbri.org
Fri Jun 11 15:03:01 CEST 2010


+cc: Dave

On Fri, Jun 11, 2010 at 1:39 PM, Ian Davis <me at iandavis.com> wrote:
> Hi all,
>
> I was wondering about the design decision behind foaf:Group and other
> similar constructs in othe vocabularies. I thought I would ask here
> because there's usually a wealth of background thinking that can get
> surfaced via these kinds of questions.
>
> Why do we want to use constructs like foaf:Group + foaf:member rather
> than rdfs:Class and rdf:type? Is there fundamental difference between
> a class of individuals and a group of them or is it stylistic?
>
> For example, we could model the European Union as a foaf:Group or an
> rdfs:Class. We would either say
>
>
> :France foaf:member :EuropeanUnion .
>
> or
>
> :France rdf:type :EuropeanUnionMember
>
> I've read the text around foaf:membershipClass but in one view of the
> world that property could be viewed as a patch needed for not simply
> using rdfs:Class in the first place.
>
> Does anyone have any thoughts on these kinds of design decisions?

This is somewhat on my mind lately, as it happens :)

The original reasoning was that groups are in a lowercase-sense
'reified' to be things-in-the-world so we can attach extra info to
them, such as homepages, icons, founders, etc. So in that context is
more than just the mathematical set of members. However there are many
cases in FOAF where we want to talk about a group and it is much more
like a set, like the set of W3C staff for example. In this situation
the membershipClass construct is somewhat longwinded, and hasn't as
far as I can see got much adoption. So I think we're missing out here
on a lot of the power of OWL and the tooling built around it, and I've
been wondering how to bridge that; perhaps just by saying that it's ok
to treat a foaf:Group as a class.

( BTW I think there's a parallel discussion to have about FRBR in RDF
and documents, but let's resist that for now :)
( the set of things that are swad-europe tshirts designed by liz-turner... )
( see also http://bpa.tumblr.com/post/10814190/faceted-classification-and-frbr )
( http://www.flickr.com/photos/danbri/2891150205/ )

I mentioned this to Dave Reynolds recently, and he mentioned that the
main problem is around identity conditions; in OWL (or DL flavours at
least?) classes are identical by membership.

To be completely honest I've never reconciled that in my head with the
fact of RDF's open world assumptions; it's rare to have a complete
description of a class and its membership in a single RDF graph. Some
pieces of FOAF design attitude only make sense when you're looking at
a sea of source-attributed triples (which we used to call 'factoids').
But applying OWL's logic to the quads level is tough. There's a
half-hearted nod at this problem in
http://xmlns.com/foaf/spec/#term_mbox where we say "This is a 'static
inverse functional property', in that there is (across time and
change) at most one individual that ever has any particular value for
foaf:mbox. " ... ie we acknowledge that FOAF as deployed in RDFWeb is
going to force us to deal with a pile of sometimes contradictory,
sometimes mergeable documents, each making claims that we have to
reconcile.

But back re Group ... let's try to work this through.

Consider two sets; the set of people who have ever worked for XYZOrg.
And the set of people who hold email addresses that are on the XYZ
staff-and-alumni mailing list. We could write OWL descriptions of
these as classes and FOAF groups. At various points in history, the
two lists might 100% overlap, or might nearly overlap (mailing lists
aren't always well managed, after all). We could model this with
groups, with classes, or with classes that are groups. Does anything
break if at some point in time, the 2 groups/classes have identical
membership? I don't know.

Here's what Dave said in an offlist discussions (w/ permission here):

> > And at the back of my
> > mind is a trickier topic: can a Group simply be a class, eg. a
> > subclass of Person? Does OWL2-DL hate that kind of thing?

Dave Reynolds:
> Don't think is a problem for DL specifically but it is a problem from an
> ontology design perspective. The question is around identity criteria.
> In an Ontology (DL or otherwise) the Class is just the set of things in
> it, two classes with the same members are automatically equivalent
> classes. Whereas for foaf:Group you want the identity to be independent
> from the group members (there's much more about this in the OntoClean
> stuff from Chris Welty et all [1]).

Maybe we should go back to the drawing board and write down some
reasons for having descriptions of foaf:Group-s ...

Something like (this is rough) ---

1. to model loose associations of people, where the use of
'Organization' would seem a bit strong/formal.
2. to model as entities some collection of people, often members of an
online forum (eg. LiveJournal and My Opera sites expose FOAF in this
fashion). In this situation, the members are aware of their being in
the group. Identi.ca / statusnet groups also work like this. Sometimes
groups membership is mediated by an admin, sometimes open to all. SIOC
I think goes into more detail on these topics.
3. to model lists of people, where the people on the list have no say
and often no awareness of being on the list. For example, the account
http://twitter.com/foaf has a public 'twitter list' at
http://twitter.com/foaf/foafy which is an unordered collection of
other twitter accounts. Such lists could also be private (eg.
killfiles, or list-of-people-who-sent-me-mail).
4. to enumerate group membership by simply stating factually who is in a group
5. to describe the criteria for counting as a member of a group
6. to provide a 'solution by indirection' to the problem of
specialising foaf:knows; rather than enumerating relationship
types (as XFN does, with xfn:muse, xyz:hates, xyz:bestFriendAtSchool)
we push these down further into the data; I could publish a
description of a group called 'people-who-inspire-me'; someone else
might publish privately a description of 'people whose writing i can't
stand'; or make a public twitter list of 'people who are XML gurus'
7. to allow composition (data merging, set stuff) of multiple group
descriptions; eg. W3C might publish a 'people who edited a W3C spec'
enumerated list; OASIS might do same; Mozilla might publish a source
code committers list; ... and a 3rd party could compose these into a
'Web standards experts' list.
8. to allow the description of expertise, eg. via SKOS; if I've made
an 'xml experts' twitter list, as have several others, how can these
basic lists be augmented with information that (a) makes clear that
the list publisher is asserting its members have expertise in some
topic (b) what that topic is
9. to allow groups and lists to be shared between social sites and
tools; perhaps I'd like to filter my view of something (say an inbox)
by a group such as "people who i am working with plus direct
colleagues"
10. search and query ie. http://www.foaf-project.org/original-intro
("We want a Web search system that's more like a database and less
like a lucky dip").
11. Access control; to have powerfully descriptive, flexible, reusable
chunks of information that can be used to control who sees what or who
can do what in online systems; and allowing the criteria to make use
of any RDF vocab (eg. foo:bloodType) or dataset/asserter (eg. Dan's
flickr group about blah; W3C's editor list).
12. Ok, enough already?


I may have missed some use cases, but I wanted to get some thoughts
down for discussion. These are some of the reasons why I see
improvements to foaf:Group as pretty central to where we go with all
this; and why you're right to draw attention to it's link with RDF's
core technologies for talking about collections of things...

cheers,

Dan


More information about the foaf-dev mailing list