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 >