[cc-community] Digg-art

Michał Rączka michaloo at gmail.com
Tue Aug 14 07:13:47 EDT 2007


Hello,

I am a coordinator of polish e-magazine Obiektyw.net focused on
around-CC issues, where are published e.g. translations from
icommons.org. As it is idle at the moment and our host service is not
used in a great part, we want to start a new CC-connected project. I
have already discussed it with Alek Tarkowski and Jon Phillips who
suggested posting here.

Firstly, the idea was to support jamendo.com with mirror and additional
playlist management on our site, but now we think about something more
ambitious. Something which could be called Digg-art: website for art
consumers, not artists; system which would aggregate info about artworks
(music, graphic, text etc.) from sites like flickr, jamendo, deviantart
and so on to provide tools to collect user's favourite works online and
to help exploring others' playlists to promote freed content as a
result.
Whereas our experience with Obiektyw shows that building community
around CC-connected sites is very difficult, we are looking for
acceptance and support from yet existing websites.

Here is translation of our early designdoc:
-quote-
FreeArt Design-doc v2
FreeArt (temp. name) project will provide number of functions to manage
and promote content presented in other, specialised in hosting various
media, systems. We decided to go the whole hog and do something bigger,
but to avoid getting stuck in too ambitious plans I suggest strong
modularity connected with subdomains zoning (user.domain.com,
catalog.domain.com, list.domain.com).
Core would be created by catalog's module, providing adding and
describing given content possibilities to registered users. Cataloging
process would proceed in two ways: if the work is coming from system
like flickr or jamendo, which already have got needed information (tags,
description, license) we can prepare apriopriate plugin to get this
information; but if production hail from other sources (e.g. author's
site) it would have to be verified by a moderator (based on provided
link, which ensure that certain work was published under CC license).
Each production have to be described by minimum 3 tags: type (music,
image, text etc.), kind (music: instrumental, electronic, big band;
image: photo, charcoal, drawing etc.) and other additional (let's say
theme tags: jazz, metal;  landscape, nude, still life etc.), number of
possible tags is limited (because of different language versions). The
module would present collected data with various criterions (on type,
kind or/and theme level: e.g. catalog.domain.com/music/guitar/pop) and
ways of presentation.
Next module, highly connected with others, will be search engine, which
would, basing on users preferences, check description, author info or
added comments, and it can work on already selected catalog (three
criterions as above).
Opinion module will manage rating, commenting and reviewing functions.
Despite of some differences, this three forms are just three following
(more complex) ways of opine about certain production. User can leave
only rate (1-10), rate + comment or rate + review (longer comment).
Playlist module will provide possibility of creating rank lists. While
catalog module will create such lists dynamically (using search keys and
sort preferences), here, criterions and sort method will be static. It
will be sophisticated module (initially it was primary target) with
options which I have already described [in previous materials] (public
and private lists, moderation, waiting lists, possibility of marking
lists, local work's rates etc.)
User managing module will make users able to register and will support
giving them aprioprate privileges to certain parts of the system and
certain elements within.


In conclusion, with adequate work division, it should be quit easy
because within each module there is nothing difficult. I propose
CodeIgniter (http://codeigniter.com/) framework, it's simple (there is
no need to learn new complex architectures) while it makes basic
operations easier, but I am not sure how it cooperate with the
subdomains division (probably using .htaccess...).
There are two things to solve: how to differ langs versions
(lang.module.domain.com/options or module.domain.com/lang/options)?
And last, less important matter is name and domain name (openart,
freeart, diggart, cc-art etc. ...) 
-/quote-

I also think about creating simple API for better cooperation with
source host services on technical level. Jon noticed "that its better to
use pre-existing software where possible".

And it is everything what we have already designed. We are open for any
comments, suggestions or even criticism.

Best regards
Michal Raczka






More information about the cc-community mailing list