Re: Re: mod_enclosures proposal

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

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.

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.

> - it is not suitable for protocols that support content-negotiatiation.
> when the same resource has multiple enc:type's it is impossible to
> associate these to the correct enc:length's or enc:qualitiy's. e.g., if
> it seems obvious in this rdf/xml representation
>     <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.

> that the png version of the image is smaller than the gif version it is
> not in the rdf graph: exchanging the values of the enc:length attributes
> would result in the same rdf.

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.

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