Re: enclosure status?

--- 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.

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

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