Re: Re: mod_enclosures proposal

Bill Kearney wrote:

>>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.
>  
>
this has nothing to do with rdf schema but with modeling the enclosure 
as resource or not.

This

<item rdf:about="/articles/design">
   <enc:enclosure rdf:resource="http://example.org/apage" rdfs:description="bla" />
</item>

corresponds to the following 3 statements:
/articles/design rdf:type item
/articles/design enc:enclosure http://example.org/apage
http://example.org/apage rdfs:description="bla"

While this

<item rdf:about="/articles/design">
   <enc:enclosure enc:uri="http://example.org/apage" rdfs:description="bla" />
</item>

corresponds to 4 statements:
/articles/design rdf:type item
/articles/design enc:enclosure _:A
_:A enc:uri http://example.org/apage
_:A enc:uri rdfs:description="bla"

As you see these are different graphs, in the second variant the enclosure is a resource distinct from the enclosed document. Different enclosures with the same target may have different other properties, in the first one the properties of each enclosure are properties of the enclosed document and vice-versa.


>>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.
>  
>
Let me try to be more explicit:

More abstract model: File system  ^= RDF model
Encoding method: FAT ^= RDF/XML
Lower-level storage: disk sectors ^= XML Files

>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.
>  
>
Not at all, they did stuck to their specs. Just their spec was made in a 
way that the floppy could be interpreted as FAT-File system but it was 
also guaranteed that the data would be in specified sectors of the disc. 
If you looked at the disk without understanding FAT you could use it, 
but you thought it would be over complicated (from this point of view 
there was no obvious reason for having things like pointers to the next 
cluster). Same with RSS 1.0: if you look at it without knowing about 
RDF/XML you just see awkward XML, there is no reason for rdf:Seq and 
stuff. On the other side: you couldn't create a floppy disk conforming 
to the spec just by using a FAT- Capable OS,  same as now you cannot 
create RSS just by using a schema aware RDF-Editor.

> ...
>
>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.
>  
>
Why isn't it that simple? why don't we leave serialization behind and 
care about a clean model as FOAF is doing?

>>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.
>  
>
Well the world of evaluation of gustibus-statements is not very 
intersubjective.  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.

>><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.
>  
>
I could have used rdf:types with disjoints classes.

>>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.
>
>  
>
The model contains both the statements:

http://example.org/apage rdfs:description "A bad example"
http://example.org/apage rdfs:description "A good example"

If its not contradictory enough just change the example. There is no 
grouping or order of the statement: an RDF/XML file is a serialization 
of a graph, a graph is a *set* of statements. You'll find no wizard that 
can help you! There are no contexts in RDF, and if there would be it 
would be modeled differently in RDF/XML.

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

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

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

>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.
>  
>
So you are saying that "cool uris" are poorly chosen uris because they 
don't identify the encoding?

>>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.
>  
>
mod_enclosure should make it possible to specify that different uris are 
alternative representation of the same enclosed document, as well as the 
different formats an url may support.

>>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 don't understand. Where's the paternalistic approach? do you conclude 
that nobody wants content-negotiation from the fact that it is rarely 
used today?

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

reto


 
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/