FOAF additions
Alright, I'm putting together updates to the FOAF information for the next version. I can't make any promises as to when it will go in, live, or even be passed onto a developer - this is a very rough draft of changes that I'm working on making.
Let me know if there's anything I missed.
Additions:
2 new vocabularies: bio, and vcard.
Personal Profile Document - This field lets spiders identify who the document is about. It will contain a foaf:maker field, the same as on journals which support external headers (all of the system styles do), a dc:title and description, and administrative information including the generator and a support request location.
foaf:person nodeId. Since we provide information about the maker, this generates a nodeID for them, so that we can uniquely identify them throughout the document.
Location information. Using vCard vocabulary, we will include location information, if the contact information is public and the user has either country, state, or city set. This information will be exactly the same information as on the userinformation page, however, it will not be linked. Keep in mind that these locations will only be as accurate as the information provided to the servers. Many people put this information in incorrectly, such as described at http://lj-dev.livejournal.com/622479.html .
Default userpic will be included as a foaf:logo.
Keywords will also be presented in a bio:keywords field, in a comma seperated list. This makes the entire keyword selection easier. The foaf:interests fields MAY be removed - I haven't discussed this with any developers yet.
Possible additions that I haven't yet coded:
Displaying a foaf:mbox when it's public and users don't have their email address spam-protected. This would display the mbox that the user has listed on their user information page in the foaf file, if the user has indicated that they don't have problems with that.
Adding an option to allow users to turn the foaf file on or off, independantly of the external URL. Basically, this would turn the users FOAF file into something that would only act as a node, with no identifying information other than a link to the user's profile. This would also allow users to maintain a FOAF file at LiveJournal as well as a seeAlso link, so that all information doesn't need to be integrated into one place.
Additions that will not happen:
Adding anything more to foaf:knows fields. Although it would be nice to have more information here, loading all the users for a FOAF file would be difficult and at this point, not possible.
Account type information. Adding this information would be exceeding the designs of FOAF. The file is supposed to a machine readable version of information designed to be passed on to other tools, none of which would understand an "account type", since most foaf files don't come from another "service" but from the user directly. However, this type of addition might fit into an lj: namespace, if we add a foaf:onlineAccount field to the foaf file. I haven't put enough work into the lj namespace to know if it's even workable yet, so we can concentrate on that later.
There is a lot of information this doesn't provide. This is not meant to be a definitive source of information for all bots. It's a way to provide information about a person and their relationships with other people. For this reason, some information will simply not be available through this interface. Work is already underway which will provide other information to spiders and bots. (The Web Services API, http://www.livejournal.com/community/lj_dev/571518.html has more information.) The goal of FOAF is not to supersede this, but instead to provide the information in a manner that is befitting to the tools that can use it.
Let me know if there's anything I missed.
Additions:
2 new vocabularies: bio, and vcard.
Personal Profile Document - This field lets spiders identify who the document is about. It will contain a foaf:maker field, the same as on journals which support external headers (all of the system styles do), a dc:title and description, and administrative information including the generator and a support request location.
foaf:person nodeId. Since we provide information about the maker, this generates a nodeID for them, so that we can uniquely identify them throughout the document.
Location information. Using vCard vocabulary, we will include location information, if the contact information is public and the user has either country, state, or city set. This information will be exactly the same information as on the userinformation page, however, it will not be linked. Keep in mind that these locations will only be as accurate as the information provided to the servers. Many people put this information in incorrectly, such as described at http://lj-dev.livejournal.com/622479.html .
Default userpic will be included as a foaf:logo.
Keywords will also be presented in a bio:keywords field, in a comma seperated list. This makes the entire keyword selection easier. The foaf:interests fields MAY be removed - I haven't discussed this with any developers yet.
Possible additions that I haven't yet coded:
Displaying a foaf:mbox when it's public and users don't have their email address spam-protected. This would display the mbox that the user has listed on their user information page in the foaf file, if the user has indicated that they don't have problems with that.
Adding an option to allow users to turn the foaf file on or off, independantly of the external URL. Basically, this would turn the users FOAF file into something that would only act as a node, with no identifying information other than a link to the user's profile. This would also allow users to maintain a FOAF file at LiveJournal as well as a seeAlso link, so that all information doesn't need to be integrated into one place.
Additions that will not happen:
Adding anything more to foaf:knows fields. Although it would be nice to have more information here, loading all the users for a FOAF file would be difficult and at this point, not possible.
Account type information. Adding this information would be exceeding the designs of FOAF. The file is supposed to a machine readable version of information designed to be passed on to other tools, none of which would understand an "account type", since most foaf files don't come from another "service" but from the user directly. However, this type of addition might fit into an lj: namespace, if we add a foaf:onlineAccount field to the foaf file. I haven't put enough work into the lj namespace to know if it's even workable yet, so we can concentrate on that later.
There is a lot of information this doesn't provide. This is not meant to be a definitive source of information for all bots. It's a way to provide information about a person and their relationships with other people. For this reason, some information will simply not be available through this interface. Work is already underway which will provide other information to spiders and bots. (The Web Services API, http://www.livejournal.com/community/lj_dev/571518.html has more information.) The goal of FOAF is not to supersede this, but instead to provide the information in a manner that is befitting to the tools that can use it.