I'm not sure why I didn't realize this before, but as soon as you put "license" into the rel attribute it clicked for me.
Okay, then I guess the question is not whether the RDF route shouldn't be promoted, but rather does the rel="[license]" approach allows for enough implied information to be extracted to be implemented in a way that allows for contained information to represent a "tag" that points to the proper RDF information that in turn points to the proper resource. The code to make something like this work and work well is SUPER easy, and off the top of my head I can't think of one reason why rel="cc:by-sa" shouldn't just work and work well by simply keeping a local RDF data store, or pointing to a community based data store to pull out the proper URI information that this particular license then relates to. Whats REALLY nice about this approach is the inherent ability to make a simple change the RDF data and have this propagate across an entire domain/organization appropriately. So if CC updates to a new version of the by-sa license, which obviously can and more than likely will happen at some point in the future given that the current 2.5 license suggests that a 1.x and 2.x family is already represented. Of course there are those who are going to jump in and suggest "Don't use Qnames in content cuz' of reason a, b, c" do which my response would be "already have a fix... I've just never published it." Maybe now would be a good time to publish that fix? :D On 6/6/06, John Panzer <[EMAIL PROTECTED]> wrote:
Hi David -- Not sure whether you're referring to feed licensing in general, or to the problem of feeds with differing licenses and their relationships. Can you clarify? In either case, I think that requiring RDF in order to license a piece of content would inhibit uptake. I think that's why most of the methods described at http://wiki.creativecommons.org/Syndication don't embed RDF directly. Of course they are indirectly referencing RDF in the case of Creative Commons licenses, so people who have RDF processors can certainly apply them constructively. However the license relations are not limited to RDF. In general, on a discussion, design, and implementation level, trying to deal with <link rel="license" href="http://creativecommons.org/licenses/by/2.5/"/> is a lot easier to deal with than <!-- <rdf:RDF xmlns="http://web.resource.org/cc/"; xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#";> <License rdf:about="http://creativecommons.org/licenses/by/2.5/";> <permits rdf:resource="http://web.resource.org/cc/Reproduction"/> <permits rdf:resource="http://web.resource.org/cc/Distribution"/> <requires rdf:resource="http://web.resource.org/cc/Notice"/> <requires rdf:resource="http://web.resource.org/cc/Attribution"/> <permits rdf:resource="http://web.resource.org/cc/DerivativeWorks"/></License></rdf:RDF> --> It's also, of course, much shorter, which becomes important when you consider the use of per-entry licenses in synthetic feeds. The same arguments apply to microformats, I think, which is why rel-license exists... which might be relevant to GlobalClip. John M. David Peterson wrote: > > Hey John, > > This is obviously an important question that also relates to the > GlobalClip/Citation work that I Bruce D'Arcus (Cc'd) and myself are > working on to allow the ability to extract all of the relative > meta-data, including licensing information, as part of a copy/paste > operation [web page > Oo.o, Word, etc...]. > > Thus far I have been using the documentation on Creative Commons > (http://creativecommons.org/technology/metadata/index_html) that > covers this area quite extensively. > > My question: Is there any reason why the RDF method described at the > above link should not be the method promoted as the de facto standard? > > I completely understand your reasoning behind looking to find a > solution to correctly propagate and promote a particular method for > content producers in whom use multiple licenses dependent upon various > factors such as those you've mentioned. While using the rel attribute > seems to be an easy route, I'm not so sure that all of the various > distinctions can be properly handled by a single attribute. With this > in mind, it *seems* that given the existing RDF route promoted by > CreativeCommons covers all of the necessary pieces to allow for such > things, this would by far be the best route to promote to content > producers. > > Thoughts? > > On 6/6/06, John Panzer <[EMAIL PROTECTED]> wrote: > >> >> All, >> >> Some sites offer two versions of feeds; one is a 'headline only' >> version >> and the other a 'full' version. Other than the content, a significant >> distinction in some cases is the license applied to the data in each >> feed. >> (See http://wiki.creativecommons.org/Syndication.) For >> example, the Engadget site offers a headline only feed with (the >> equivalent >> of a) by-sa Creative Commons license, while its full text is by-nc-sa, >> prohibiting copying for commercial use. >> >> Okay, so far so good. But let's say I'm an ad supported aggregator >> (commercial use of content). I cannot therefore display the 'full' >> feed and >> I'll need to truncate or elide the content. However, I could display >> the >> 'excerpt' feed with no problems. It would be nice if I could >> discover the >> related 'headlines' feed (which I can display with full fidelity) if the >> user tries to subscribe to the 'full' feed through my ad supported >> aggregator. However, right now, there's no automatic way to do that. >> >> A [EMAIL PROTECTED] seems appropriate; I'm thinking of doing this: >> >> <link rel="alternate" type="application/atom+xml" title="Headlines >> Only" >> href="..."/> >> >> ...and then relying on software to determine that (1) there's another >> alternative version of the feed that (2) has a different license >> (requires >> fetching the feed of course) and (3) perhaps should be offered as an >> alternative to the user, or used instead of blindly truncating text. >> >> My major question is whether a "headline only" feed is an "alternate" >> representation, or perhaps an "index" to the full feed, or perhaps a new >> relation (or two) is needed. >> >> Thoughts? >> >> -- >> John Panzer >> System Architect >> http://abstractioneer.org >> > >
-- <M:D/> M. David Peterson http://www.xsltblog.com/
