[uf-new] hAudio Issue D4: 2008-01-10 rel-enclosure does not allow for links to streaming files

[Martin McEvoy]

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 +AHw-rel="enclosure"+AHw- 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+ACM-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+ACM-Service+AF8-Publishing+AF8-of+AF8-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
>
> +AF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXw-
> microformats-new mailing list
> microformats-new+AEA-microformats.org
> http://microformats.org/mailman/listinfo/microformats-new
>