Thoughts? Seems like it'd be pretty trivial to implement?
Open Source Advocate-at-Large
This email is: [ ] bloggable [X] ask first [ ] private
When there are multiple 'authors' for the tags, this needs to be made
more explicit when reporting them back onscreen.
Chris Messina wrote:
> Here's a quick plugin request idea (inspired by Tantek):
> Thoughts? Seems like it'd be pretty trivial to implement?
PhD Student, Information Science, UNC-CH
Yep, would be cool, definitely. I've lost track of relationship
between categories and tags in the Wordpress world. Does wordpress
have an innate notion of tag, as well as category? Or they're
essentially same thing?
My thinking is to perhaps use bengee's new RDF store to harvest the
categories that my friends are using, so they can be re-used rather
than reinvented. I'm not sure if Morten's SKOS output plugin still
works, but we're going to have a chat about this in IRC soon, so will
report back here...
The permissions/whitelisting for this can already be handled by my
diso-profile plugin, although I am looking to improve that part of the
- Stephen Paul Weber, Amateur Writer
As for the difference between taxonomy tags and categories in
WordPress, the simple way to think about their differentiation is that
you use free tags on the fly, whereas categories are more like sets or
more-permanent collections. While I can see how programmatically they
should probably be the same thing (like Drupal), I do believe that
both systems derive from the same taxonomy infrastructure:
As well, I believe the WordPress API differentiates between tags and
categories, so it's something to keep in mind.
Anyway, back to permissions. How can we best structure/document our
approach to permissions? I feel like Drupal has one of the more
flexible (but hard to use systems) so perhaps we can learn from their
architecture while also inheriting some of the decent UI from
We just need 'nice names' like the XFN creator has and then put them
in some kind of checkbox-based UI or similar...
That's how I've been thinking anyway :)
I think we should consider professional connections too, but starting
with friends, family and "web buddies" or contacts would be smart.
Just to mark my concern about XFN clear, mixing XFN semantics with
access functionality is dangerous; for example, when I was at Flock, I
had to set a number of coworkers as "family members" within Flickr to
be able to prevent the world from seeing early screenshots... this was
somewhat odious to me since they were clearly not family members but I
had not other way of marking those images as being available to only a
subset of of my contact list...
I wonder if we should consider the ability to create groups/tagged
groups of people like Facebook sets as a more flexible way of managing
permissions? or does that quickly overcomplicate things?
Dealing with permissions also means dealing with the ways we can store
information about people. Right now, we have two models: Wordpress
users, and (in a roundabout way) the blogroll. I have the skeleton of
a third - a DiSo-specific contacts table. A DiSo contact could be
linked to a Wordpress user via the userid, and we could probably join
on the blogroll in the same way, but that gets hairy. I'm
sleep-deprived right now, or I'd launch into a discussion of the
semantics behind these various models, but clearly we need something.
We like the XFN data that the blogroll has, we like the way the actual
users can have roles, permissions, and login via openid, and we have
some custom needs (oh yes, we have xmpp contacts too) that in this
case include tags or groups for group-based permissions.
A tangled web we weave, no?
I believe that the taxonomy model in Wordpress can be applied to
anything - the blogroll categories are a taxonomy, so we could reuse
those, or create our own, but I think that applying a taxonomy
(whether groups or tags or both) to whatever object we decide to use
is within the realm of possibility. Update: check out
wp-includes/taxonomy.php for a decent api, which could definitely be
used by a plugin to tag/group/categorize whatever we want. Update #2:
check out http://codex.wordpress.org/Version_2.3:new_taxonomy
The biggest reason to me to use in place code and data structure is
that users / plugin devs are familiar with the UI / data model
already. It also reduces our overhead.
+1 on using the new tax features to extend XFN, -1 on using it on a
brand new data model
I agree with Stephen's idea to move a lot of our data into userMeta
(which is what Matt Mullenweg recommended). I won't make the final say
on this point, but I think this approach makes sense and is "doing the
appropriate WordPress thing".
Stephen, do you have a clear privacy model in your head that you could
share? Or do we need to do some research and brainstorming? And, what
can we learn from Drupal, if anything?
I'm still skeptical about using XFN for permissions, just because
people might call someone a friend but might not want to share
everything with that "friend" that they share with all their other
"friends". Perhaps we can have macro levels and then allow for
individual person overrides?
Maybe Will Norris can give us some insight here?
That said, +1 to ALSO allowing arbitrary groups like 'close friends'
to share things with a smaller subset.
Not quite sure what you mean by privacy model. In code this is what I envision:
Wordpress, PHP, God
<?php if( is_('friend') ) : ?>
, My puppy!
<?php endif; ?>
<?php if( is_('contact') ) : ?>
, RSS, Social Media
<?php endif; ?>
<?php if( is_(array('kin', 'Close Friend')) ) : ?>
, My extra secret interest
<?php endif; ?>
Wordpress has a UI for this on links.
> The question here is of course what is discussed on a protocol level and
> what on a implementation level?
I'm a fan of the implement first, discuss, reimplement technique --
mostly because I speak better about code samples and demos than
abstract protocol concepts.
That said, we might want to think about how the categories that are
not XFN are presented so that they can 'come with' to other services
as XFN so easily does?
> I guess DiSo is more about Wordpress
> specific implemenation details.
For now. If someone write code for another system we won't be offended ;)
> Nevertheless it might be great to make it
> also interoperable with other system (like I would be very interested in
> putting a social networking layer into Plone) and thus it might be good to
> define what the protocol should look like.
That's the eventual goal.
Even if it's as simple as giving a blanket statement that 'tags provided
by author and trusted friends'.
The authorship of the tags themselves should be preserved and presented.
Flickr munges/compresses this information at the moment and I'd argue
it's a loss of data.
Of course, this should be balanced by the fact that you'd be
announcing/leaking who your trusted friend-editors are with this
approach as well.
- self-defined groups of people
- group management at the 'person' view
- group management at the 'group' view
These are just containers of contacts/people. When we 'do' an action
based on these groups, it's just taking an action on a dereferenced list
of people - so it doesn't really matter what the groups are
called/named. The group names only have to matter to the user who's
And of course, the group-person relationship is many-to-many.