GSoC12: C3 Commons - Social Object Module (aka Publications)

29 views
Skip to first unread message

Shelly Grist

unread,
Apr 4, 2012, 5:42:12 PM4/4/12
to silverst...@googlegroups.com
Based on the conversation I had with xeraa (related link), Here's a revamp of my project proposal.

GSoC12: C3 Commons - Social Object Module (aka Publications)

Websites which offer some form of social sharing are becoming more and more popular.  These social sites allow members to share various objects of interest from photos (Picasa Web Albums, Panoramio, Flikr), videos (YouTube), movie reviews (Rotten Tomatoes), book/product reviews (Amazon), blogs/journals (WordPress, LiveJournal) and finally to the minutiae of their everyday lives (Facebook).

Social sharing sites also share some common features. A social object is shared with the community to which members can attach metadata: tags, reviews, rankings, etc.  This type of socially shared metadata enables sites to “add value” by providing features such as recommendation systems (Amazon), object rankings (Rotten Tomatoes), number of views (YouTube), find related objects by tag or member (Picasa Web Albums).   This “added value” makes the sharing experience richer and helps to connect members no matter where they are geographically.

Goals:

  • Build an extendable and reusable social object module.
  • Social object will be an extendable DataObject (based on DataObejct as Pages?).
  • Module will allow members to attach various metadata DataObjects:  tags (use existing tags module?), rankings, reviews.
  • New DataObject code will be developed for rankings and reviews.
  • A recommendation system to find similar social objects will be developed based on object metadata (tags, reviews).
  • A recommendation system to find members with similar interests will be developed based on the metadata provided by the member.
  • Working example provided along with instructions on how to extend the module.


xeraa

unread,
Apr 4, 2012, 7:55:21 PM4/4/12
to silverst...@googlegroups.com
Hi Shelly,

Good to hear from you again!

If I understand you correctly, you want to provide a (generic) wrapper for different content elements and link external metadata to that (from a list of predefined providers)?
Could you provide an example with Amazon or Rotten Tomatoes, because I don't fully get how / why you want to add social features.

For example you add a movie poster from Picasa and link Rotten Tomatoes' and Amazon's ratings to it - right? Now you want to show movies (or posters?) with a similar rating? IMHO that won't lead to spectacular results, so I assume my example is bad. Could you provide a better one?

Have you already found OEmbed for embedding external content (see https://groups.google.com/forum/?fromgroups#!topic/silverstripe-dev/odWE5CH9Ms4)? I assume you'd use that to import external content and provide the social features based on it?

Cheers,
Philipp

Shelly Grist

unread,
Apr 4, 2012, 10:38:22 PM4/4/12
to silverst...@googlegroups.com
Hi Philipp

I'm not planning on linking to other social sharing sites or their content.  I want to build a Social Object module that would allow SilverStripe sites to implement social sharing similar to what is available on Rotten Tomatoes or Amazon etc. 

For example, say a SilverStripe developer is building a site for Australian motorcycle enthusiasts who want to share their photos of their trips along with their opinions of the best trip routes or the best cafes to stop at.  Maybe these members come from all over Australia so they might want to connect with a member from another state with similar interests if they're planning a big trip. 

A Social Object module will provide a basic building block which the developer can enhance for his specific implementation.  It will already have a basic social object class (linked to the member who added it), with the setup to link metadata to it: tags, reviews/ratings, etc. The metadata must also be linked to the member who added it.  The module will include various algorithms to compute similarity coefficients which is the foundation for providing a recommendation system or any more advanced social network analysis.  The Social Object module will allow the developer to make the connections between similar objects, between objects and members and between similar members.  These similarity connections enable the value adding features like finding similar objects or members with similar interests.

Hope this makes more sense now....

Thanks,
Shelly

xeraa

unread,
Apr 5, 2012, 4:57:24 PM4/5/12
to silverst...@googlegroups.com
Hi Shelly,
 
I'm not planning on linking to other social sharing sites or their content.  I want to build a Social Object module that would allow SilverStripe sites to implement social sharing similar to what is available on Rotten Tomatoes or Amazon etc. 

Ah ok - you want to build a recommender system within the website itself.
Have you thought about using a decorator (http://doc.silverstripe.org/sapphire/en/reference/dataobjectdecorator) instead of extending a data object? Depending on how much variation you have in your content DOs, this might be helpful to add the same functionality multiple times rather than having to add one or more layers of abstraction.
 
For example, say a SilverStripe developer is building a site for Australian motorcycle enthusiasts who want to share their photos of their trips along with their opinions of the best trip routes or the best cafes to stop at.  Maybe these members come from all over Australia so they might want to connect with a member from another state with similar interests if they're planning a big trip. 

A Social Object module will provide a basic building block which the developer can enhance for his specific implementation.  It will already have a basic social object class (linked to the member who added it), with the setup to link metadata to it: tags, reviews/ratings, etc. The metadata must also be linked to the member who added it.  The module will include various algorithms to compute similarity coefficients which is the foundation for providing a recommendation system or any more advanced social network analysis.  The Social Object module will allow the developer to make the connections between similar objects, between objects and members and between similar members.  These similarity connections enable the value adding features like finding similar objects or members with similar interests.

IMHO it would be important to further specify the kind of metadata as this will have a big impact on both scope and recommender.
For example, I'd also include geo locations(you can probably fetch that from a user's IP, some images contain that information,...).

Cheers,
Philipp

Shelly Grist

unread,
Apr 5, 2012, 9:31:34 PM4/5/12
to silverst...@googlegroups.com
Hi Philipp


Have you thought about using a decorator (http://doc.silverstripe.org/sapphire/en/reference/dataobjectdecorator) instead of extending a data object?

Thanks for the suggestion regarding using a decorator for the DataObject.  I have actually used a decorator for my MemberRole class.  I extended it to accommodate extra fields, and has_ relationships, etc.  But for my Article (my Publications)  and LibraryItem ,etc classes I just extended the DataObject class.  I based my MemberRole class on Aram's SSbits tutorial 'Registering Users and allowing them to edit their details' but I didn't really understand all of the underlying code behind it.

I think that is part of the main problem I've had using SilverStripe - I've found various tutorials which help me but I don't always get all of the underlying architecture choices.


IMHO it would be important to further specify the kind of metadata as this will have a big impact on both scope and recommender.

Specifying the initial metadata is key.  But there are almost endless choices - most dependent on specific implementation needs.  I'm wondering how complex I make the initial module.  Would it be better to provide for the most popular metadata choices, to be determined, in a basic module that can then be extended/adapted by the user using decorators?  Can you use a decorator on a decorator?  For example, if the SocialMember and SocialObject extend DataObjectDecorator with basic data and methods will a user be able to easily extend them? 

Also some of the metadata will also be DOs - tags, reviews, etc which will need to have a many_many relationship to both the SocialMember and the SocialObject.  I'm not sure if each of these will need to be there own separate module?  I'm using the tagfield module now.  Is it being updated for SS3, do you know? 

I also noticed that the tagfield module says to create a tag DO that extends the DataObject rather than using a decorator.  Is there a tutorial or something somewhere that I can read that can explain when its best to extend a class and when its best to use a decorator?

Thanks, Shelly

xeraa

unread,
Apr 5, 2012, 9:56:25 PM4/5/12
to silverst...@googlegroups.com
Hi Shelly,
 
Have you thought about using a decorator (http://doc.silverstripe.org/sapphire/en/reference/dataobjectdecorator) instead of extending a data object?

Thanks for the suggestion regarding using a decorator for the DataObject.  I have actually used a decorator for my MemberRole class.  I extended it to accommodate extra fields, and has_ relationships, etc.  But for my Article (my Publications)  and LibraryItem ,etc classes I just extended the DataObject class.  I based my MemberRole class on Aram's SSbits tutorial 'Registering Users and allowing them to edit their details' but I didn't really understand all of the underlying code behind it.

Basically a decorator (I think Rails calls it a Mixin) hooks into another class rather than extend it. This is especially useful if you can't really replace an existing one - for example Member as the CMS uses it in /admin/security. So you want to inject your own attributes into it, which a decorator does for you.
So if you also want to rate users, providing a (probably abstract?) DataObject won't work too well for you. But I don't know enough about your exact scope to give you a finale opinion.

I think that is part of the main problem I've had using SilverStripe - I've found various tutorials which help me but I don't always get all of the underlying architecture choices.

IMHO it would be important to further specify the kind of metadata as this will have a big impact on both scope and recommender.

Specifying the initial metadata is key.  But there are almost endless choices - most dependent on specific implementation needs.  I'm wondering how complex I make the initial module.  Would it be better to provide for the most popular metadata choices, to be determined, in a basic module that can then be extended/adapted by the user using decorators?  Can you use a decorator on a decorator?  For example, if the SocialMember and SocialObject extend DataObjectDecorator with basic data and methods will a user be able to easily extend them? 

I must admit I've never tried to extend a decorator two or more times, but this should IMHO be possible.
However don't make it too complex. Additionally adding layer upon layer sounds nice in theory, but it gets harder to handle and slower with each layer (OOPs spaghetti code is lasagne code - layer upon layer ;-) ).
I'd settle for a set of sensible parameters (probably tags, ratings, locations) and keep that extensible. You don't need to cover everything.

Also some of the metadata will also be DOs - tags, reviews, etc which will need to have a many_many relationship to both the SocialMember and the SocialObject.  I'm not sure if each of these will need to be there own separate module?  I'm using the tagfield module now.  Is it being updated for SS3, do you know? 

I think Ingo has written the module and is maintaining it - I've never really used it and can't say too much about it.
 
I also noticed that the tagfield module says to create a tag DO that extends the DataObject rather than using a decorator.  Is there a tutorial or something somewhere that I can read that can explain when its best to extend a class and when its best to use a decorator?

Tried to explain above - maybe Ingo can add some feedback on the specifics of the tagfield module.

Cheers,
Philipp 
Reply all
Reply to author
Forward
0 new messages