Re: An Introduction: SOCML

Of course it would be great to be able to port data between different
social networks: closed or open.

The danger with any one-size-fits-all specifications is that they don't.
The devil in any interchange format will lurk in the application details.
Imagine trying to make Facebook Topic+comment model work in
Twitter'severything-is-a-post model: there's no direct fit and dealing
with ever
single edge case might work between two networks, but add a third with a
different application logic and you are back at square one. They are simply
different posting systems.

Also, the risk when trying to mash together different systems with
different application logic: you could end up with a lowest common
denominator defining your application. Of course something like XML gives
one some breathing room.

Perhaps best if you write up a wiki page listing the problem with real
examples so that it's more tangible. I'm wary of specs without real world
use cases to evaluate them against. This seems like an exercise in a spec
finding a problem. A solid set of problem cases would help allay this fear.

Some other thoughts:
- I think you could solve much of this using Activity Streams Atom 1.0
spec. If it's not, it's probably worth iterating the AS spec.
- For your spec to be a success you really don't want to get bogged down in
transport security, authentication and authorisation - these have little to
do with interchange.

IMHO, the real way to solve this is different soc-nets having well
documented APIs with which users can pull *ALL* data out. Even better when
they speak a well adopted protocol. For example, at buddycloud, we
acknowledge that we don't know who users will want to repurpose their
information, but it's there and accessible in a programmatic way  (https
://api.buddycloud.org/simon@buddycloud.org/content/posts).

S.

On 13 February 2013 08:27, Julian Steinwachs <julian.steinwachs
@googlemail.com> wrote:

>
>
>    1. How can we standardized social media objects such as messages,
>    status updates, pictures, etc. while maintaining the ability to add
>    additional extensibility to these objects?
>
>
> I like what the tent guys are doing there: the object type is given as an
> url with a human readable (soon also machine readable) description of this
> type. This url also always contains a version number of this post type, so
> its extensible. And anyone can come up with new types. They say these types
> should be used like file-extensions. I think thats a concept worth copying.
>
> I also would find it good if these descriptions would also contain
> information what one can do with that object and how. So for a photo for
> example that it can be rated by distributing an object that looks like X.
> Or a status message is reposted with an object that looks like Y. That
> would also solve a problem I see with activitystreams. That you can
> potentially like a comment to a comment to a rating of a photo and so on.
> This is just unneeded complexity.
>



-- 
Simon Tennant | buddycloud.com | +49 17 8545 0880 | office hours: goo.gl/
tQgxP