Re: [videoblogging] rel=no_enclosure + CC License clause for re-hosting controls (was: Is it Fair Use to link directly to a vlog's video?)
No. I think it would confuse more than it would help.Ok, i can agre with that. As I mentioned in my last email this is already handled by the present CClicenses. I'll have to go back and review that then. I thought the re-hosting part was more inferred. Thanks.sullOn 4/10/06, Andreas Haugstrup <[EMAIL PROTECTED]> wrote: On Mon, 10 Apr 2006 22:17:38 +0200, Michael Sullivan<[EMAIL PROTECTED]> wrote:> So, should their be an opposing rel=no_enclosure so services like> feedburner > and blog engines etc can easily skip that media excluding it from the RSS> channel?No. I think it would confuse more than it would help. You already haveRelEnclosure, so when you use RelEnclosure you already speficy the opposite relationship - all links without rel="enclosure" should beregardles as not being enclosures. The problem is that many scrapers areover-zealous. A sane algorithm would only include enclosures for the following conditions: - Any link marked with rel="enclosure" - Any elements - Any and elementsTwo years ago when this media scraping thing got started for real the programmers were more worried about "making it easy" for the publishers soevery link got scraped. I "fought" with especially Peter when he startedmefeedia about this issue. I thought then and think now that the over-zealous was a short term solution - a long term solution is thealgorithm above.I hate to say I told you so, but you got what you asked for. If scrapersand services rigidly enforced RelEnclosure from the start in 2004 we would not be having this discussion.> 2*> Should Licenses such as Creative Commons provide optional clauses that> state> whether or not the media can be re-hosted without opt-in and> re-distributed > from that host?> Would this streamline how media travels within all of the mediaspheres on> the Internet?As I mentioned in my last email this is already handled by the present CClicenses. --Andreas Haugstrup Pedersenhttp://www.solitude.dk/ >Commentary on media, communication, culture and technology.Yahoo! Groups Links <*> To visit your group on the web, go to:http://groups.yahoo.com/group/videoblogging/<*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED]<*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/-- Sullhttp://vlogdir.com http://SpreadTheMedia.org YAHOO! GROUPS LINKS Visit your group "videoblogging" on the web. To unsubscribe from this group, send an email to: [EMAIL PROTECTED] Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
Re: [videoblogging] rel=no_enclosure + CC License clause for re-hosting controls (was: Is it Fair Use to link directly to a vlog's video?)
On Mon, 10 Apr 2006 22:17:38 +0200, Michael Sullivan <[EMAIL PROTECTED]> wrote: > So, should their be an opposing rel=no_enclosure so services like > feedburner > and blog engines etc can easily skip that media excluding it from the RSS > channel? No. I think it would confuse more than it would help. You already have RelEnclosure, so when you use RelEnclosure you already speficy the opposite relationship - all links without rel="enclosure" should be regardles as not being enclosures. The problem is that many scrapers are over-zealous. A sane algorithm would only include enclosures for the following conditions: - Any link marked with rel="enclosure" - Any elements - Any and elements Two years ago when this media scraping thing got started for real the programmers were more worried about "making it easy" for the publishers so every link got scraped. I "fought" with especially Peter when he started mefeedia about this issue. I thought then and think now that the over-zealous was a short term solution - a long term solution is the algorithm above. I hate to say I told you so, but you got what you asked for. If scrapers and services rigidly enforced RelEnclosure from the start in 2004 we would not be having this discussion. > 2* > Should Licenses such as Creative Commons provide optional clauses that > state > whether or not the media can be re-hosted without opt-in and > re-distributed > from that host? > Would this streamline how media travels within all of the mediaspheres on > the Internet? As I mentioned in my last email this is already handled by the present CC licenses. -- Andreas Haugstrup Pedersen http://www.solitude.dk/ > Commentary on media, communication, culture and technology. Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/videoblogging/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
Re: [videoblogging] rel=no_enclosure + CC License clause for re-hosting controls (was: Is it Fair Use to link directly to a vlog's video?)
Hello Michael,On 4/10/06, Michael Sullivan <[EMAIL PROTECTED]> wrote:
So, let's discuss.pros and cons to these two thoughts please1*Semantic HTML is used to specify a media link that should be used as an RSS enclosure in the form of rel=enclosure. see here:
http://microformats.org/wiki/rel-enclosureTheir are cases when hotlinking to media in a blog post etc where the author does not want to re-syndicate that media in RSS as a downloadable enclosure (attached file).
So, should their be an opposing rel=no_enclosure so services like feedburner and blog engines etc can easily skip that media excluding it from the RSS channel?Some points on this...
#1: I think we should choose a different name other than "no_enclosure". (I'm guessing you're thinking of rel-nofollow. But that choice of name goes against the HTML specs.) The name that's choosen should be a noun.
What's a good noun for "not part of this"? Or "not mine"? ("external"? "borrowed-object"?) Anyone have any suggestions?#2: If we're applying this to an or element, then we can NOT use the "rel" attribute. Since neither of these HTML elements has that attribute. (And yes, I know that the , , , and elements should have this. I tried arguing for them in the WHATWG to get this added to HTML5... but I couldn't seem to get support for it.)
The attribute we do have to add semantics is the "class" attribute. (And I know, most people are probably thinking something like... wait, "class" is for applying stylesheets
. That's actually a very common misconception. The "class" attribute is alot like the "rel" and "rev" attributes in that it expresses sematics as well.) So...It might be something like:
(Where "abc" would be replaced by whatever we decide to call this thing.)
2*Should Licenses such as Creative Commons provide optional clauses that state whether or not the media can be re-hosted without opt-in and re-distributed from that host?
Would this streamline how media travels within all of the mediaspheres on the Internet?I think that this really goes beyond the Creative Commons. (This is something I've been thinking about for quite a while.) We need to be able to expresses "contracts"... or more specifically, "permissions", "restrictions", and "requirements" for "contracts" in machine readable form. (And we'd need the "legal framework" to make it "safe". So that people who do things based on these "permissions", "restrictions", and "requirements" don't have to worry about getting sued. This would be similar to what has been done by the Creative Commons with their set of licenses.)
With all that, things can be automated and streamlined.So,... you'd have ways of saying... "You can do X". "You can NOT do Y". "You MUST do Z". and "You MUST NOT do W".
You'd then need to come up with a way of expressing this in Semantic HTML, XML, RDF, etc.A machine that understands this could even have overrides for "inaliable rights" in a country. (For example, if a "contract" like this said, "You MUST NOT breath"... in most countries [as I understand it] that would legally be allowed to be ignored and the rest of the "rules" of the contract would apply. Well, assuming nothing else in it violated inaliable rights of the parties involved.)
Some other notes, you may want to have those "X", "Y", "Z", "W" be a URLs. The URL would point something like the Creative Common deeds. There would be a "normal English" description of it, as well as "Legalleze". Software would be pre-programmed to auto-understand commonly agreed upon set of these things. (Kind of like the way RSS readers auto-understand various RSS extensions.)
As new ones come out and become popular they would gain adoption. If the software gets something it doesn't yet understand, it could ask the user (in some way) what they want to do. (Maybe by popping up a window. And letting them somehow look at the document.) I could even ask the user how they want to handle this "condition" in the future. (So they don't have to be asked again.)
Did that make sense? (I know I've kind of rushed the explaination.)See ya
Thanks,sullOn 4/10/06, Charles Iliya Krempeaux
<[EMAIL PROTECTED]> wrote:
Hello Michael,I think you are on the right track. What you're alluding to is using Semantic HTML.(Some of you may have heard the term "Micformat" before. A "Microformat" is basically just Semantic HTML with a Specification.)
Although, just to nit-pick :-) ... It should be class="no_enclosure" (instead of rel="no_enclosure") if you're putting this on an or element. (I won't bore you with the details of "why" unless you ask to hear it.)
Semantic HTML has the advantage that this is machine readable. That way the whole process can be automated. (And not just by your vlogging software, but by many many other kinds of software too. Which produces all sorts of social implications. Which are hopefully "good".)
See yaOn 4/10/06, Michael Sullivan <
[EMAIL PROTECTED]> wrote:
hmmm, maybe we shou
Re: [videoblogging] rel=no_enclosure + CC License clause for re-hosting controls (was: Is it Fair Use to link directly to a vlog's video?)
On 4/10/06, Michael Sullivan <[EMAIL PROTECTED]> wrote: > So, should their be an opposing rel=no_enclosure so services like feedburner > and blog engines etc can easily skip that media excluding it from the RSS > channel? In my own scraper, if I find any rel=enclosure then I assume that all enclosures will have a rel=enclosure attribute. I assume that feedburner does the same, since this is a pretty intuitive way to do things. The way to be sure that some media will not be pre-fetched, then, is just to have at least one rel=enclosure on some other item. Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/videoblogging/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
