[rdfweb-dev] Re: <foaf:community>?

Bill Kearney wkearney99 at h...
Sat Dec 14 19:41:12 UTC 2002

> I did have a look at something like this:
> http://dublincore.org/documents/rdf-relation-types/

Yes, that's the sort of stuff I was mentioning.

> but it didn't seem to have the finer division that might be
> important. For vaguer concepts (like cliques or social circles) it
> might already be expressed in the knows relationships

A relationship is one thing. What kind of relationship is another.

<ns:group rdf:datatype="http://example.com/types#clique" />
<ns:group rdf:datatype="http://example.com/types#fraternity" />
<ns:group rdf:datatype="http://example.com/types#treehouse" />

Or the WordNet stuff could be used as well. The idea there is that groups are
known. While as the same time different types of groups are known. So one
could say person X belongs to Y number of groups without having to say person X
belongs to Y number of groupA, groupB, groupC, etc.

Avoiding, for now, the ambiguity of what consistutes "belonging" to something.
To follow Dan's thinking, your group states members. Those members would also
have to add a reference stating they belong to your group. Using a generic
group type might probably be a lot easier for them. That way they just express
belonging to the group, without it's type being defined. The group itself,
however, defines it's type. That'd get used to pivot around the different group
types. Grafting a group type into the members assertion seems like it would
really complicate things.

> but I'm more
> interested in something that is halfway between that and a company
> roster (which could be expressed with FOAFCorp?). I can (and partly)
> have set up the discussion board on the site of one of the
> communities I visit to pump out FOAF files for everyone so this could
> be taken as an authoritative linking of that person with that
> community and the link to their FOAF file could be the relation
> identifier above. As emails are authenticated it could also be used
> to vouch for you being who you said you were.

Sure, the group foaf indicates the members. The user foaf indicates their own
groups. The linkage follows around.

> However, it doesn't express other divisions like admin roles like
> administrators, moderators, etc. and such things could have some
> uses. I could set up a page which allowed people to add themselves to
> a Group document as long as you were logged in and I had your email
> address (authenticated) I could match that with the administrators
> email address listed there and if it matched send off an email to
> your address where you could confirm the addition or any subsequent
> changes. I'm sure if I put my mind to it I could come up with other
> examples.

Those mechanisms, while important, are perhaps less important in the foaf sense.
But yes, that flow you describe sounds right.

> Anyway this is one of the reasons I threw this idea into the ring -
> if it can be accomodated within existing markup without causing
> things to strain at the seams then that is good but if not then there
> may be a need for something else and they are my ideas for it. All
> your input is much appreciated :)

Indeed, it's great to see the various perspectives being taken into

One thing that comes to mind here is that RDF can be used to make 'layers' of
statements about stuff. Where simplified XML is often very hierarchy oriented,
RDF doesn't have to be. This is one of those "light bulb going off"-like bits
of enlightenment about RDF.

For issues related to roles you'd be well served indicating such in perhaps
different structures. You might find that cramming all of them into one big-ass
XML document to be a really big challenge. And the consumers of the data might
have to jump through some seriously twisted hoops to untangle the hierarchies.
So think about what's going to be using a given document and make use of
external documents to contain the other stuff.

-Bill Kearney

More information about the foaf-dev mailing list