R: An Introduction: SOCML

Within OMA SNEW (Social Network Web) Enabler specification we defined a format for representing & migrating all personal social network data (activities, contacts, media) from one SN to another.
It relies on ActivityStreams, portable contacts and xrd descriptors wrapped in a zip format.

You can check the latest (draft) version of the spec here:
http://member.openmobilealliance.org/ftp/Public_documents/CD/Permanent_documents/OMA-ER-SNeW-V1_0-20121217-D.zip


walter

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's everything-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<mailto: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<http://buddycloud.com> | +49 17 8545 0880<tel:%2B49%2017%208545%200880> | office hours: goo.gl/tQgxP<http://goo.gl/tQgxP>
Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.

[cid:00000000000000000000000000000003@TI.Disclaimer]Rispetta l'ambiente. Non stampare questa mail se non è necessario.