[foaf-dev] Group vs Class

[Richard Cyganiak]

Hi Ian,

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 .
>
> or
>
> :France rdf:type :EuropeanUnionMember

It would also be useful to be able to say:

<#me> rdf:type :EuropeanUnionCitizen .

and

:Galway rdf:type :EuropeanUnionCity .

and

: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  
do it.

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  
a :EuropeanUnionCountry.)

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.

Best,
Richard





>
> 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?
>
> Cheers,
>
> Ian
> _______________________________________________
> foaf-dev mailing list
> foaf-dev at lists.foaf-project.org
> http://lists.foaf-project.org/mailman/listinfo/foaf-dev