Re: mod_enclosures proposal

--- In [email protected], "Bill Kearney" <ml_yahoo@i...> wrote:
> 
> Why not make better use of RDF and more closely model it after the
way a 2.0
> element appears?
> 
> <enc:enclosure rdf:resource="http://some/external/file.mp3" />
> 
> Or merely use:
> 
> <rdfs:seeAlso rdf:resource="http://some/external/file.mp3" />
> 
> And then use a subseqent rdf:Description to 'say more' about it:
> 
> <rdf:Description rdf:about="http://some/external/file.mp3" />
>     <dc:title>Some music file</dc:title>
>     <dc... insert various and sundry dublin core elements.... />
> 
>     <enc:length>1939570</enc:length>
>     <enc:type>audio/mpeg</enc:type>
> 
>     ...as well as anything else...
> </rdf:Description>

I do not see how this closer to RSS 2.0 syntax. I think my example
below is much closer.

However if your approach is more sensible from RDF point
of view, is not so clear to me. Frankly, I am still new
to RDF, and while I think I understand it more or less enough,
I am still not sure about common practices and good styles
in RDF. Perhaps some RDF experts here could comment?

> Given that RDFs already has a great many ways to describe
collections,
> alternates and the like it seems like a sort of bad idea to go
reinventing
> them here.

Actually we don't. We use standard "Alt" and "Seq" collections.
There is one which is not present in RDF: "Parallel" which we have
added.

 > It's true that discovering this data does require using RDF-centric
methods.
> It doesn't require using only an RDF capable parser (although it
helps) as
> much as it requires knowning to /look/ for the added metadata.
> 
> So rather than ask folks to jump through a different sort of hoop,
why not
> just make it clear that using RDF constructs are helpful and worth
> understanding for /more/ than just things like enclosures?   This
way they
> learn more about handling *ANYTHING* and not just a special case. 
They'll
> have to learn the special case anyway but at least their tool will
have
> learned something else for the in-between handling.
> 
> -Bill Kearney
> 
> 
> ----- Original Message ----- 
> From: <lord@c...>
> > --- In [email protected], Danny Ayers <danny.ayers@g...>
wrote:
> > > I'd better start by apologising for not having checked the
current
> > > proposal(s) before posting, and for stating something that's
> > probably
> > > obvious. I do think it's important though. I'd suggest there
are two
> > > specific requirements that override all the others:
> > >
> > > 1. to be able to cover the simplest case in simple syntax:
"this is
> > an
> > > enclosure, here is the URI, this is the media type" (*one*
> > enclosure)
> > > 2. to be able to add metadata to it
> >
> > Danny,
> >
> > The requirements you have are certainly was high on our
> > list when we put together the proposal.
> >
> > For example here is single enclosure in current, RSS 2.0
> > spec syntax:
> >
> > <item>
> > ...
> >     <enclosure
> >        url="http://www.crocodile.org/sounds/matrosi.mp3"
> >        length="1939570"
> >        type="audio/mpeg" />
> > ...
> > </item>
> >
> > and in our, proposed one in RSS 1.0:
> >
> > <item>
> > ...
> >     <enc1:enclosures>
> >         <enc:Enclosure
> >             enc:url="http://www.crocodile.org/sounds/matrosi.mp3"
> >             enc:length="1939570"
> >             enc:type="audio/mpeg" />
> >         </enc1:enclosures
> > ...
> > </item>
> >
> > I think we are as close as possible to the orignial syntax. Also
> > it is quite simple.
> >
> > As to adding metadata, this is provided by us by nature of RDF,
and
> > users can attach any kind of peoperties to enclosure nodes. We
could
> > not foresee
> > all possible kind of properties for all possible data types
enclosure
> > can contain,
> > so we left this open and defined only basic properties like
"length".
> >
> > Check out the proposal, it have more details. We will be glad to
hear
> > your and other people feedback.
> >
> > Sincerely,
> > Vadim





 
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/