Here is my FOAF

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.]

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 — 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.