FOAF support / RDFa

[boonebgorges]

Support Friend of a Friend to make BuddyPress compliant with linked data standards. Good web citizenship :)

This could be done with a plugin. DJPaul worked up a proof of concept in the 1.1.x days: ​http://svn.dangerous-minds.com/djpaul/out-of-the-box/ To my mind, though, there are some limitations to that approach: 1) having it as a plugin means that the majority of installations won't use it, which limits the utility of having FOAF support in the first place; 2) Paul's solution makes the information available via a distinct URL. In my view, this produces a bit of undesirable overhead: anyone who wants to use the data has to know the slug that the site admin has chosen, adding an extra step to the process of crawling for data on the site.

My proposal is that we implement FOAF via RDFa, embedded directly in templates. Drupal is taking that very route in the Drupal 7 core. See this thread ​http://groups.drupal.org/node/16597 for the initial roadmap. The rough roadmap in that thread is similar to the way it would/could work in BuddyPress. We'd need to make sure that there was a programmatic way to add attributes dynamically to the important elements in the DOM, for instance something like

<ul id="members-list" class="item-list">
	<?php while ( bp_members() ) : bp_the_member(); ?>

		<li <?php bp_the_member_list_item_attribute() ?>>

where bp_the_member_list_item_attribute() is a template tag that echos something like property="foaf:Person", but is filterable by plugins.

We'd also need a way for admins to specify (optionally) which profile fields correspond to which FOAF attribute. I think that means collecting what we assume are the most commonly used vocabulary items from the spec ​http://xmlns.com/foaf/spec/, then offering them to the admin at the time of profile field creation/editing.

I can whip up a prototype, but it'd be nice to get some feedback in the meantime.

[DJPaul]

Good topic. At the last dev chat, which I know you missed most of, I specifically mentioned we'd need a way to assign a "meta type" to each xprofile field option -- see onwards from around ​https://irclogs.wordpress.org/chanlog.php?channel=buddypress-dev&day=2010-11-10#m103111

[johnjamesjacoby]

All for it. Seems like a perfect use case for profile meta.

[boonebgorges]

As per dev chat, I'm accepting responsibility for this bad boy. For the moment, I plan to focus on an implementation of FOAF that does not reside directly in the templates, so that we can minimize template modifications. This also means that I'll be able to build it as a plugin first. So the first rev will give us a chance to practice with ontology, and mapping ontology onto profile fields; once we feel comfortable with that (post-1.6 to be sure) we can consider how an inline RDFa implementation might look.

[DJPaul]

Per the description, I've dabbled in this before - I'm happy to help if you need a 2nd opinion on anything :)

[boonebgorges]

Not going to happen for this release :(

[DJPaul]

Hello, old ticket. I'm pretty surprised my SVN linked in the original description is still online.

In the years since, FOAF and SIOC and other related ontologies have come and gone in terms of maintenance and popularity. FOAF itself never really took off in a really large way, though it still appears to be around, and it's a technology we could choose to use.

However, I think RDFa isn't the way to go any more. I think we can close this in favour of using JSON-LD (which includes Schema.org) in our upcoming REST API to expose this data. @boonebgorges, thoughts?

[boonebgorges]

Thanks for the necropost, @DJPaul ;)

I agree that RDFa is probably not the way to go in 2016. I don't know much about JSON-LD but it does seem to be a promising way of approaching the problem in a standard way across components.

I think it's worth keeping the ticket open for consideration of FOAF. cc @bronsonquick

[DJPaul]

We're closing this ticket because it has not received any contribution or comments for at least two years. We have decided that it is better to close tickets that are good ideas, which have not gotten (or are unlikely to get) contributions, rather than keep things open indefinitely. This will help us share a more realistic roadmap for BuddyPress with you.

Everyone very much appreciates the time and effort that you spent sharing your idea with us. On behalf of the entire BuddyPress team, thank you.

If you feel strongly that this enhancement should still be added to BuddyPress, and you are able to contribute effort towards it, we encourage you to re-open the ticket, or start a discussion about it in our Slack channel. Please consider that time has proven that good ideas without contributions do not get built.

For more information, see ​https://bpdevel.wordpress.com/2018/01/21/our-awaiting-contributions-milestone-contains/
or find us on Slack, in the #buddypress channel: ​https://make.wordpress.org/chat/