Re: Re: mod_enclosures proposal

> I'm talking about disadvantages of using rdf:resource in Suzan's
> variants, the points do not apply for the variants with enc:url in which
> the enclosure is an anonymous resource.

How so?  The downside to using them as enc:url is they're opaque to anything
that doesn't already understand that namespace.  Unless an RDF schema is
applied there's nothing about them that clarifies they're resources.

> An anecdote (just once): Eight years ago, my bank delivered the
> information of incoming payments on a floppy disks. The specification
> how the data is provided was really complicated, they described what
> information there is in every sector of disk. Complicated enough that I
> thought I had to access floppy disk sectors directly, the floppy disk
> was also specified to contain redundant data without apparent use. Well,
> after putting the disk in my mac, the disk turned out to be
> interpretable as normal FAT-File system with a text file containing the
> transactions.

While that's quaint tale, it hardly seems to parallel anything here.
Wouldn't you have been surprised, however, if they'd actually stuck to their
specs?  Oh, wait, you'd then be part of the 'defacto' standard camp and
raise a great stink about breakage.

> The moral: serializing
> RDF is not a nightmare (easy as moving a file on a floppy), but
> serializing it so that it can be understood by those who don't
> understand RDF is.

I disagree with that analogy as it's nowhere near that simple, nor should it
be.  While at some point it may BE that simple we're still a ways from
there.  I can recall the days of using hard sectored 8" single-sided
floppies so I know the horrors.

> I think it is not useful (and developing semantic web applications
> becomes incredibly hard) if statements about a resource can be true and
> false in different contexts (in the same world).

That's ridiculous.  I could claim in metadata that I found a particular
piece of audio to be "bad".  Likewise someone else could come along and
claim it's "good".  De gustibus non desputandum est. (but don't hold me on
the spelling).  It's riduculous to think any or all statements can or even
should be held as truthful without an appreciation of their provenance
and/or context.

> Modeling enclosures as
> own resources (as opposed to identifying the enclosure with the enclosed
> document) makes it possible to merge models without creating
> contradictions.  Doing it the other way, we may have contradictions in
> one and the same rdf document, consider:

> <item rdf:about="/articles/design">
>    <title>designing web pages nicely</title>
>    <enc:enclosure rdf:resource="http://example.org/apage"
rdfs:description="A bad example"/>
> </item>
> <item rdf:about="/articles/writing">
>    <title>writing websites eloquently</title>
>    <enc:enclosure rdf:resource="http://example.org/apage"
rdfs:description="A good example"/>
> </item>

That's a pretty weak example.  The string description has no meaning, at
least not from any machine processable learning standpoint.

> While looking at the xml it seems clear what the author wants to express,
> looking at the rdf-graph you can't even guess it
> (exchanging the two rdfs:description attributes produces the same graph!).

I'll defer to those better versed in deciphering RDF (esp in N3) but I'd
venture you're wrong.  The items themselves do represent using the
enclosure.

> In the example the url http://example.org/images/logo represents *one*
> resource, the logo of "example.org". The different variants of the logo
> may have additional uris on their own, but what the author of the
> rss-feeds most likely wants to reference is the logo itself and not one
> specific format of it.

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.
The choice of what image type to use is left to the publishing source with
the expectation being the consumer will take whatever steps are necessary to
accomodate it.  While having alternative representations is certainly a
clever idea there's nothing in the RSS spec that supports doing it.
Besides, even if that were the case there'd be other markup using rdf:Alt
containers to handle it anyway.

> Of course RSS should not force developers to use
> http content-negotiation, but enc:type should be optional

I, and several other folks, STRONGLY disagree with the idea of omitting type
markup.  There's really very little reason to publish something like an
enclosure without taking the mere milliseconds to properly annotate it's
type.  Sure, a poorly chosen URI could get reused over time and eventually
retyping of it would be "bad" for an accumulated triplestore.  Omitting it
from a feed, however, is not the way to solve that bad design decision.

> and specifying  multiple types of a resource must be possible as well.

I'm all for alternation being possible.  I can well forsee why someone would
want to know that 6 different forms of the intended enclosure could be
obtained.  Low-fi in mp3 for some, 56k in WMA for others and whatever else.

> I'm not telling
> the developers that they *have* to do anything, but if they want to
> provide "cool uris" [1] they should be able to, for the user it is an
> advantage, as she doesn't care about the format but is lucky when she's
> able to open a bookmark on other devices and even after unisys removed
> all our gif-viewer.

I think you're espousing a valid position, just that nobody wants or needs
to use it.  I also think that taking "paternalistic" approaches to what
users will or won't do to obtain use of the content is a bad idea.

> I'm not! It's one resource! and lets not talk about markup but about
> graphs first (we'll find the easiest serialization for hand-written
> rdf/xml later, and if it's not easy enough.... tans pis).

I don't disagree with the sentiment of discussing design first.  But I balk
at it when I look back at some of the other debacles of RDF theory dragging
along horrendous markup.  Best to keep it foremost to avoid it becoming
something that won't gain any traction.

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