[foaf-dev] Group vs Class
richard at cyganiak.de
Sun Jun 13 10:08:33 CEST 2010
Here's my take on this. It's not so much about foaf:Group in
particular, but about the question wether groups of things are best
modelled as rdfs:Classes or as non-class resources.
On 11 Jun 2010, at 12:39, Ian Davis wrote:
> For example, we could model the European Union as a foaf:Group or an
> rdfs:Class. We would either say
> :France foaf:member :EuropeanUnion .
> :France rdf:type :EuropeanUnionMember
It would also be useful to be able to say:
<#me> rdf:type :EuropeanUnionCitizen .
:Galway rdf:type :EuropeanUnionCity .
:BP rdf:type :EuropeanUnionCompany .
and so on. The result of using rdf:type and classes here is that I
need several classes to talk about the same European Union. The
modelling does not capture the fact that :EuropeanUnionCountry
and :EuropeanUnionCity are somehow related. If I wanted to capture
this relatedness, then perhaps I'd need to invent an extra property to
More importantly, this class-based modelling of groups does not
actually yield a URI for the thing we talk about -- the European Union
as such. (You made a URI for the set of EU member states, but that's
not the same thing.)
I prefer the other approach: Define a URI for the European Union as
such (or finding a good existing one), and relate different entities
to it via :memberState, :locatedIn, :citizenOf and so on.
(The one advantage of the class-based approach is that we have some
good out-of-the-box vocabulary for talking about classes:
:EuropeanUnionCountry rdfs:subClassOf :EuropeanCountry .
:EuropeanUnionCountry owl:disjointWith :AmericanCountry .
which allows us to use an off-the-shelf reasoner to infer additional
information about France from knowing that France is
Given a modelling that encourages re-use of identifiers and
“linkyness”, and another modelling that enables more off-the-shelf
reasoning, I'll always advocate the first. Because “linkyness” enables
serendipitous discovery and re-use of information. Once you've found
the information you need, there's always a way of “inferring” what you
need from it, no matter if the information is expressed in RDFS or
FOAF or something different.
> 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?
> foaf-dev mailing list
> foaf-dev at lists.foaf-project.org
More information about the foaf-dev