Hi.



Looking at the RSS 0.9 spec [1], I noticed that it doesn't use rdf:about or

rdf:ID on any of it's descriptions. Therefore, each RSS 0.9 file is NOT

asserting any statements about the resources referred to in the rss:link or

rss:url elements as prescribed by RSS 1.0.



I believe that we shouldn't be making statements directly about the linked

resources but rather we should be making statements about the abstract

RSS-specific resources that are related to the "real" resources via the

rss:link and rss:url properties. Aaron explained this nicely in [2]. This

about the model. How useful is it to have a resource (rss:item) with a

property like rss:link that refers to itself?



By switching to rdf:ID, we can retain semantic compatibility with RSS 0.9.

(If that's important--if syntactic compatibility is, I think this is

moreso.) We'll also avoid the issues raised by Markus and Ken in [3] and

[4].



With RSS 1.0, aggregation supposedly requires that each rss:channel,

rss:item, etc, element be uniquely identifable. Using rdf:ID (which would

probably contain values like "item1", "item2", etc), aggregators would be

required to prepend the URI of the RSS file to each ID contained therein in

order to retain it's "identity". I don't imagine this being too burdensome.

Ken's worried about duplicate rdf:about attributes in the same file in [4].

I think we're guaranteed to have duplicate rdf:about attributes across

multiple RSS files from different sources. How will we uniquely identify

those after they're aggregated unless we do some preprocessing anyways?



Thanks for your time,

Jason.



[1]

http://my.netscape.com/publish/help/quickstart.html

[2]

http://www.egroups.com/message/rss-dev/878

[3]

http://www.egroups.com/message/rss-dev/942

[4]

http://www.egroups.com/message/rss-dev/945

This issue is more difficult than it seems. We're making RDF assertions,

that much is clear. The question then becomes about what. If we make them

about items with strange IDs or URIs, the problem then becomes that while,

we're using RDF, we're not making generically useful assertions -- an RDF

application has to know that if:

     an assertion is made about an item

     that item has a link to a URL

     then that assertion is valid for that URL



The question is: How much of an issue is this? Is it a reasonable assumption

that an RDF application using RSS would be smart enough to realize this?



The other question is: What does 0.9 do? As far as I have seen, 0.9

assertions (and I use that term loosely) are really only valid for the scope

of the RSS file, or related usage. That is, I've never seen an RSS app

(although I plan to create one for RSS 1.0) that provides the RSS metadata

for a specific URL, so that you could enter in the address of a news article

and get back a title or description. Most only provide the RSS information

in the context of a specific channel. Thus, I think the ID-type usage would

be valid in this situation.



--

Aaron Swartz | me@... | http://www.aaronsw.com

On Tue, 17 Oct 2000, Aaron Swartz wrote:



> This issue is more difficult than it seems. We're making RDF assertions,

> that much is clear. The question then becomes about what. If we make them

> about items with strange IDs or URIs, the problem then becomes that while,

> we're using RDF, we're not making generically useful assertions -- an RDF

> application has to know that if:

>     an assertion is made about an item

>     that item has a link to a URL

>     then that assertion is valid for that URL



When we are making assertions about 'items' it is fine to use the URL of

the item in the rdf:about, because we are describing a particular Web

resource at a particular URL.  In this case, the rss:link property will

replicate the URL used in the rdf:about - this perfectly acceptable,

though not ideal because of the replication of the URL.



When we are making assertions about a channel things are less obvious.

In Rael's first example RSS 1.0 file at



   http://meerkat.oreillynet.com/?_fl=rss10



we see



<channel rdf:about="http://meerkat.oreillynet.com/">



This looks reasonable - the URL resolves to the syndication service that

is being described.  This URL is a valid value for both the rdf:about and

for the rss:link property.



In the second example at



   http://www.oreillynet.com/cs/rss/print/q/32?x-ver=1.0



we see



<channel rdf:about="http://www.oreillynet.com">



I'm less convinced that this is correct.  This RSS file is not a

description about the resource at that URL.  For example, the title of the

resource at that URL is not 'Articles from The O'Reilly Network' as

indicated in the RDF.  In this case, the URL is a valid value for the

rss:link property but not for the rdf:about.



So, what is a 'channel' anyway?  What is the thing being described?



Someone suggested that the channel *is* the RSS file - and that the URL of

the RSS file should be used for the rdf:about.  For example, we might see



<channel rdf:about="http://meerkat.oreillynet.com/?_fl=rss10">



(BTW, the RDF-MS Spec inidcates that this can be written as simply



<channel rdf:about="">



I think).



However, this feels pretty uncomfortable to me... what we are saying is

that 'this is a description of the RSS resource that is a description of

the RSS resource that is a description of the RSS resource' ad infinitum.



I'm confused as to whether the 'channel' is the RSS file, a particular

HTML (or other) respresentation of the RSS file (as in the first example

above) or some more abstract concept that corresponds to a particular, but

changing, collection of items.



If 'channel' is simply a collection of items, then it seems appropriate to

assign it a unique identifier, a URI that is not necessarily a URL and

that doesn't necessarily resolve to anything, and use it as the value of

rdf:about?



> The question is: How much of an issue is this? Is it a reasonable assumption

> that an RDF application using RSS would be smart enough to realize this?



Not sure what you mean here?  If you mean, will an arbitrary RDF

application that doesn't have built-in understanding of RSS-specific

semantics, understand what <link> means?  Then, no - probably not?  I

suppose that the RSS RDFS schema definition could indicate that the

rss:link property is a subProperty of dc:relation (which I think it is)...

such that if the RDF application understood dc:relation, it would have

some understanding of rss:link ??



Andy

--

Distributed Systems and Services

UKOLN, University of Bath, Bath, BA2 7AY, UK       a.powell@...

www.ukoln.ac.uk/ukoln/staff/a.powell             Voice: +44 1225 323933

Resource Discovery Network - www.rdn.ac.uk         Fax: +44 1225 826838

> So, what is a 'channel' anyway?  What is the thing being described?

>

> Someone suggested that the channel *is* the RSS file - and that the URL of

> the RSS file should be used for the rdf:about.



Agreed, for 1.0 I believe we should set rdf:about for the channel to "" and

look towards a URI representation in a later version. This usage of "" is

valid RDF, and is used in an example in the RDF spec.



I hereby propose to set the rdf:about attribute of the channel element to be

required to be "", meaning the RDF document itself.



Does anyone have any complaints with this change?



--

Aaron Swartz | me@... | http://www.aaronsw.com

Hi Aaron,



Aaron Swartz wrote:

>

> > So, what is a 'channel' anyway?  What is the thing being described?

> >

> > Someone suggested that the channel *is* the RSS file - and that the URL of

> > the RSS file should be used for the rdf:about.

>

> Agreed, for 1.0 I believe we should set rdf:about for the channel to "" and

> look towards a URI representation in a later version. This usage of "" is

> valid RDF, and is used in an example in the RDF spec.

>

> I hereby propose to set the rdf:about attribute of the channel element to be

> required to be "", meaning the RDF document itself.

>

> Does anyone have any complaints with this change?



Yes, I have ;)



While I agree that a good practice would be to set this attribute to a

URI where you can usually find the channel, I don't think we should

hardwire it to the location where the channel is when you process it.



Doing so means that if you save a RSS feed locally and work on the saved

version, you will have in your RDF triples a value set to something like

"file:/myfilesystem/saved.rss" which is meaningless.



Eric

>

> --

> Aaron Swartz | me@... | http://www.aaronsw.com

>

> To unsubscribe from this group, send an email to:

> rss-dev-unsubscribe@egroups.com



--

------------------------------------------------------------------------

Eric van der Vlist       Dyomedea                    http://dyomedea.com

http://xmlfr.org         http://4xt.org              http://ducotede.com

------------------------------------------------------------------------

Due to the good points brought up by Eric and Dan (thanks guys!) I'd like to

try proposing the opposite:



The rdf:about attribute of the channel element is a URL where a copy of the

channel can be accessed.



The reason I didn't propose this in the first place, is because it would be

more difficult for RSS authors (I noticed Rael had some trouble generating

the correct URIs for Meerkat, as did Moreover). However, I don't see this as

a terribly difficult constraint.



For reference, the current spec says this:



> The {resource} URL of the channel element's rdf:about attribute *must* be the

> *same* as that found in each of the inchannel elements found in the image,

> item, and textinput elements.



Does this imply that it can be any arbitrary URL?



Anyone have serious problems with this addition?



--

Aaron Swartz | me@... | http://www.aaronsw.com

On Thu, 19 Oct 2000, Aaron Swartz wrote:



> > So, what is a 'channel' anyway?  What is the thing being described?

> >

> > Someone suggested that the channel *is* the RSS file - and that the URL of

> > the RSS file should be used for the rdf:about.

>

> Agreed, for 1.0 I believe we should set rdf:about for the channel to "" and

> look towards a URI representation in a later version. This usage of "" is

> valid RDF, and is used in an example in the RDF spec.

>

> I hereby propose to set the rdf:about attribute of the channel element to be

> required to be "", meaning the RDF document itself.

>

> Does anyone have any complaints with this change?

>



I'd much prefer an absolute URI, so that apps can ship the channel data

around in text format without having to ship a bunch of 'where I found

this' context along with it. Also a good way to avoid having similar but

slightly different URIs be used for same channel.



Dan

Aaron Swartz <aswartz@...> writes:



> Due to the good points brought up by Eric and Dan (thanks guys!) I'd like to

> try proposing the opposite:

>

> The rdf:about attribute of the channel element is a URL where a copy of the

> channel can be accessed.

>

> The reason I didn't propose this in the first place, is because it would be

> more difficult for RSS authors (I noticed Rael had some trouble generating

> the correct URIs for Meerkat, as did Moreover). However, I don't see this as

> a terribly difficult constraint.

>

> For reference, the current spec says this:

>

> > The {resource} URL of the channel element's rdf:about attribute *must* be

the

> > *same* as that found in each of the inchannel elements found in the image,

> > item, and textinput elements.

>

> Does this imply that it can be any arbitrary URL?

>

> Anyone have serious problems with this addition?



Yes (I think, I'm just rereading the recent articles on this while

updating the issues page).



I don't recall us concluding that we're breaking the connection

between <link> and rdf:about (if so, let me know, it's one of our

issues!)



If that's the case, <link> is definitely the URL of the site or

channel that this <channel> describes, therefore the rdf:about would

be too, and any examples to the contrary are just wrong.



(Simply point me to a msg# if this has already been discussed,

please.)



   -- Ken

Ken MacLeod <ken@...> wrote:



> If that's the case, <link> is definitely the URL of the site or

> channel that this <channel> describes, therefore the rdf:about would

> be too, and any examples to the contrary are just wrong.



I was just re-reading the spec on this point, and things are very unclear.

First, the channel element only says "The {resource} URL of the channel

element's rdf:about attribute *must* be the *same* as that found in each of

the inchannel elements found in the image, item, and textinput elements." To

me this implies that it can be any URL.



It is not until you get to the link element that you see "The channel link

element is superceded by (and identical to) the channel element's rdf:about

attribute, but is required for backward compatibility with RSS 0.9."

However, syntax section reads <link>{channel_link}</link> not {resource} as

would be expected. This is inconsistent with all of the other link elements

in the spec.



However, every example in the spec, as well as Edd's proposal, use the

rdf:about to point to the URL of the RSS file, like:



<channel rdf:about="http://www.xml.com/xml/news.rss">

<channel rdf:about="http://meerkat.oreillynet.com/?_fl=rss1.0">



If nothing else, we need to clear up the inconsistency in the spec.



--

Aaron Swartz | me@... | http://www.aaronsw.com

What is sure is that:



1) per RDF semantic, rdf:about is used as an identifier for the channel.

2) per RSS 0.9x usage, the link element is a URL (or URI) pointing on an

existing page which can be visualized for a human being.



Therefor, I don't think these 2 values should be equals since they are

not referring to the same resources or objects (a channel in one case, a

page in the other one) and this would be confusing if we wanted to

describe the page itself in the same rdf database.



IMHO, a good practice would be to use a URL where the RSS feed can

usually be found as rdf:about.



There are exceptions, though and I don't think we should make a firm

rule about this, but only a "best practice" advise.



These exceptions are, for instance, sites building dynamics RSS feeds

depending on sessions variables for which you can't provide a URI which

will return the same feed (but will still have to assign an identifier

to the channel).



Hope this helps.



Eric



Aaron Swartz wrote:

>

> Ken MacLeod <ken@...> wrote:

>

> > If that's the case, <link> is definitely the URL of the site or

> > channel that this <channel> describes, therefore the rdf:about would

> > be too, and any examples to the contrary are just wrong.

>

> I was just re-reading the spec on this point, and things are very unclear.

> First, the channel element only says "The {resource} URL of the channel

> element's rdf:about attribute *must* be the *same* as that found in each of

> the inchannel elements found in the image, item, and textinput elements." To

> me this implies that it can be any URL.

>

> It is not until you get to the link element that you see "The channel link

> element is superceded by (and identical to) the channel element's rdf:about

> attribute, but is required for backward compatibility with RSS 0.9."

> However, syntax section reads <link>{channel_link}</link> not {resource} as

> would be expected. This is inconsistent with all of the other link elements

> in the spec.

>

> However, every example in the spec, as well as Edd's proposal, use the

> rdf:about to point to the URL of the RSS file, like:

>

> <channel rdf:about="http://www.xml.com/xml/news.rss">

> <channel rdf:about="http://meerkat.oreillynet.com/?_fl=rss1.0">

>

> If nothing else, we need to clear up the inconsistency in the spec.

>

> --

> Aaron Swartz | me@... | http://www.aaronsw.com

>

> To unsubscribe from this group, send an email to:

> rss-dev-unsubscribe@egroups.com



--

------------------------------------------------------------------------

Eric van der Vlist       Dyomedea                    http://dyomedea.com

http://xmlfr.org         http://4xt.org              http://ducotede.com

------------------------------------------------------------------------

Eric van der Vlist <vdv@...> writes:



> What is sure is that:

>

> 1) per RDF semantic, rdf:about is used as an identifier for the channel.

> 2) per RSS 0.9x usage, the link element is a URL (or URI) pointing on an

> existing page which can be visualized for a human being.

>

> Therefor, I don't think these 2 values should be equals since they are

> not referring to the same resources or objects (a channel in one case, a

> page in the other one) and this would be confusing if we wanted to

> describe the page itself in the same rdf database.

>

> IMHO, a good practice would be to use a URL where the RSS feed can

> usually be found as rdf:about.

>

> There are exceptions, though and I don't think we should make a firm

> rule about this, but only a "best practice" advise.

>

> These exceptions are, for instance, sites building dynamics RSS feeds

> depending on sessions variables for which you can't provide a URI which

> will return the same feed (but will still have to assign an identifier

> to the channel).



To summarize what I think I've heard said, and put that in to terms I

think most important for RSS 1.0, then:



  * the explicit connection between <link> and rdf:about should be

    undone, so that at some time in the future they can be used

    seperately.



  * the only hard requirement, at this time, for rdf:about is that it

    be unique, globally (for items, channels, and might as well be for

    images and textinputs)



  * <link>, therefore, need not be unique (as some existing uses have

    shown)



  * recommended current practice is to copy <link> (<url>) to rdf:about

    iff it is unique, and otherwise to create a unique URI for

    rdf:about.



  * any more specific definition of rdf:about, at this time, is

    unspecified



I believe I've also read that some think channel rdf:about should

point to the RSS file, and I'd like to give a counter-argument for

that: I would like to see the channel rdf:about to uniquely identify

the *channel*, where there might be several versions of RSS, other

site summary, topic maps, etc. that may also describe that channel.

As such, there may (to be determined later) be statements that could

be made about a channel that provide links to these other resources.



"Uniquely identify the channel" (rdf:about) can mean the site URL if

there's effectively only one channel to the site, a channel URL/URI if

there's multiple channels to the site, or a virtual or query URI if

this is a manufactured channel.



Am I close?



   -- Ken

Ken MacLeod wrote:

>

> To summarize what I think I've heard said, and put that in to terms I

> think most important for RSS 1.0, then:

>

>  * the explicit connection between <link> and rdf:about should be

>    undone, so that at some time in the future they can be used

>    seperately.

>

>  * the only hard requirement, at this time, for rdf:about is that it

>    be unique, globally (for items, channels, and might as well be for

>    images and textinputs)

>

>  * <link>, therefore, need not be unique (as some existing uses have

>    shown)

>

>  * recommended current practice is to copy <link> (<url>) to rdf:about

>    iff it is unique, and otherwise to create a unique URI for

>    rdf:about.

>

>  * any more specific definition of rdf:about, at this time, is

>    unspecified

>

> I believe I've also read that some think channel rdf:about should

> point to the RSS file, and I'd like to give a counter-argument for

> that: I would like to see the channel rdf:about to uniquely identify

> the *channel*, where there might be several versions of RSS, other

> site summary, topic maps, etc. that may also describe that channel.

> As such, there may (to be determined later) be statements that could

> be made about a channel that provide links to these other resources.

>

> "Uniquely identify the channel" (rdf:about) can mean the site URL if

> there's effectively only one channel to the site, a channel URL/URI if

> there's multiple channels to the site, or a virtual or query URI if

> this is a manufactured channel.

>

> Am I close?



I find it a good summary.



Eric



>   -- Ken

>

> To unsubscribe from this group, send an email to:

> rss-dev-unsubscribe@egroups.com



--

------------------------------------------------------------------------

Eric van der Vlist       Dyomedea                    http://dyomedea.com

http://xmlfr.org         http://4xt.org              http://ducotede.com

------------------------------------------------------------------------

Eric van der Vlist <vdv@...> writes:



> Ken MacLeod wrote:

  <http://www.egroups.com/message/rss-dev/1006>



> > Am I close?

>

> I find it a good summary.



If this solves the immediate need, then the next step is to word it as

specific changes to the spec, and propose those changes.  I know this

would be several tasks down on my list, so if anyone can pick it up

(Eric, Aaron, anyone?), let us know when you start.



   -- Ken

Ken MacLeod <ken@...> wrote:



>> Ken MacLeod wrote: <http://www.egroups.com/message/rss-dev/1006>

>>> Am I close?

>> I find it a good summary.

> If this solves the immediate need, then the next step is to word it as

> specific changes to the spec, and propose those changes.  I know this

> would be several tasks down on my list, so if anyone can pick it up

> (Eric, Aaron, anyone?), let us know when you start.



Before writing these up as spec changes, I'd like to see a poll and perhaps

even a vote on the issue. I was under the impression that there might be

some resistance to the change, which is why I planned on saving it to 1.1.

However, it seems to be a somewhat important issue, which is relatively

unclear in the current spec, and so we need to pick at least _some_ sort of

resolution.



Second for a poll?



--

[ Aaron Swartz | me@... | http://www.aaronsw.com ]

Aaron Swartz <aswartz@...> writes:



> Ken MacLeod <ken@...> wrote:

>

> >> Ken MacLeod wrote: <http://www.egroups.com/message/rss-dev/1006>

> >>> Am I close?

> >> I find it a good summary.

> > If this solves the immediate need, then the next step is to word

> > it as specific changes to the spec, and propose those changes.  I

> > know this would be several tasks down on my list, so if anyone can

> > pick it up (Eric, Aaron, anyone?), let us know when you start.

>

> Before writing these up as spec changes, I'd like to see a poll and

> perhaps even a vote on the issue. I was under the impression that

> there might be some resistance to the change, which is why I planned

> on saving it to 1.1.  However, it seems to be a somewhat important

> issue, which is relatively unclear in the current spec, and so we

> need to pick at least _some_ sort of resolution.

>

> Second for a poll?



No problem, the poll's been seconded (and now thirded :-).



I believe we have determined, though the poll will surely help, that

there is considerable desire to have rdf:about be something different

than link, at some future time.



The resistance that I see is trying to determine, for 1.0, what it

should be used *for*, if it's *not* a copy of link.



My summary[1], as ideas for what is strictly necessary for releasing

1.0, is that all rdf:about must be globally unique, that link

therefore need not be unique, and that as a default, rdf:about

*should* be a copy of link.  This leaves everything open for future

discussion, while still telling 1.0 implementors exactly what to

expect and not expect, in a hopefully future-compatible way.



I'm still rereading the threads on this, so please correct me if I've

missed something.



   -- Ken