Here is my FOAF

And mine: http://actsofvolition.com/stev…

Added foaf:based_near (geographic indicator), foaf:made (in this case pointing to my RSS feed), and an RDF desciption of my FOAF. These necessitated references to the Dublin Core, RSS and WGS84 namespaces.

These flesh-out the FOAF (and its possible output) a little, though not as much as knowing more people who use FOAF would.

Also added foaf:myersBriggs, for whatever that’s worth.

There’s an interesting FOAF autocreation tool at Tecknik.net. You point it at your FOAF and OPML files, it autodiscovers FOAF files from OPML <outline> items, then hashes them into your existing FOAF. But this raises a question:

What does “knows” mean in the FOAF context? I don’t “know” the people in my blogroll and it might be rude to imply that I do. This is nascent stuff and I’m just playing around with it, so right now it’s no big deal. Ultimately, though (if I understand where FOAF could lead), some level of discrimination is appropriate. Ain’t it? Before there can be a friend of a friend there has to be a friend.

Still, these emerging standards are great. Beats designing schemas in the dark.

[Peter, you’re serving .rdf and .opml files as MIME-type text/html.]

Yeah, its mildly ironic thats it’s called ‘friend of a friend’ but I removed the foaf:friend property a couple of years ago. The foaf:knows property is supposed to pretty much trauma free, ie. not something it should be easy to cause offence or upset by using (or not using, even). The definition for the looming new FOAF spec is here btw., see http://xmlns.com/foaf/doc/know… — one remaining question being discussed on the FOAF list (rdfweb-dev) currently is whether foaf:knows is symmetric, ie. where X foaf:knows Y implies the reverse… Any thoughts on that?

From the emerging FOAF spec:

Similarly, if there exists a foaf:Document that has two people listed as its foaf:maker(s), then they are probably collaborators of some kind.

Ahh, the Erdos Number again (or Winer number, or whatever).

For my part I agree it’s wise to have forgone more granular “knows” distinctions. As DanBri says, it’s probably for applications to draw and weigh such inferences. It would be a simple matter for a FOAF app to infer that reciprocal foaf:knows mean something that unidirectional ones don’t. Needn’t be any more complicated than that &#8212 though obviously collaboration clues introduce another set of metrics for apps that want to evaluate them.

FOAF documents, then, are largely undirected, and represent the “less.” However because they have a flat though fundamental richness, comparative applications can produce the “more.” Those applications become harder to build (and will suppress the popularity of FOAF) if FOAF attempts to self-direct. Strong inferences are harder to draw if strong implications must first be waded through and dealt with. It’s the difference between “you must deal with me” and “you may deal with me, or not.”

Yet FOAF is a social animal. Uninformed as I am, I agree that FOAF should hold tight to its minimalist classes and properties. When the really good and useful FOAF aggregation apps emerge, they’ll inform necessary changes (if any) to the spec. Toying with it at this point probably lacks real-world cred, is probably bloating and corrupting, and might be faintly masturbatory. If anything, cut properties.

Congratulations on a great idea, DanBri, and on having the wherewithall to hold it close. Also thanks to Peter for getting me and others thinking about RDF again.

The appeal of FOAF and the “knows” verb seems in some ways to be similar to that of RSS, in that it implies a connection to a “trusted source”, in a sense, “knows” might mean “worth knowing” or “less likely to be a source of unwanted content or ads”. Attribute-based profiles like eduPerson would seem to be a nice addition to FOAF, and if my Mozilla spam filter was FOAF-aware it could put mail from FOAF-identified sources at the top of my inbox.

Here’s mine:

http://www.willpate.org/foaf.r…