Re: Re: enclosure status?

On Sat, 9 Apr 2005, Vadim Zaliva wrote:
> --- In [email protected], Danny Ayers <danny.ayers@g...> wrote:
> Yes, I think proposals are non-conflicting, essentially my proposal
> just adds whole lot of bells and whistles. I feel that Suzan's leaves
> too many things open, and non RDF-guru developers have to figure out
> on their own and we may end up with non-compatible implementations.

Can we merge these two proposals, so that there is a minimal syntax based 
on Suzan's model and a maximal syntax based on yours?  I strongly agree 
that alternative formats need to be supported, since virtually all 
playlist formats have that feature.

About Bittorrent in particular, that's a tough nut to crack because BT is 
so contrary to web architecture.  There must be prior art for indirection 
of that kind, though.  ?

- Lucas

>
> Couple of questions they might have:
>
> 1. How one specify alternative formats? This is the most frequently
> asked feature.
> 2. How one specify multiple enclosures?
> 3. How one provide information about which of alternative formats are
> most preferable?
>
> I can put forward sample use-cases where all these features are
> needed.
>
> Current version of Suzan's proposal does not address #2 and #3.
>
> I also disagree with her approach on BitTorrent. Looking at her
> example, you will notice that BitTorent version of enclosure does not
> provide any information about content type of an object. Imagine you
> have audio file in several formats, all distributed with BitTorent.
> Following Suzan's proposal they will differ only by URL. So you need
> to actually download them first to figure out which one you want.
>
> Then come "nice to have" things, like "rel", "location", "ContentID".
> Yes, they are obvious and RDF allows to attach these and countless
> other things to enclosure anyway. But I think these are some people
> will need in first order, and offering to them a standard way of
> representing them will simplify their life a lot. Imagine yourself in
> the shoes of developer of RSS-based application: he might not even
> know much about RDF and would not have motivation and time to figure
> out how to define say, "location" property, that it is good idea to
> make it sub-property of dc:coverage and what are RDF formats for
> spatial information representation are out there he can use. We did
> this job for him.
>
> I really do not want to sound like I criticizing Suzan's proposal in
> order to push mine, but as developer who have need to use something
> like this right away, I just need to see proposal which provides
> certain level of functionality right now.
>
> Sincerely,
> Vadim
>
>
>
>
>> a general +1
>>
>> I'd note that the "competition" between the proposals here, well,
>> isn't really. The simple version of Suzan's proposal fits nicely at
>> the kind of level the builders of the current generation of RSS
> tools
>> are likely to be willing to support. But it doesn't particularly
>> dumb-down the domain model, and it would be straightforward to give
>> more information, for example following the methods in Vadim's
>> proposal. Taken as a whole that proposal would probably choke most
> of
>> the podcast developers, but in its minimal form it's almost
> identical
>> to Suzan's.
>>
>> Cheers,
>> Danny.
>>
>> [1]
>> On Apr 9, 2005 2:17 AM, crschmidt@c... <crschmidt@c...> wrote:
>>>
>>> On Sat, Apr 09, 2005 at 02:09:19AM +0200, Suzan Foster wrote:
>>>>
>>>>
>>>> On Apr 9, 2005, at 2:00 AM, Lucas Gonze wrote:
>>>>
>>>>>
>>>>>
>>>>> On Fri, 8 Apr 2005, Dan Brickley wrote:
>>>>>> but one quick point (all else looks good...): perhaps
> enc:url= could
>>>>>> be replaced with use of the rdf:resource= notation, which
> will
>>>>>> tell generic RDF tools that a URI is being used.
>>>>> ...
>>>>>> Using enc:url is OK, but will make certain RDF queries harder
>>>>>> to express, since the RDF layer wouldn't realise that the
> thing that
>>>>>> is the value of the enc:enclosure property is the thing with
> the
>>>>>> cc:permits and foaf:maker property, so more application-level
> smarts
>>>>>> would be required.
>>>>>
>>>>> Taking advantage of RSS 1.0's RDF-nature is a Good Thing, so I
> am for
>>>>> this.
>>>>
>>>> If there are no objections i'll make the changes.
>>>
>>> I am also in favor.
>>>
>>> --
>>> Christopher Schmidt
>>>
>>>
>>> [Non-text portions of this message have been removed]
>>>
>>>
>>> Yahoo! Groups Links
>>>
>>>
>>>
>>>
>>>
>>
>>
>> --
>>
>> http://dannyayers.com
>
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>


 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/rss-dev/

<*> 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/