Re: [docbook] Modeling social media conversations?

[Lech Rzedzicki <lech@kode1100.com>]

On Tue, Jan 24, 2012 at 2:54 PM, Norman Walsh <ndw@nwalsh.com> wrote:
> Hello world, anyone done any work modeling social media conversations?

I'd say it needs to modeled as a simplified form of Semantic Web,
following RESTful approach.

You identify the resources here, which end up having URIs, that is:
posting (tweet, G+ post, FB status update etc)
user (typically I would not repeat all the user info every time if I
have the URI to identify, but that could be my relational d b
thinking)

Then using those URIs you can say additional things about these
resources - i.e. if the post has been retweeted from elsewhere, you'd
probably ref the URI of that post, if you want to mention a person or
an account you ref the URI of that user.

I wouldn't go too far in defining specific actions for a specific
service - some people insist on using instagram or flickr when sharing
photos, even when the actual sharing happens on facebook, is that a
facebook or flickr interaction, does it matter?
Instead I'd focus on modelling the interactions - the fact that the
post is retweeted means it's gaining popularity and could possibly be
hijacked for marketing purposes, for example.
Currently I don't see you gathering bits like how many times has this
been shares or a number of "+1", arguably this is more important than
who as was the case with hundreds retweeting iBook author EULA...

One final bit I'd take into consideration is:
a) the technology that's been used to create those social interactions
b) the way you might want to consume and process what you've just captured.

ad a) Both twitter and facebook have initially built their sites with
relational db's on the backend (Ror / php) so in some ways,
interactions with those sites is still limited somewhat and while
improvements have already been announced, the only verb you can use on
facebook posts is still "like", even if it's a post on genocide. I'm
sure that somewhere behind layers of memcached there's still the posts
table and the users table and mirroring that in XML is trivial.
Ad b) I obviously understand the reasons to model this in XML, but it
is very likely that this sort of data will want to be consumed in JSON
or more generally in key/value pairs, so model it so that the XML can
split and rebuilt from those pairs trivially.

Finally how's that related to docbook? ;)


Lech