Skip to:
Content

BuddyPress.org

Opened 14 years ago

Closed 6 years ago

#2738 closed enhancement (maybelater)

FOAF support / RDFa

Reported by: boonebgorges's profile boonebgorges Owned by: boonebgorges's profile boonebgorges
Milestone: Priority: normal
Severity: normal Version:
Component: REST API Keywords: trac-tidy-2018
Cc:

Description

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.

Change History (9)

#1 @DJPaul
14 years ago

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

#2 @johnjamesjacoby
14 years ago

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

#3 @boonebgorges
13 years ago

  • Owner set to boonebgorges
  • Severity set to normal
  • Status changed from new to assigned

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.

#4 @DJPaul
13 years ago

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

#5 @boonebgorges
13 years ago

  • Milestone changed from 1.6 to Future Release

Not going to happen for this release :(

#6 @DJPaul
8 years ago

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?

#7 @boonebgorges
8 years ago

  • Component changed from Core to REST API
  • Priority changed from major to normal

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

#8 @DJPaul
6 years ago

  • Keywords trac-tidy-2018 added

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/

#9 @DJPaul
6 years ago

  • Milestone Awaiting Contributions deleted
  • Resolution set to maybelater
  • Status changed from assigned to closed
Note: See TracTickets for help on using tickets.