Re: An Introduction: SOCML

Simon,

Excellent feedback. I agree that one-size-fits-all specifications has the
potential to limiting rather than liberating and you make some fair points!

Melvin also made similar comments with respect to avoiding the pitfalls of
getting bogged down in transport security, authentication, etc. and I agree
with both of you completely. I will remove those items from discussion and
instead will focus more on the data standard.

The use of case scenarios you mentioned is something I had not considered
and it makes a lot of sense to me to create a few. Essentially, at the end
of this exercise, all I want is a uniform data interchange format to be
established that will be accepted among the various independent social
networks. To accomplish this I believe that having a set of uniform objects
with agreed upon required fields, while also allowing for additional custom
extensibility, is the best way to go.

Regarding Activity Streams, in an earlier post to the listserv I mentioned
that I believe AS currently seems to lack an emphasis on portability of
user content, and largely seems to be "action related." I'm not completely
married to the idea that we need to recreate the wheel, as
AS largely accomplishes 75% of what most social network services want to
capture; however, I'm not sure how to go about extending this interchange
format and more to the point I'm not entirely sure I agree with their
implementation.

I've updated the SOCML wiki with some new ideas. The concepts are not too
dissimilar from AS -- the one thing that is different is that I make a case
for nested social media objects within other social media objects. (I
couldn't find an example of AS doing this; although, it may be implied
somewhere in the docs).

Here are some direct links:

*Identity Object *- very similar to AS "actor" concept. This tag is
universal to all social media objects and describes the owner.

http://www.w3.org/2005/Incubator/federatedsocialweb/wiki/SOCML:Identity

*Status Update* *Object *- This is a very simplistic object. In the example
you will see how I embedded an additional identity object in the content to
reference another user. I'd imagine the same could be done for events,
pictures, etc.

http://www.w3.org/2005/Incubator/federatedsocialweb/wiki/SOCML:Status

*Service Object* - Ok, so here is where I get a bit into the weeds and try
to create an object that defines service endpoints for how the different
networks can communicate with each other. Of course, this might be one of
the pitfalls you are cautioning against but I think it's important for
social network services to know how to communicate with each other.

http://www.w3.org/2005/Incubator/federatedsocialweb/wiki/SOCML:Service

Finally, the updated SOCML object tree can be found here:

http://www.w3.org/2005/Incubator/federatedsocialweb/wiki/SOCML_Technical

I will work on some use case scenarios to help further articulate the idea.
I do want to emphasize that I do not want this project to be entirely
driven by my own vision and would like for as many people as possible to
have a hand in creating this. Ultimately, a data standard is no good if
nobody uses it. Perhaps, I can help write a mod for buddycloud that
implements the final standard? :)

Anyway, I look forward to your feedback!

Chris



On Wed, Feb 13, 2013 at 4:49 AM, Simon Tennant <simon@buddycloud.com> wrote:

> 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
>