[whatwg] [Fwd: Re: Helping people seaching for content filtered by license]

Nils Dagsson Moskopp nils-dagsson-moskopp at dieweltistgarnichtso.net
Thu May 14 15:31:50 PDT 2009


sorry, forgot to cc the list

-------- Weitergeleitete Nachricht --------
> Von: Nils Dagsson Moskopp
> <nils-dagsson-moskopp at dieweltistgarnichtso.net>
> An: Ian Hickson <ian at hixie.ch>
> Betreff: Re: [whatwg] Helping people seaching for content filtered by
> license
> Datum: Mon, 11 May 2009 10:04:41 +0200
> 
> Am Freitag, den 08.05.2009, 19:57 +0000 schrieb Ian Hickson:
> >      * Tara runs a video sharing web site for people who want licensing
> >        information to be included with their videos. When Paul wants to blog
> >        about a video, he can paste a fragment of HTML provided by Tara
> >        directly into his blog. The video is then available inline in his
> >        blog, along with any licensing information about the video.
> > 
> > (Really? A video sharing site dedicated to people who want licensing 
> > information to be included with their videos? That's a pretty specific 
> > audience, wow.)
> > 
> > This can be done with HTML5 today. For example, here is the markup you 
> > could include to allow someone to embed a video on their site while 
> > including the copyright or license information:
> > 
> >    <figure>
> >     <video src="http://example.com/videodata/sJf-ulirNRk" controls>
> >      <a href="http://video.example.com/watch?v=sJf-ulirNRk">Watch</a>
> >     </video>
> >     <legend>
> >      Pillar post surgery, starting to heal.
> >      <small>© copyright 2008 Pillar. All Rights Reserved.</small>
> >     </legend>
> >    </figure>
> 
> Seriously, I don't get it. Is there really so much entrenched (widely
> deployed, a mess, IE-style) software out there relying on @rel=license
> meaning "license of a single main content blob" that an unambigous
> (read: machine-readable) writeup of part licenses is impossible ? How
> about a possible future keyword, say @rel=content-license ?
> 
> > The example above shows this for a movie, but it works as well for a 
> > photo:
> > 
> >    <figure>
> >      <img src="http://nearimpossible.com/DSCF0070-1-tm.jpg" alt="">
> >      <legend>
> >       Picture by Bob.
> >       <small><a href="http://creativecommons.org/licenses/by-nc-sa/2.5/legalcode">Creative 
> >       Commons Attribution-Noncommercial-Share Alike 2.5 Generic License</a></small>
> >      </legend>
> >    </figure>
> 
> Can I infer from this that an <a> in a <small> inside a <legend> is some
> kind of microformat for licensing information ? Crude, if you really
> mean it this way, but probably workable. Maybe this needs to be
> explicitely spelled out in the spec ?
> 
> > Admittedly, if this scenario is taken in the context of the first 
> > scenario, meaning that Bob wants this image to be discoverable through 
> > search, but doesn't want to include it on a page of its own, then extra 
> > syntax to mark this particular image up would be useful.
> > 
> > However, in my research I found very few such cases. In every case where I 
> > found multiple media items on a single page with no dedicated page, either 
> > every item was licensed identically and was the main content of the page, 
> > or each item had its own separate page, or the items were licensed under 
> > the same license as the page. In all three of these cases, rel=license 
> > already solves the problem today.
> 
> Relying on linked pages just to get licensing information would be,
> well, massive overhead. Still, you are right - most blogs using many
> pictures have dedicated pages.
> 
> > This discourages people from using 
> > multiple licenses, of course, but that's actually a good thing, as it 
> > discourages license proliferation.
> 
> Actually, it discourages working along with perfectly good existing
> licenses as well. Like having CC-BY content on a CC-BY-SA site.
> 
> >      * Fred's browser can tell him what license a particular video on a site
> >        he is reading has been released under, and advise him on what the
> >        associated permissions and restrictions are (can he redistribute this
> >        work for commercial purposes, can he distribute a modified version of
> >        this work, how should he assign credit to the original author, what
> >        jurisdiction the license assumes, whether the license allows the work
> >        to be embedded into a work that uses content under various other
> >        licenses, etc).
> > 
> > Advising a user on the legal implications of a license is something that 
> > needs trained professionals, but given a particular license, advice could 
> > be provided in canned form. So it seems like this is already possible, the 
> > user just has to select a license from a list of licenses. A user agent 
> > could pre-select a license based on the value of the page's rel=license 
> > link(s), or based on scanning the page for mention of a license, too.
> 
> AFAIK, the CC namespace exists for this purpose and answers some fairly standard questions.
> 
> >      * When licensing a subpart of the page, existing implementations must
> >        not just assume that the license applies to the whole page rather than
> >        just part of it.
> > 
> > This is resolved by not having a mechanism for machine-readably licensing 
> > just part of a page, and instead putting such content on its own page, 
> > which leads to a better experience anyway from a search perspective.
> 
> Add a severely worse experience from a programmers standpoint. Software
> will need to scrape all linked documents - a browser add-on doing
> something with licensing information over a collection of items would
> suddenly be an enormous waste of HTTP requests.
> 
> > In conclusion, it seems most of these use cases are already handled by the 
> > current text in the spec and do not show a need for a more elaborate 
> > scheme. The rel="license" feature in particular handles search adequately, 
> > and is already deployed both in consumers and generators. Two areas where 
> > we could add more syntax-level support would be in licensing subparts 
> > explicitly, and in providing machine-readable licenses. The former seems 
> > like an obvious need but actual deployed content doesn't seem to need it, 
> > since most individually licensed works exist on pages of their own 
> > already, or are covered by the same license as other works on the same 
> > page.
> 
> Well, this topic seems to be done then.
> 
> 
> *Sighs*
-- 
Nils Dagsson Moskopp
<http://dieweltistgarnichtso.net>




More information about the whatwg mailing list