Re: [whatwg] [Fwd: Re: Helping people seaching for content filtered by license]
Nils Dagsson Moskopp writes: Am Freitag, den 08.05.2009, 19:57 + 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. 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. smallcopy; 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 Merely using rel=license in the above example would not cause the copyright message to be displayed to users. that an unambigous (read: machine-readable) writeup of part licenses is impossible ? Why does the license information need to be machine-readable in this case? (It may need to be for a different scenario, but that would be dealt with separately.) 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. smalla 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 ? No. But if a human sees a string that mentions © copyright or license then she's likely to realize it's licencing information. And if it's placed next to a picture it's conventional to interpret that as applying to a picture. It's also conventional for such information to be small, because it's usually not the main content the user is interested in when choosing to view the page. Magazines and the like have been using this convention for years, without any need to explicitly define what indicates licensing information, seemingly without any ambiguity or confusion. Smylers
Re: [whatwg] [Fwd: Re: Helping people seaching for content filtered by license]
On Fri, May 15, 2009 at 8:40 AM, Smylers smyl...@stripey.com wrote: Nils Dagsson Moskopp writes: Am Freitag, den 08.05.2009, 19:57 + 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. [...] Why does the license information need to be machine-readable in this case? (It may need to be for a different scenario, but that would be dealt with separately.) It would need to be machine-readable for tools like http://search.creativecommons.org/ to do their job: check the license against the engine's built-in knowledge of some licenses, and figure out if it is suitable for the usages the user has requested (like search for content I can build upon or search for content I can use commercialy). Ideally, a search engine should have enough with finding the video on either Tara's site *or* Paul's blog for it to be available for users. Just my two cents.
Re: [whatwg] [Fwd: Re: Helping people seaching for content filtered by license]
Eduard Pascual writes: On Fri, May 15, 2009 at 8:40 AM, Smylers smyl...@stripey.com wrote: Am Freitag, den 08.05.2009, 19:57 + 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. Why does the license information need to be machine-readable in this case? (It may need to be for a different scenario, but that would be dealt with separately.) It would need to be machine-readable for tools like http://search.creativecommons.org/ to do their job: check the license against the engine's built-in knowledge of some licenses, and figure out if it is suitable for the usages the user has requested (like search for content I can build upon or search for content I can use commercialy). Ideally, a search engine should have enough with finding the video on either Tara's site *or* Paul's blog for it to be available for users. Yeah, that sounds plausible. However that's what I meant by a different scenario -- adding criteria to the above, specifically about searching. Hixie attempted to address this case too: 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. To which Nils responded: 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. It's perfectly valid to disagree with this being sufficient (I personally have no view either way on the matter). I was just clarifying that the legend mark-up example wasn't attempting to address this case, and wasn't proposing legendsmall (or whatever) as a machine-readable microformat. Smylers
