[foaf-dev] Time to make the foaf classes relate to Dublin Core classes?

[Dan Brickley]

On 23/01/2008, KANZAKI Masahide <mkanzaki at gmail.com> wrote:
> Hi Kjetil,
>
> 2008/1/23, Kjetil Kjernsmo <kjetil at kjernsmo.net>:
> > I think foaf:Group can encompass such ad hoc classes of people, as the
> > spec further says "This concept is intentionally quite broad, covering
> > informal and ad-hoc groups, long-lived communities, organizational
> > groups within a workplace, etc. "
>
> Well, foaf:Group can be an ad-hoc group, but I expect it be a 'real'
> one, while dcterms:AgentClass is for more 'abstract' group (hence
> class of agents) such as 'all female'. I wonder it would be confusing
> to mix up both categories.

You are both right. The DC approach directly says that some group is
simultaneously a "group" of agents, and an RDFS/OWL class. The current
FOAF design doesn't treat them directly as classe. This is to allow
groups to be treated as you say, as "real world" things - social
things with a history and properties. However we do allow abitrary
ad-hoc groups, such as the group of people with a bloodType of A+. The
difference in in FOAF is that we currently have an extra layer of
indirection:
>From http://xmlns.com/foaf/spec/#term_Group
[[
While a foaf:Group has the characteristics of a foaf:Agent, it is also
associated with a number of other foaf:Agents (typically people) who
constitute the foaf:Group. FOAF provides a mechanism, the
foaf:membershipClass property, which relates a foaf:Group to a
sub-class of the class foaf:Agent who are members of the group. This
is a little complicated, but allows us to make group membership rules
explicit.
]]

This, I must say, is an under-used corner of FOAF. It was intended as
a way to allow a group's membership criteria to be defined in terms of
arbitrary properties, in a machine-readable way. But it hasn't been
much explored yet. Recently I've been exploring the idea of using
SPARQL here instead, with a custom SPARQL query associated with the
Group description being used as a way to indicate group-membership.
This is an area where RIF, OWL and SPARQL overlap somewhat. Although
ideally SPARQL isn't the right technology here, I think it has
potential worth exploring. And in fact the queries could be generated
from simple OWL definitions, so it could be made compatible with the
earlier approach (if people care).

Some related notes here: http://danbri.org/words/2008/01/22/260

> > Though, the idea of a
> > reciprocal subclass got me somewhat confused, envisioning a Venn
> > diagram, does that mean that they partly but not entirely overlap?
>
> Reciprocal subclass is exactly same relationship as
> owl:equivalentClass, so it is not desirable in this case. I think they
> might have some overlap, but not subclass (entirely part of) each
> other.

Exactly. a foaf:Group whose members are those people with a
workplaceHomepage of http://example.com/ is not the same thing as the
corresponding RDFS/OWL class. In DC, the Group is just the same thing
as the class (I'd like to see OWL WG comments on that design btw).
FOAF makes the connection between these two explicit with
:membershipClass. Here is how the idea looks in SPARQL instead:

PREFIX : <http://xmlns.com/foaf/0.1/>
PREFIX : <http://www.w3.org/2002/07/owl#>
CONSTRUCT {
  <http://example.com/mygroups.rdf#thegroup> a :Group;  :member ?x .
}
WHERE {
  ?x a :Person; :workplaceHomepage <http://example.com/> .
}

The advantage of having the definition in OWL, would be that we would
be making the semantics more explicit . SPARQL construct queries
aren't really rules, officially. They're more an implementation
technology. But we're implementors ;) .... And one implementation
issue we'd it is that  if we had several of these rules (eg. in some
personal semweb aggregation) their interaction would need to be
handled in application code. An example I have already is that I have
RDF descriptions of the group of agents and their openids who have
commented on my blog, and who have edited the FOAF wiki. I'd perhaps
like to define further groups in terms of those underlying groups.
That should be possible, but if we use SPARQL, it would need care and
hand-coding to figure out how the different queries and datasets
depend on each other.The advantage of having this also in SPARQL is
that you can send the query directly to a database, and perhaps also
that it is directly more intuitive to mainstream Web developers, on
the assumption that they'll be using SPARQL more than OWL. The OWL
version of this would be something like:

   <owl:Class rdf:about="#Class_of_Persons_who_work_for_example_dot_com">
     <rdfs:subClassOf rdf:resource="http://xmlns.com/foaf/0.1/Person"/>
     <rdfs:subClassOf>
       <owl:Restriction>
         <owl:onProperty
rdf:resource="http://xmlns.com/foaf/0.1/workplaceHomepage"/>
         <owl:hasValue rdf:resource="http://example.com//"/>
       </owl:Restriction>
     </rdfs:subClassOf>
   </owl:Class>

In some restricted simple cases it should be possible to generate the
SPARQL from the OWL, although I'm not really sure how far it makes
sense to go here.

My use case is that I want to the ability to define (privately! ie. in
privacy of my own data store) some rules for data filtering. For
example, I might love Flickr, but wish that they had a way to let me
see photos from people I've actually met. Or I might be preparing for
a conference, and want - just this month - to see Flickr or Twitter
data streams from people who are planning to attend that conference.
I'm hardly going to sit down and go thru and reclassify everyone using
Flickr's "friend" UI (although I've heard of people doing similar
things for ACL). Or I might be considering seeking a job at
example.com, and want to see stuff from employees there. In each case,
there are raw data streams from existing social network sites, there
are also profiles (often with FOAF or XFN machine versions) at those
sites, and there are public, explicitly enumerated buddylists too.
However the social dynamics of those publically enumerated lists are
pretty crude and limiting. I think it could be really powerful if we
could exploit the data streams and services of each of these sites,
but do it from a private control panel configured in terms of
arbitrarily defined (and privately configured) group descriptions.

To me, this is where very explicitly named interpersonal properties
such as XFN makes a load more sense. Saying things in the public Web
is always complex and prone to gaming, schoolyard ego dynamics, and
awkwardness. We found this in the first version of FOAF. In FOAF
originally, we allowed people to say "knows", "knowsWell", or
"friend". Even this limited ability created early awkwardness: it was
enough to say, in effect, "I know this person well but they're not a
friend". Which isn't what everyone likes to hear about themselves.
Similarly in XFN, person A might consider B an "acquaintance", while B
might consider A a "friend". Saying these things in a public
(aggregatable, queriable) form is, again, sometimes a bit awkward. And
I had a Plaxo invite yesterday from someone who I consider a friend,
but who flagged me as a business contact. I'll have a word with her
later :) ....  Now ... safe within the privacy of your own database,
you might be a little more explicit in the way you classify your
contacts. So my thinking is that we'll have local aggregations of RDF
from blogs, FOAF, converted XFN, etc. And on top of that, merge in
some private data (eg. people you've met at conferences, addressbooks,
family tree data, private XFN claims), with foaf:Group definitions
applied on top of this aggregation and used to provide custom views
into the offerings of things like Twitter and Flickr, where people are
currently feeling overwhelmed due to the difficulty of providing more
filtered, nuanced views of the activity streams of their 100s of
"friends".

Am I making any sense here?

cheers,

Dan

ps. related work - http://wiki.foaf-project.org/SparqlPress - semweb
addons for Wordpress including an embedded SPARQL system (using
Bengee's ARC).