Re: mod_enclosures proposal

--- In [email protected], Suzan Foster <su@i...> wrote:
> On Nov 18, 2004, at 10:03 PM, lord@c... wrote:

> I think that you could profit from a less verbose syntax by losing
the 
> <enc1:children/>. In your proposal the class Enclosures is a class 
> which contains a single property which has a Collection class
which, 
> etc.. I think the semantics should be: item has a property
enclosures, 
> which is a collection of, etc.. I tested this with a pair of SPARQL 
> queries (see below), and as you can see the <enc1:children/> is
totally 
> redundent and just adds an extra triple pattern to get to where you 
> want to be.

Actually, besides "children" "Enclosures" have other properties,
such as "rel" and "description". I think they are useful.
 
> I'm also not sure what kind of ranges you expect with enc1:quality.
The 
> numerical value doesn't seem to express much unless you know it's
exact 
> meaning whilst enc1:quality="high" is maybe subjective, but
directly 
> apparent in it's meaning.

What if there is no "high" quality enclosure in the list? Only
"medium" and "low"?

Right now we have numerical range 0-1.0 which show relative quality. 
To get best quality you should find one with maximum quality value.
The key is that the value is "relative". If one enclosure have quality
0.25 and another is 0.5, it only means that author suggest that second
one is twice as preferable than first. It does not mean that first one
have 25% of some "perfect" representation. Maybe I need to clarify
this a bit in the document.

If we go with enumerated values, we will restrict users to smaller
range. I will be pressed to come up with more that 10 words describing
quality gradations, which might not be enough. :)

Also quality value should be considered together with client
capability to show different formats. I think that sensible display
algorithm would be first to see if "preferred" enclosure format is
supported and if yes to show it without looking further at other
alternatives. If it is not supported, display agent should get list 
of alternatives, sort it in descending order according to quality
factor and go down the list, displaying first one, in format it could
handle. 

Only in some very rare cases, display software might actually need to
analyze quality values besides using them as sorting criteria. Such
example could be environments where there is a "cost" of displaying 
different formats is substantially different. This cost could be CPU
cycles for format conversion, or perceived quality degradation due to
the limitation of viewers for particular format. If I would be
developing enclosures processing for such environments, I would weight
display formats supported by viewer by "cost" on the 1-0 scale (with
1.0 for best supported and 0 for not supported at all formats). Then,
for each enclosure alternative I will build "normalized" quality by
multiplying enclosure own "quality" value by display format "cost
factor" value. Then, I would sort according to this combined value and
will select first one from top with non-zero normalized quality value.

Going with enumerated list of possible "quality" values will not
permit us to do such intelligent processing, while simplification 
of the format will be not so substantial.

Sincerely,
Vadim





 
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/