Hello Manu Manu Sporny wrote: > Andy Mabbett wrote: > >>> "By adding rel="enclosure" to a hyperlink, a page indicates that the >>> destination of that hyperlink is intended to be downloaded and cached." >>> >> I don't take issue with that definition; I simply don't believe that a >> streaming audio feed, (say, one running 24/7, like BBC Radio 4's) can >> ever be an "enclosure". >> >> Consider the usage "I have downloaded it and enclose it with this >> e-mail". >> > > Your issue has to do with the semantics of the word "enclosure", which > unfortunately means something a bit different in the English language as > it does in the computing realm. > > It's a valid point - and I'm a bit torn as you could interpret it in > different ways. Like you said, one could use it in the following sense: > > "I have downloaded it and enclose it with this e-mail", which would be a > valid use of enclosure. > > It all depends on what you're "enclosing"... are you enclosing the > actual file or a reference to the file. My interpretation is that > rel-enclosure states that you're "enclosing a reference to a > representation of what you are discussing". > > A better analogy would be: > > "I have enclosed a device that will let you listen to this radio > station.", as well. > > Or... "I have enclosed a portal to let you listen to this audio stream". > > I do admit, however, that this concept will be lost on those that don't > know much about knowledge representation... so perhaps there is a better > word than rel-enclosure? > > >>> My preference is to resolve that rel-enclosure is applicable to both >>> static and streaming files and note the decision on the rel-enclosure >>> wiki page. >>> >> In which case "enclosure" is a misnomer. "Embedded" might be better. >> > > It's better, but you can't really embed or enclose something that has no > end or temporal boundary, can you? (unless we get into the realm of 5 > multi-dimensional physics). > > rel="manifestation", rel="download" or rel="representation" are more > accurate. > > rel="download" is basically what we decided to use for the Media RDFa > vocabulary (which the Audio RDFa vocabulary is layered upon): > > http://purl.org/media > > So, that's an option if we'd like to keep both vocabularies in sync, or > offer rel-download as an alternative to rel-enclosure. > > The down-side is that rel-enclosure already exists and we should re-use > when possible. > > Thoughts from the community? > > I think Andy's issue is the definition of rel-enclosure
"By adding |rel="enclosure"| to a hyperlink, a page indicates that the destination of that hyperlink is intended to be downloaded and cached. " http://microformats.org/wiki/rel-enclosure#Abstract Certain kinds of audio can not be physically downloaded to your hard drive or cached anywhere, consider shout-cast streams and web radio stations, also audio that can only be accessed through flash players need to be considered, so rel="manifestation", rel="download" or rel="representation" still suggests that they are something that can be cached and saved elsewhere, rel ="stream" may be more accurate for marking up audio that can't be downloaded or cached but still playable. This theory still isn't conclusive, so I hit the audio-info examples page (again) for further analysis, what I was looking for is evidence of audio that is streamed to the user, without being downloaded and typically played in the browser by some form of player commonly a Flash Player the evidence was remarkable. Out of the 38 examples available on: http://microformats.org/wiki/audio-info-examples#Service_Publishing_of_Music 16 examples Do Have a stream 15 examples Do Not have a stream 7 examples are Unavailable I have made the study available on Line for viewing http://weborganics.co.uk/docs/Stream-Analysis.txt I would like to propose rel="stream" for these kinds of files. Best Wishes. Martin McEvoy > -- manu > > _______________________________________________ > microformats-new mailing list > [email protected] > http://microformats.org/mailman/listinfo/microformats-new > _______________________________________________ microformats-new mailing list [email protected] http://microformats.org/mailman/listinfo/microformats-new
