Re: Re: mod_enclosures proposal

Bill Kearney wrote:

>>- it does not allow to assign properties to the enclosure that are not
>>properties of the enclosed documents. for example enclosures with the
>>same target may have different rdfs:label's and another rdfs:label may
>>be an appropriate for the target itself. also properties may be added to
>>an enclosure to tell clients how to present the resource to the user,
>>which dependents on the enclosing resource and not only on the enclosed
>>document.
>>    
>>
>
>I'm not following you.  You're saying that a compact serialization can't be
>accomplished, right?  While RDF's serialization in XML may have some "hoops"
>you have to jump through it's very rarely the case that you "can't" express
>it properly.
>  
>
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.

>Finding the right way to serialize it such that it's not a parsing nightmare
>is certainly considered one of RDF's downsides.  Until you actually need it,
>that is.
>  
>
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. The bank did the same as we are now doing with RSS, they 
specified how the low-level serialization should look like in a way that 
the data can also be interpreted with higher lever abstractions. luckily 
I just had to read the floppy, same as today users of rdf-tools (such as 
jena) have difficulties writing correct RSS 1.0 it would have been very 
hard for me to produce a spec conforming floppy. 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.

>There are always going to be scoping issues when triples are layered.  Your
>example of multiple labels applied to the same resource, while true, is
>certainly a matter of scope.  Use of a label for a resource would certainly
>need to be aware of what context was used to describe it.  I could see how
>dumping many different triples together would pose that risk of confusion
>but I'd question whether that's not a problem with ANY combination of data.
>  
>
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). 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>
...

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

>>    <enc:enclosure rdf:resource="http://example.org/images/logo"
>>enc:type="image/gif" enc:length="5897"/>
>>    <enc:enclosure rdf:resource="http://example.org/images/logo"
>>enc:type="image/png" enc:length="4987"/>
>>    
>>
>
>Why are you using the same URI for two different resources?  Why would you
>need to?  To force the type delivery to be controlled during the connection?
>While that might be something some might want to /try/ using it doesn't seem
>like a terribly good idea.  In theory it'd work but in practice getting
>developers to actually use it /properly/ might be an impossible challenge.
>I mean, get real, you're telling the developer the type of the remote
>resource (and some folks whine they don't even want to do this) and then
>you're telling them they'll *HAVE* to use that during connection
>negotiation?  I understand the mechanics of doing it but seriously question
>the likelihood of it being /useful/ to most situations.
>  
>
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. Of course RSS should not force developers to use 
http content-negotiation, but enc:type should be optional and specifying 
multiple types of a resource must be possible as well. 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.

>Well, the fact that you used the same URI for two entirely different
>resource has more to do with the problem than any attribute markup.
>  
>
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).

reto

1. http://www.w3.org/Provider/Style/URI


 
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/