Re: Re: mod_enclosures proposal

> Why isn't it that simple? why don't we leave serialization behind and
> care about a clean model as FOAF is doing?

You're obviously not aware of issues with foaf parsing not being as simple
and clean as many developers expect.

> The statement "http://example.org/apage
> rdfs:description 'ugly'" may have different truth value for you and me,
> but if I ever assert it you can expect me not to assert
> "http://example.org/apage rdfs:description 'beautiful'" at the same time.

Ah, but you didn't assert it as the same.  Each item was different and it'd
be entirely reasonable to have your example of a good design example versus
a bad writing example.

> >Well, in some theoretical world of what is POSSIBLE that's arguable.  In
the
> >realm of what's PRACTICAL as well as in the RSS specs that's hogwash.
The
> >use of an image for an rss feed is already clearly established in the
specs.
> >
> >
> Exactly, we include images and not particular encoding of images. These
> are irrelevant, and wherever possible rss-feed should link to the
> content-type-independent url of the image.

Unfortunately for you, no part of the spec supports that argument.

> I see no contradiction
> between the rss spec and the proposed best practices such as "cool
> uris", there is of course a gap between currently implemented web and
> the web designed by w3c recommendations. but just reproducing the
> existing won't bring us further.

Nor will pushing inane examples.  This is perhaps a fundamental reason RDF
hasn't gained effective traction.  Too many examples of pie-in-the-sky
theories that are impossible to parse.

> It was suggested on this list, that RSS should not completely rely on
> http for content negotiation as there are other protocols for exchanging
> rss (such as freenet). I agree, but think that the http features should
> be supported as well, and that http-urls should be usable in the general
> case and not only when they identify a determined encoding of a resource

Well, for developers to break out of the "single call to download it all"
mindset they're going to have to be given reasonble steps to follow.  Giving
them type data is a much more likely way to encourage uptake than to force
conneg onto them.  Many of the tools they're using (sad to say) do a
horrible job of supporting it.  Why raise the bar to such a height as to
make it impossible for them to try?

> I may want to enclose http://example.org/videos/current-advertising in
> my feed without knowing about all the formats the video is delivered or
> will be delivered in the future, it may however be useful to specify in
> the feed that the resource is meant to be a video.

In the context of enclosures it's reasonable to assume the type of the
content is as the element describes it.  Should it need to use something
different it's more than welcome to do so when that time arrives.

> So you are saying that "cool uris" are poorly chosen uris because they
> don't identify the encoding?

No, that expecting a typed URI will deliver that type and that untyped
elements aren't terribly useful towards solving the demands the users and
developers are requesting.  That untyped URI and conneg /could/ be used is
theoretically possible.  Practical, however, no.

> looking at the serializations of rdf-graphs is like looking at text
> files in binary: please avoid using upper-case so I can easily recognize
> letter by the trailing '011'.

Yes well, the tool developers need more than nonsensical replies and
theories.

-Bill Kearney



 
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/