Re: [OSCOM] Open source DAM

Elliot McGucken <[email protected]>
Newsgroups gmane.comp.cms.oscom
Message-ID <[email protected]>
Hello All,

I've been following this discussion with interest, and just wanted to add
the scenarios from Authena.org from OSCOM 2003 and 22surf.org.

It seems that within the next few years Open Source CMS has huge
opportunities to empower creators/artists/writers/programmers with new
business models.

http://oscom.org/events/oscom-3/proposals/mcgucken_authena.html
http://authena.org
http://22surf.org

Authena Fundamentals:
1. Creators will be free to designate hosts and marketplaces for their
content. No contracts need be signed with corporate conglomerates to
facilitate basic rights management and global distribution.

2. Creators will be afforded a full spectrum of rights options via the
extensible Creative Commons licenses.

3. Authena client and server modules will remain open and free, in
accordance with the GPL license.

4. RDF/RSS feeds will contain digital rights descriptions within the
framework of the extensible CC License and Dublin Core schemas.

5. Three fundamental types of media formats--thumbnailed, watermarked, and
pristine original--will be described in the RDF/RSS feed, which may employ
an Authena schema in addition to the Dublin Core and CC License schemas.

6. Pristine originals of media may be encrypted or stored within a
password-protected directory, should the creator's chosen license
necessitate this.

7. Web services employed by Authena will be based on simple paradigms,
implying the use of REST, which also offers strong support for the semantic
web.

8. A robust ratings system will be built into Authena clients and servers,
which will allow for the ranking of content as well as the repositories and
marketplaces. These rankings will be made available within the RSS feeds.
Rankings facilitated by trusted sources will be given more credibility, so
as to discourage ballot-stuffing.

9. Security and encryption, when needed by the creator's chosen license,
will be provided by open source technologies including SSL and PGP.

10. Authena will use simple protocols based on open standards.

Authena Scenarios
1. Photography: Jenny wishes to create a portfolio of photographs taken
during her summer trip to Wyoming, and perhaps sell some. With a few
mouseclicks, she launches a photo gallery powered by the Open Source
gallery project at pnavy.com. She uploads her pictures and enters the
rights information, releasing a few pictures under Creative Commons
licenses. A client-side Authena module at pnavy.com watermarks the pictures
and embeds RDF license descriptions in the media using EXIF. The Authena
module also generates an RSS feed containing the rights descriptions and
locations of the images. Jenny then opens accounts at stock photography
shops including westgallery.com and wyominggallery.com, both powered by
Oscommerce with photography and Authena modules (vvgallery.org), and
syndicates her pictures to the stock photography marketplaces. A
server-side Authena module at wyominggallery.com reads the RSS feed
residing on the same server as Jenny's portfolio, and using her Authena
password she entered when registering, wyominggallery.com transfers and
logs rights information, thumbnails, watermarked versions, and the pristine
originals via a REST protocol over https. The originals distributed under
the CC license are kept in a public directory, while the proprietary
originals are encrypted and/or kept within a password-protected directory.
A greeting card company in Ireland browses thumbnailed and watermarked
versions of the pictures at wyominggallery.com, and after using a couple of
Jenny's public domain photographs, they purchase publishing rights to her
proprietary photographs, and download a zipped package of high-resolution
originals off the wyominggallery.com server. Jenny is compensated
accordingly by wyominggallery.com.

CMS Client Hosting Jenny's Pictures: Gallery/Postnuke/Phpnuke with Authena
Modules
CMS Server Selling Jenny's Pictures: Oscommerce with photography and
Authena modules (VVGallery)

2. Music: The Tain Collins Band records their first CD. With a few
mouseclicks at bandnuke.net, they launch a postnuke-powered website devoted
to their CD, making three songs available for download with the CC
licenses. An Authena module generates the RDF/RSS rights description for
the entire album. An Authena spider from freestreaming.com parses the
rights information, and grabs the mp3s released under the CC licenses,
preserving the Attribute license. The Tain Collins Band registers for
accounts at cdworld.com and streamingbands.com to syndicate their CD's
content, providing the sites with their Authena password. Authena modules
at cdworld.com and streamingbands.com look back at the RSS feed at the Tain
Collins website, and the digital content and rights are transferred and
logged via a REST protocol over https. Thumbnails (10 second song clips),
watermarked (songs with irregularities or lower audio quality), and the
pristine originals, stored in the password-protected Authena directory, are
transferred. People can buy physical CD's from cdworld.com (oscommerce
powered), or they can subscribe to access streamed music from
streamingbands.com (netjuke powered). Both cdworld.com and
streamingbands.com compensate The Tain Collins Band in proportion to how
often the music is listened to via streaming media or ordered via physical
copies of the CD.

CMS Client Hosting Tain's Music: Postnuke/PhpNuke with Zina & Authena
modules
CMS Server Selling Tain's Music: Netjuke/Oscommerce with Authena modules

3. Books: Kelly has written a book about windsurfing. With a few
mouseclicks at surf.net she launches a Phpnuke portal devoted to her
passion. She makes the first chapter of her book available for download off
her site, releasing it with a CC license which is manifested in the RSS
feed. She syndicates the entire book to niche CMS marketplaces including
allsports.com and booksondemand.com. The digital files are transferred and
logged via a REST protocol over https. David comes across Kelly's site, and
after reading the first chapter, he wants a hard copy. He follows the link
to booksondemand.com and finding another book on windsurfing, he decides he
wants them both. Booksondemand.com lets David combine the two files into
one book, which he orders and receives at a local Kinkos with a
print-on-demand press.

CMS Client Hosting Kelly's Book: Postnuke/Phpnuke/Xoops with Authena
Modules
CMS Server Selling Kelly's Book: Oscommerce/VVGallery with Authena and
book-publishing modules

4. Film/Educational Repositories: Greg shoots a documentary pertaining to
peoples' favorite great books. He creates a personal CMS portal at
filmgallery.com/greg and uploads mpegs of his work. He releases it all
under the Creative Commons Attribute license. The UCLA film school finds
his technique amazing, and they add his work to their repository. This will
bring some renown to Greg, so he's psyched. And because the Authena modules
are already installed in Greg's Gallery, and the UCLA film school has an
Authena-empowered repository at uclafilm.org, all they have to do is point
it at the RDF/RSS feed at Greg's site. The UCLA Authena server modules read
the CC licenses in the RSS feed on Greg's site, and seeing that they grant
permissions to use the files as long as they cite Greg, the Authena module
ports the film clips into UCLA's repository, preserving the CC licenses.

CMS Client Hosting Greg's Film: Gallery/Posnuke/Phpnuke/Xoops with Authena
CMS Server Hosting UCLA Film Repository: Oscommerce/VVGallery with Authena
or Netjuke with film modules and Authena

5. Corporate Repositories: Apple computer is creating a repository of all
film created under a Creative Commons license. Having installed the Authena
server modules, they employ google, searching for every site containing an
authena.php file, which generates the RSS/RDF feed. They scan the RSS
feeds, checking the Dublin Core "dc:format" tag for avi's and mpeg movie
formats, and the cc:license tag for appropriate rights. Finding Greg's
movies at the UCLA film repository, and ascertaining the CC licenses allow
their use in the given context, the UCLA Authena modules upload the digital
files into their own repositories, maintaining the digital rights
descriptions.

CMS Client Hosting Greg's Film at UCLA: Oscommerce/VVGallery with Authena
CMS Server Hosting Greg's Film at UCLA: Oscommerce/VVGallery with Authena

6. Gaming:
Independent game developers post their mods and original graphics on their
own Postnuke sites at gamernuke.com. Many of them release their early work
under CC licenses, to gain publicity. Opensourcegamer.org continually scans
the RSS Authena feeds at gamernuke.com and several other gaming
communities, downloading all the new mods and graphics released under CC
licenses, so as to become a repository for public domain mods.

CMS Client at gamernuke.com: Postnuke with Authena modules
CMS Server at opensourcegamer.org: Oscommerce with Authena modules

Syndicated Commerce & A Philosophy of Creators' Rights
Unlike physical property, digital media can exist in multiple places at
once. This suggests that the digital marketplaces of the future will have
copies of the pristine originals residing on their servers. A creator may
easily syndicate their film, music, or book to several marketplaces. Thus
the OSCMS model of content and commerce syndication, wherein the creator
uploads their content onto their personal CMS, generates versions including
thumbnailed, watermarked, and pristine originals within a secured Authena
directory, and syndicates it to multiple marketplaces. The creator may
choose multiple niche marketplaces for their content, as well as huge,
general marketplaces, such as an Ebay or Amazon for content, or public
domain repositories. Rather than having their content pass through a
centralized corporate structure, their content is distributed via a network
of markets.

Authena is starting out as "a philosophy of creators' rights" inspired by
the Open Source CMS renaissance. Should working paradigms be adopted, they
may become standards. Many entities are attempting to develop DRM standards
from the top down, whereas standards may have a better chance being built
from the ground up. Thus a good place to begin is with simple
implementations which add useful functionality to Open Source CMS systems.
If enough authors, artists, musicians, photographers, and creators find it
useful, then certain aspects may become standards.

Based on the RDF specification, the Dublin Core, and the Creative Commons
licenses, Authena will strive to afford a full spectrum of rights
definitions. Authena will seek a new paradigm of syndicated commerce and a
new mechanism for distribution, whereby creators host their content on an
Open Source CMS such as Postnuke, and syndicate it to any number of trusted
marketplaces and repositories based on other CMS or Open Source commerce
systems such as Oscommerce.


On Wed, 6 Apr 2005, Robert Koberg wrote:

> [email protected] wrote:
> > On Wed, Apr 06, 2005 at 10:11:38AM -0700, Robert Koberg wrote:
> >
> >>Hi Tony,
> >>
> >>Perhaps all your 'Art Historian in need of structure' needs is subversion:
> >>
> >>http://subversion.tigris.org/
> >>
> >>particularly:
> >>
> >>http://svnbook.red-bean.com/en/1.0/svn-book.html#svn-ap-a-sect-6
> >
> >
> > I don't get it. How would you implement a DAM solution with
> > a version control system? Binary only files in a source code
> > repo? AFAIK subversion uses mod_dav metadata storage (when
> > using the apache server backend -- please correct me if this
> > changed). This is an o.k. solution for use cases where you
> > just need queries of the type: "all metadata related to resource x".
> > How would subversion answer questions like: "list all resources
> > created in France between 1402 and 1437 by flemish painters"?
> > Or: "All resources for which there is more than one scan"?
>
>
> Well, the user seemed somewhat technical and the requirements were not
> great. /Maybe/ that is all he needs. Just a thought after reading the
> requirements...
>
> The properties section of svnbook mainly uses binaries as examples. From:
>
> http://svnbook.red-bean.com/en/1.0/svn-book.html#svn-ch-7-sect-2
>
> "Say you wish to design a website that houses many digital photos, and
> displays them with captions and a datestamp. Now, your set of photos is
> constantly changing, so you'd like to have as much of this site
> automated as possible. These photos can be quite large, so as is common
> with sites of this nature, you want to provide smaller thumbnail images
> to your site visitors. You can do this with traditional files. That is,
> you can have your image123.jpg and an image123-thumbnail.jpg
> side-by-side in a directory. Or if you want to keep the filenames the
> same, you might have your thumbnails in a different directory, like
> thumbnails/image123.jpg. You can also store your captions and datestamps
> in a similar fashion, again separated from the original image file.
> Soon, your tree of files is a mess, and grows in multiples with each new
> photo added to the site.
>
> Now consider the same setup using Subversion's file properties. Imagine
> having a single image file, image123.jpg, and then properties set on
> that file named caption, datestamp, and even thumbnail. Now your working
> copy directory looks much more manageable—in fact, it looks like there
> are nothing but image files in it. But your automation scripts know
> better. They know that they can use svn (or better yet, they can use the
> Subversion language bindings—see the section called “Using Languages
> Other than C and C++”) to dig out the extra information that your site
> needs to display without having to read an index file or play path
> manipulation games."
>
>
> best,
> -Rob
>
>
> >
> > HTH Ralf Mattes
> >
> >
> >>best,
> >>-Rob
> >>
>
> _______________________________________________
> General mailing list
> [email protected]
> http://oscom.org/cgi-bin/mailman/listinfo/general
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.