Re: Re: mod_enclosures proposal

On Nov 24, 2004, at 12:50 AM, Bill Kearney wrote:

>
>> The following four validate:
>>
>> 1. <enc:enclosure enc:url="..." enc:type="..." enc:length="..."/>
>> 2. <enc:enclosure rdf:resource="..." enc:type="..." enc:length="..."/>
>> 3. <rdfs:seeAlso enc:url="..." enc:type="..." enc:length="..."/>
>> 4. <rdfs:seeAlso rdf:resource="..." enc:type="..." enc:length="..."/>
>>
>> My preference would be for either 1 or 2.
>
> Why not #4?  The idea being if we're going to get developers to pay
> attention to things we might as well get them to be able to do more 
> than
> just one thing.  If it uses an rdfs:seeAlso with an rdf:resource and a
> separate type we'd be opening the door to a lot more than just 
> enclosures.

The reason I prefer the first two above the fourth is due to how i 
would use it in rdql/sparql:

SELECT ?item ?enclosure
WHERE
	(?item enc:enclosure ?enclosure)

I now know that I have an enclosure. When I use rdfs:seeAlso however, I 
can not be so sure without post-processing of the results:

SELECT ?item ?other
WHERE
	(?item rdfs:seeAlso ?other)

With a rdfs:seeAlso I'd rather see the following so that I can select 
on class:

<rdfs:seeAlso>
   <enc:Enclosure rdf:resource="..."/>
</rdfs:seeAlso>

SELECT ?item ?enclosure
WHERE
	(?item rdfs:seeAlso ?enclosure)
	(?enclosure rdf:type enc:Enclosure)


However, this syntax doesn't address the wish of non-rdf parsers to 
keep it simple.

> Granted, the interest exists for enclosures and I'm all for the idea 
> but
> wonder if we'd be needlessly limiting things by not using #4.  I 
> suppose
> there would need to be something in the markup that made the assertion 
> it's
> indeed a thing to be used as an enclosure and #2 is probably "simpler" 
> at
> doing this.  I wonder if it's not overly simplified.
>
> For those not versed in RDF consider that by using an rdf:resource on 
> the
> URL (which #2 also does) makes for much easier finding its use in a
> triplestore situation.  Or in a big index or archive of lots of feeds.
> Using it as a enc:url type would /require/ use of an RDF schema to 
> clarify
> it's semantics.

SELECT ?url ?length ?type
WHERE
	(?item enc:enclosure ?enclosure)
	(?enclosure enc:url ?url)
	(?enclosure enc:length ?length)
	(?enclosure enc:type ?type)

SELECT ?url ?length ?type
WHERE
	(?item enc:enclosure ?url)
	(?url enc:length ?length)
	(?url enc:type ?type)

I seem to be able to find the right information without use of a 
schema. It does make it a simpler query though. The only extra you get 
from the enc:url is when it is reused for different episodes, which is 
already the case in some instances.

>   As in, a query for "everything using that URL as a
> resource" could help build out a list of quite a lot more than just 
> looking
> for enc:url uses.   At the same time, making use of a seeAlso opens 
> the door
> for developers to use a single interface to detect "other things" being
> available for an item.  This as opposed to multiple interfaces for 
> each and
> every type of other thing.

Good point.

> Support for an enclosure is indeed a compelling feature to add and 
> could
> well stand on it's own.  I'm just thinking about the two-step process 
> of
> "hey, something else and it's an enclosure" allowing for more 
> extensibility
> than just "hey, it's an enclosure".

Agreed, but I still would like to be able find out that it is in fact 
an enclosure without having to do complex post-processing.

Regards,
Suzan Foster.



 
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/