Re: PaceIRI

[Martin Duerst]

At 16:04 05/01/11, Martin Duerst wrote:
>
>I have completed (as far as I'm concerned) PaceIRI.
Just to help everybody to look at it faster, here is the URI/IRI:
http://www.intertwingly.net/wiki/pie/PaceIRI
Sorry I forgot.
>The proposal is simple, namely to allow IRIs wherever the spec
>currently allows URIs. I have given details of what needs to be
>changed in the spec for that to happen. If anything is unclear,
>I'm glad to help out the editors.
>
>As far as I remember, the main objection on previous discussions
>of IRIs was that the IRI spec was not yet approved. But it is
>approved now. If there are other objections, please say so.
>
>
>Regards, Martin. 

content for text/ or +xml SHOULD be local? (was: Re: Hash for Links)

[Martin Duerst]

At 05:59 05/01/09, Robert Sayre wrote:
>http://atompub.org/2004/10/20/draft-ietf-atompub-format-03.html#rfc.section.5.10.2
>
>"If the value of type begins with "text/" or ends  with "+xml", the 
content SHOULD be local; that is to say, no "src" attribute should be provided."
>
>If you want to suggest language that describes the bad things that could 
happen when people ignore that recommendation, I would be happy to include it.

When I read this, I was somewhat surprised to find a SHOULD.
A should, in IETF terms, is really quite strong. I'd prefer
a wording such as:
"In general, content with value of type beginning with "text/" or
ending with "+xml" will be inline; that is to say, no "src" attribute
is provided."
(and I think inline is the better term; local implies on the user's
machine rather than inside the document)
In both cases, adding something like "Such content is usually
short, and in that case, carrying it inline is more efficient."
covers the rationale I know about. There may be other rationales.
Regards, Martin. 

PaceIRI

[Martin Duerst]

I have completed (as far as I'm concerned) PaceIRI.
The proposal is simple, namely to allow IRIs wherever the spec
currently allows URIs. I have given details of what needs to be
changed in the spec for that to happen. If anything is unclear,
I'm glad to help out the editors.
As far as I remember, the main objection on previous discussions
of IRIs was that the IRI spec was not yet approved. But it is
approved now. If there are other objections, please say so.
Regards, Martin. 

atom entry documents, feed alternates, mime-types

[Eric Scheid]

I've realised another use case for atom entry documents.

I'm using del.icio.us to track certain memes. For example:
http://del.icio.us/tag/atom
http://del.icio.us/tag/rss
http://del.icio.us/tag/folksonomy

For each of those pages they offer an RSS feed. The feed's entries contain
the bookmarked page title, the URL, and the brief comment entered by the
bookmarkee, if any. Unfortunately, this means that in my feed reader I'm
seeing just headlines and links, no summary, no content.

What would be really neat is if del.icio.us were able to follow a  in
the html page to discover an Atom , and use the  element.
This would be similar in how citeulike (similar to del.icio.us, but geared
for academics) extracts the citation details from academic papers.

To attempt to do so with currently deployed best practice is problematic: a
blog page may well have a , but
that is most likely to point the ongoing feed, not the item alternate in
xml. While there is a chance that that particular page is in the current
feed, it's quite possible that it has already dropped off the bottom. Even
if del.icio.us wanted to serially download the history of that feed looking
for that entry, it would be an immense bandwidth waste, and we haven't
settled on any concrete conventions for the format to communicate where
archives can be found.

Life would be so much easier if there was also a  on the html page
which lead directly to a standalone Atom Entry document.

Well, easier except for a couple of bumps in the road. What @rel would we
use on the entry page ... "alternate" is already taken to mean "the feed in
which this entry was once found". Perhaps we need a different @type value
for Atom Entry documents, to distinguish them from Atom Feed documents?
That, or we try using a different @rel ("feed"?) to identify the feed (while
still allowing the html page whose contents change as new entries come and
go being able to legitimately refer to the Atom Feed document as it's
"alternate"). 

Come to think of it, if there will exist things like "feeds of feeds", which
act as directories of feeds offered by a site, then the html page whose
content reflects the most recent entries should then have a link to the
directory/collection feed, in the same way that individual pages would.

Thus, on an entry html page it would be mighty nice to find this:




and on the most-recent-posts page it would have this




where:

[1] is the atom entry document for that page
[2] is the feed in which this entry/page was once announced
[3] is the atom feed document which is the alternate for this page
[4] is the atom feed document which is the site directory of feeds

Note how [3] is distinguished from [1]. For backwards compatibility we
should also allow the following on an entry html page:



In summary, the del.icio.us situation suggests great usefulness in having
individual atom entry documents being more widespread, which might just help
popularising the atom feed format at the same time. The other feed formats
don't really have this feature of being able to point to a resource which is
the item and just the item, in machine readable xml. It's probably doable in
RDF though, so RSS 1.0 kinda has I, but we all know there are perceptions of
popularity problems with it.

If we want to use atom entry documents as page metadata resources, then we
need to make a couple of changes as outlined above.

e.

Re: PaceFeedRecursive

[Eric Scheid]

On 11/1/05 6:59 AM, "Danny Ayers" <[EMAIL PROTECTED]> wrote:

> Ok, I don't think there is any benefit in the normal case (feed ::=
> meta, (meta, content)*), but the recursive nesting method makes it
> possible to convey information about relationships between feeds.
> Which begs the questions:
> 
> How useful are the semantics of one feed containing another?
> How desirable is it to convey such information in Atom format?

Would not the element set which describes a resource be an entry, regardless
of whether that resource is an html page, image/jpg, rss 0.91 feed, atom
feed, etc?

With our  element, we are able to clearly communicate that a resource
we link to is of type application/atom+xml.

Surely, if someone wanted to build the equivalent of an OPML file in Atom
format, they could do so simply by creating an entry for each feed ... where
any of those feeds could also be of the same OPML equivalent class, thus
giving you deep nesting if you really want it. Alternatively, shallow
nesting is possible by the presence of multiple  elements within an
entry, possibly with @rel="DC.refined" or whatever the DC term is.

I note that the Nature Publishing Group already have something similar:

http://npg.nature.com/pdf/newsfeeds.rdf

e.

Re: Atom Link element: Success

[Henry Story]

Ok, I don't know what happened to me there. I must have been overly 
tired. I went to do some weigh lifting, came back and found that my 
reasoning is in fact correct.

In fact if you put in the following rdf

http://purl.org/atom/#";
   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#";>
   
 atom:hreflang="de" 
atom:href="http://example.org/de/2003/12/13/Atom03"/>


in the validator you get the following graph:

<>
which is what I started off with.
Henry Story
On 10 Jan 2005, at 19:11, Henry Story wrote:
Ok, I give up on this task.
I have just found that when there is a rdf:Resource you can't also 
have attributes. And that attributes have to be qualified.

It is a real pity.
It would be good to make a list of what we would have needed from 
RDF/XML to make Atom be rdf, and then work backwards to create 
RDF/XML2 where this works out fine.

Henry
On 10 Jan 2005, at 01:29, Robert Sayre wrote:
Henry Story wrote:
[snip]
4) Property attributes
--
both hreflang, href and all the other properties of Link are unique, 
 and given that they are string literals (subsets of them at least, 
but  nevertheless) they can be move into attributes on Link


   
 hreflang="de" 
href="http://example.org/de/2003/12/13/Atom03"/>


Use of unqualified attributes is deprecated in RDF/XML (check the 
validator). My opinion is that the transformation you're looking for 
would be easier with XSLT.
You are right. The validator at  is 
really useful.

[snip]
It gets a POST with a fairly average atom entry, but there are  
extensions in funny places. Like most people, the server stores  
standard fields in a relational database, so there are columns for  
title, summary, etc. in a table called something like  
"journal_entries". It would be fairly easy to store immediate 
children  of entry in an "unknown_xml" field, and pass them 
through, but what  about the other extensions? Using an RDF store 
might make this problem  a lot easier, but I don't forsee a mass 
migration in that direction  happening this year or next.

You don't need a specialized RDF storage, though very good ones 
exist.  There are schemes to map RDF into any relational database, 
just as  there are schemes to map objects into relational databases. 
In fact  most RDF storage tools in Java provide this.

That's not my point. My point is that there's a staggering amount of 
data currently living in RDBMSes, and people aren't going to 
re-architect their storage to use Atom.
I was not trying to get people to use RDF databases at the back end. I 
was just hoping that a well engineered XML document would with a 
little care also turn out to be a well engineered RDF document. That 
would provide maximum flexibility in that it would allow people to 
move into the rdf world seamlessly.


Robert Sayre

Re: PaceFeedRecursive

[Roy T. Fielding]

On Jan 10, 2005, at 6:54 AM, Graham wrote:
Seriously, though, all you've done is not bothered to flatten the
data at any point.
Why is that a goal?  We know all of the data is in the leaves, so
"flattening" them is what happens when the entries are processed
depth-first.
While this may please you, all it means is the software at the far end 
has to wade through a few more sets of angle brackets and implement a 
couple of stacks.
Actually, a few less angle brackets (count them), and any client
that tries to process XML without some awareness of hierarchy is
not my concern.  Design for the clients that matter.
Don't think for a second that your format contains more data that
the current flat format,
I would hope not -- the point was to make that data available such
that it would not have to be replicated in every entry.
because since it's all implicit, it's worthless.
Implicit?  Did you mean inherited?  Hierarchical containment is
explicit in XML.
If say, entries appear in two separate groups in a feed, it might
mean that they came from separate sources, or it might nor it might
not mean anything. Why not just make it explicit?
You are not talking about my proposal, or at least it was
fundamentally misunderstood.  Wait until it gets filled-out.
Roy

RE: Please Review: Dissemination of Earthquake / Tsunami data via Atom

[Bob Wyman]

We’ve made a good bit of progress on
cleaning up our PubSub Earthquake/Tsunami reporting service and would like to
ask folk on the list to take a look at the feed we’re generating. (Note:
This isn’t “publicly” announced yet, so please restrict
comments to personal email or the list.)

 

You can see a sample Atom feed of all
recent earthquakes (and tsunami reports in “AddOn” fields –
when we receive them) at:

 

http://atom.pubsub.com/90/69/6169a3b8e062b66f7afd592f.xml

 

Use “View Source” to see the
actual Atom file if you are using a browser that supports style-sheets.

 

I’m sure there is much to be said
about this kind of service; however, my interest in sending this message to
this group is to get comments on our use of Atom for this application. Please
note that in the near future we’ll be allowing people to access this data
via “Atom over XMPP PubSub” for real-time push distribution. Thus,
you’ll be able to say things like: “Only send me quakes over 5.0
magnitude that occur in Southern California
and have ‘waveforms’ data in AddOn records.” We’re also
going to be supporting a pure TCP/IP “telnet” socket connection for
folk who want the full stream. Naturally, REST, SOAP, Email, and other
distribution mechanisms will either be enabled by default (as with all other
PubSub services) or could be provided if demand exists. 

 

I am particularly interested in “Atom-related”
comments at this point. For instance, you’ll notice “Delete”
messages in the feed. We’ve talked about “Delete” or “Retract”
capability often in the past and I’ve usually argued against it. However,
it turns out to be necessary with this kind of feed since often earthquake
reports are retracted as erroneous – often as the result of telemetry
glitches. How should we best handle the need for “Delete” in this
context? What will be easiest for clients to handle?

 

Also, please be aware that I am aware of
no existing standards for this data. If you know of any such standards, please
let me know. (Note: I am aware of CAP and have participated in that forum. It
solves a different problem.)

 

Thanks in advance for your assistance. My
hope is that we’ll be able to use Atom to make a real contribution to
making the world just a bit safer…

 

    bob
wyman

 

Re: PaceFeedRecursive

[Robert Sayre]

Danny Ayers wrote:
On Mon, 10 Jan 2005 11:49:35 -0500, Bob Wyman <[EMAIL PROTECTED]> wrote:
 

   6. Concern that "Feed of Feeds" really doesn't buy you much that
Head In Entry doesn't already provide in the normal case. 
   

Ok, I don't think there is any benefit in the normal case (feed ::=
meta, (meta, content)*), 

It won't screw up DSig as badly. "Collectable Signatures"[0] will still 
require XPath, though.

Robert Sayre
[0] 
http://cvs.apache.org/viewcvs.cgi/xml-security/src_samples/org/apache/xml/security/samples/signature/CreateCollectableSignature.java?rev=1.9&view=markup

Re: PaceFeedRecursive

[Danny Ayers]

On Mon, 10 Jan 2005 11:49:35 -0500, Bob Wyman <[EMAIL PROTECTED]> wrote:
> 
> Roy T. Fielding wrote:
> > a proposal on making the feed element recursive

> The primary arguments against "Feed of Feeds" have been (my
> apologies if I forgot some...)

Thanks Bob. 

IMHO there are pretty strong counter-arguments to 1-5, but this is trickier:

> 6. Concern that "Feed of Feeds" really doesn't buy you much that
> Head In Entry doesn't already provide in the normal case. 

Ok, I don't think there is any benefit in the normal case (feed ::=
meta, (meta, content)*), but the recursive nesting method makes it
possible to convey information about relationships between feeds. 
Which begs the questions:

How useful are the semantics of one feed containing another?
How desirable is it to convey such information in Atom format?

Cheers,
Danny.

-- 

http://dannyayers.com

Re: PaceFeedRecursive

[Isofarro]

Bob Wyman wrote:
Roy T. Fielding wrote:
a proposal on making the feed element recursive
(Speaking for myself, I'm not clued-up enough to understand the 
problem / use-case Roy's pace solves)

Equivalent proposals have often been made in the past (sometimes by
me!). These proposals fall in the category that we've come to know as "Feed
of Feeds".
Agreed. I'm still none the wiser as to alternatives of handling 
Feed of Feed type scenarios. Using an entry element to describe 
a feed inside a feels rather hackish. Using an OPML/OML document 
feels like using two distinct vocabularies where one should do.

My intention is to create an Atom-enabled "space" that is 
navigatable. Resources are Atom Entries, Collections of 
resources are Atom Feeds. From a starting point of an Atom 
Entry, I would like to be able to follow a series of links to 
find other related or neighbourly Atom entries - something like 
going to the parent feed and find a sibling feed.

I find Roy's pace useful for what I want to do - have a way of 
expressing a collection of collections - feeds of feeds. For my 
purposes I can definitely live with one level of recursion or 
nesting:


  ...
  ...
  ...

I can also live with the internal feed not having any entry 
elements - it will just be a pointer and metadata to another 
feed (presumably via a link element).

From my perspective there was a related/relevant discussion 
going on in the Atom Protocol mailing list a few months ago 
about Collections and Resources. Its easy enough to see a 
collection as an Atom feed, and a Resource as an Atom entry, but 
I can't get my head around the correct way of representing a 
Collection of collections without looking at either a feed 
inside a feed, or an OPML/OML representation for each Collection 
of Collections hierachy I'm expecting.

If we are going to use feeds and entries to represent 
collections and resources, we should at least be able to express 
collections of collections with the same vocabulary.


The primary arguments against "Feed of Feeds" have been (my
apologies if I forgot some...)
1. Fear that an arbitrarily deep nesting of feeds might result in
excessively large feeds. (i.e. Feed of Feeds of Feeds of Feeds...)
Limit the nesting to one level. (Feed inside a feed).
2. Belief that a need to handle nested feeds would increase
complexity for client developers. With HeadInEntry, clients are not required
to understand the sourcing issues, but have the necessary data available if
they wish to use it.
With the above limitation the complexity would be identical to 
handling an entry, except the link element definitively refers 
to an Atom Feed rather than an Atom Entry.

3. Desire to simplify the migration path from RSS and Atom 0.3 to
Atom V1.0. The introduction of "Feed of Feeds" would result in a drastic
change in the structure of feeds that might require significant
modifications to the design of existing clients and thus tend to retard
efforts to move to the new format.
The additional work required is to handle a feed element at the 
same point as expecting an entry element. The metadata expected 
in the feed is roughly the same as a summary-only  
without the summary.


4. Questions concerning attribution in interfaces. If an entry is
extracted from a feed nested within another feed, then to which feed should
the entry be associated in an interface?
The limitation above I guess disallows this particular situation.

5. Issues concerning partially nested feeds. For instance, one may
wish to incorporate a single entry from a feed into another feed.
Same as 4.)
6. Concern that "Feed of Feeds" really doesn't buy you much that
Head In Entry doesn't already provide in the normal case.
Just the ability to list feeds that are "filters" of the current 
feed. Taking del.icio.us as an example, the collection at
http://del.icio.us/tag/css would give me recent links with the 
css tag. I'd like to have the ability to refer to the collection
http://del.icio.us/tag/css+tutorial within that feed since it is 
a related feed - a more refined filter than the current feed. 
I'd also like to be able to link the other way - in the 
/tag/css+tutorial collection be able to refer to the "parent" 
collection /tag/css and /tag/tutorial.

For me this would be a nice to have. I don't demand it. 
(Although recommendations of alternative approaches would be 
very welcome)

Just my ha'penny.
Mike
(P.S. Does Roy Fielding's email domain name - gbiv.com have 
anything to do with the colours of the Rainbow, as in roygbiv 
[Red Orange Yellow Green Blue Indigo Violet])?

RE: Atom Link element: Failure

[Jeremy Gray]

Henry, would you mind sending me a copy of the example you were trying to
work up? I took a scroll through your recent emails to see if I could figure
out which one gave you so much trouble, but I'm not sure if I'm looking at
the right materials or not.

I'm curious because you mention that when there is an "rdf:Resource[sic] you
can't also have 
attributes" which, given that rdf:resource applies only to property
elements, makes sense. As such, I'm wondering what exactly you were trying
to accomplish when you hit your roadblock.

Thanks in advance,

Jeremy 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Henry Story
Sent: Monday, January 10, 2005 10:12 AM
To: Robert Sayre; Tim Bray
Cc: [EMAIL PROTECTED]; 'Atom WG'
Subject: Re: Atom Link element: Failure



Ok, I give up on this task.

I have just found that when there is a rdf:Resource you can't also have 
attributes. And that attributes have to be qualified.

It is a real pity.

It would be good to make a list of what we would have needed from 
RDF/XML to make Atom be rdf, and then work backwards to create RDF/XML2 
where this works out fine.

Henry

On 10 Jan 2005, at 01:29, Robert Sayre wrote:
> Henry Story wrote:
>
>> [snip]
>> 4) Property attributes
>> --
>>
>> both hreflang, href and all the other properties of Link are unique,
>> and given that they are string literals (subsets of them at least, 
>> but  nevertheless) they can be move into attributes on Link
>>
>> 
>>>  hreflang="de"
>> href="http://example.org/de/2003/12/13/Atom03"/>
>> 
>
>
> Use of unqualified attributes is deprecated in RDF/XML (check the
> validator). My opinion is that the transformation you're looking for 
> would be easier with XSLT.

You are right. The validator at  is 
really useful.

[snip]

>>>
>>> It gets a POST with a fairly average atom entry, but there are
>>> extensions in funny places. Like most people, the server stores  
>>> standard fields in a relational database, so there are columns for  
>>> title, summary, etc. in a table called something like  
>>> "journal_entries". It would be fairly easy to store immediate 
>>> children  of entry in an "unknown_xml" field, and pass them through, 
>>> but what  about the other extensions? Using an RDF store might make 
>>> this problem  a lot easier, but I don't forsee a mass migration in 
>>> that direction  happening this year or next.
>>
>>
>> You don't need a specialized RDF storage, though very good ones
>> exist.  There are schemes to map RDF into any relational database, 
>> just as  there are schemes to map objects into relational databases. 
>> In fact  most RDF storage tools in Java provide this.
>
>
> That's not my point. My point is that there's a staggering amount of
> data currently living in RDBMSes, and people aren't going to 
> re-architect their storage to use Atom.

I was not trying to get people to use RDF databases at the back end. I 
was just hoping that a well engineered XML document would with a little 
care also turn out to be a well engineered RDF document. That would 
provide maximum flexibility in that it would allow people to move into 
the rdf world seamlessly.


> Robert Sayre
>

Re: PaceFeedRecursive

[Antone Roundy]

On Sunday, January 9, 2005, at 05:36  PM, Roy T. Fielding wrote:
I just created a starting point for a proposal on making the
feed element recursive, eliminating the need for RDF syntax,
atom:head, and a bunch of things proposed in other paces regarding
aggregators and digital signatures.
  http://www.intertwingly.net/wiki/pie/PaceFeedRecursive
Perhaps instead of making feed recursive, it would be better to have 
one more kind of document element to be used for aggregate feeds.  For 
example:



...
...


...
...


...
...


This would get rid of the problem of feeds of feeds of feeds..., but 
would raise a few questions:

* Does  need a  and/or the kinds of things it 
contains>?  I'd say yes, and it's role would be just like the feed/head 
in an aggregate feed based on PaceHeadInEntry.

* If one aggregates s, does one need to carry forward data 
from aggregation/head, and if so, how does one do that?  I'd be willing 
to punt on this and say that it just can't be done.  Allowing it would 
be similar to reintroducing feeds of feeds of feeds...

On the question of eliminating atom:head, if we go this route, we could 
eliminate entry:head, but feed:head was created for reasons other than 
enabling it to be embedded in entries.

The rationale for the pace states:
Simplifies description of the Atom syndication format to containers 
(feed, entry, content) and metadata that targets its own parent (feed 
or entry).

I've been mulling over the question of what the hierarchical placement 
of an element means, and came up with the following possibilities for 
what a child element might be:

1) metadata about its parent (eg. modification date of an entry).
2) metadata about its parent's content??? For example, does  
name the author of an entry, or of it's content?  If we decide that 
metadata about the content itself must be an attribute in the content 
element itself, then we can eliminate this one.
3) the parent's content (eg. entries in a feed, content in an entry).
4) a container for other child elements just for convenience (eg. head 
in a feed)--which would mean that the container's children could be 
metadata about their grandparents, perhaps metadata about the 
grandparent's content, or the grandparent's content itself.  
Eliminating feed/head would eliminate this one.  But remember that 
feed/head predates PaceHeadInEntry--it was created for a different 
purpose, so we may not want to be too quick to toss it out.

That's a slightly different view than what you describe, but not a 
whole lot--assuming 2 and 4 are gone, elements are either metadata 
about their parent, or their parent's content.  Without understanding 
the format, one can't tell which a particular element is unless we did 
something like the following (which I am NOT advocating--I'm happy with 
applications having to know a little about the format if they care to 
distinguish):


...

...

...
...


If we explicitly state that extension elements may only interact with 
other elements in their own namespace and with their immediate parents 
(ie. they may be metadata about or the content of their immediate 
parents, or may interact as defined in the extension with other 
elements from the extension), we eliminate problems with extension 
elements trying to influence the interpretation or handling of their 
siblings, and eliminate questions of inheritance from feed to entry 
(except with elements defined in the Atom core, a la ).

Re: Atom Link element: Failure

[Henry Story]

Ok, I give up on this task.
I have just found that when there is a rdf:Resource you can't also have 
attributes. And that attributes have to be qualified.

It is a real pity.
It would be good to make a list of what we would have needed from 
RDF/XML to make Atom be rdf, and then work backwards to create RDF/XML2 
where this works out fine.

Henry
On 10 Jan 2005, at 01:29, Robert Sayre wrote:
Henry Story wrote:
[snip]
4) Property attributes
--
both hreflang, href and all the other properties of Link are unique,  
and given that they are string literals (subsets of them at least, 
but  nevertheless) they can be move into attributes on Link


   
 hreflang="de" 
href="http://example.org/de/2003/12/13/Atom03"/>


Use of unqualified attributes is deprecated in RDF/XML (check the 
validator). My opinion is that the transformation you're looking for 
would be easier with XSLT.
You are right. The validator at  is 
really useful.

[snip]
It gets a POST with a fairly average atom entry, but there are  
extensions in funny places. Like most people, the server stores  
standard fields in a relational database, so there are columns for  
title, summary, etc. in a table called something like  
"journal_entries". It would be fairly easy to store immediate 
children  of entry in an "unknown_xml" field, and pass them through, 
but what  about the other extensions? Using an RDF store might make 
this problem  a lot easier, but I don't forsee a mass migration in 
that direction  happening this year or next.

You don't need a specialized RDF storage, though very good ones 
exist.  There are schemes to map RDF into any relational database, 
just as  there are schemes to map objects into relational databases. 
In fact  most RDF storage tools in Java provide this.

That's not my point. My point is that there's a staggering amount of 
data currently living in RDBMSes, and people aren't going to 
re-architect their storage to use Atom.
I was not trying to get people to use RDF databases at the back end. I 
was just hoping that a well engineered XML document would with a little 
care also turn out to be a well engineered RDF document. That would 
provide maximum flexibility in that it would allow people to move into 
the rdf world seamlessly.


Robert Sayre

Re: Hash for Links [Was: Re: Posted PaceEnclosuresAndPix]

[Walter Underwood]

This is really cache management. Use e-tags, from the HTTP 1.1 spec.
Or use an HTTP cache, which would require no changes to Atom.
Going thorugh a client-side HTTP 1.1 cache would automatically take
advantage of the e-tags and other caching information in HTTP.
wunder
--On Saturday, January 08, 2005 06:14:50 PM -0800 James Snell <[EMAIL 
PROTECTED]> wrote:
I really don't want to be going down the road of requiring HTTP header
equivalents in the Atom feed, etc.  All I want is the ability to
specify a hash of whatever it is that is being linked to.  It could
work in both link and content elements and one could easily use the
Content-MD5 header to verify whether or not the resource referenced
has been modified since the time it was included in the Entry.
The URI and the length of the file do not guarantee that the content
has not changed and yes, I had considered this as a possible non-core
extension but wanted to float it as a core item first.
On Sat, 08 Jan 2005 15:02:27 -0500, Robert Sayre <[EMAIL PROTECTED]> wrote:
Bill de hÓra wrote:
>
>
>>  http://example.com/somefile.mp3";
>>  hash="{generated_hash_value}"
>> hashalg="{uri_identifying_the_hash_algorithm_used" />
>>
>> The hash and hashalg attributes would be optional but MUST appear
>> together.
>>
>> Thoughts? (If we have more than two people respond favorably to this,
>> I'll write up a Pace for it)
>
>
>
> Seems like a good idea - would it be possible to move them into elements?
Well, Content-Length lives in the attributes as "length", but I don't
think we need to make a home for every HTTP header. Content-MD5 will
work just fine; it would probably be wise to send a HEAD request before
automatically downloading a giant mp3. Furthermore, you'll get a good
enough identifier by concatenating the URI and the length. Something
more accurate will require a HEAD request. Thirdly, there's absolutely
no reason to have this in core.
Robert Sayre


--
- James Snell
  http://www.snellspace.com
  [EMAIL PROTECTED]

--
Walter Underwood
Principal Architect
Verity Ultraseek

RE: PaceFeedRecursive

[Bob Wyman]

Roy T. Fielding wrote:
> a proposal on making the feed element recursive
Equivalent proposals have often been made in the past (sometimes by
me!). These proposals fall in the category that we've come to know as "Feed
of Feeds". Each time the proposal has been made, it has been rejected. This
explains why "head in entry" is necessary -- since we can't have a "Feed of
Feeds", we need an alternative mechanism for associating Feed metadata with
entries that have been copied from other feeds.

The primary arguments against "Feed of Feeds" have been (my
apologies if I forgot some...)
1. Fear that an arbitrarily deep nesting of feeds might result in
excessively large feeds. (i.e. Feed of Feeds of Feeds of Feeds...)
2. Belief that a need to handle nested feeds would increase
complexity for client developers. With HeadInEntry, clients are not required
to understand the sourcing issues, but have the necessary data available if
they wish to use it.
3. Desire to simplify the migration path from RSS and Atom 0.3 to
Atom V1.0. The introduction of "Feed of Feeds" would result in a drastic
change in the structure of feeds that might require significant
modifications to the design of existing clients and thus tend to retard
efforts to move to the new format. While we should be completely open to
such drastic structural changes, we should only accept such changes if the
benefits of doing so are clear, compelling and overweigh the costs of
migration.
4. Questions concerning attribution in interfaces. If an entry is
extracted from a feed nested within another feed, then to which feed should
the entry be associated in an interface? Or, should the interface attempt to
show the full "path" of the nesting hierarchy that contains the entry? With
"Head in Entry" it is likely that people will say that an entry "belongs" to
whatever feed it was found in. However, with "Feed of Feeds" it is more
likely that client developers and users will seek to associate the entry
with its source feed. (Note: This is a psychological or social issue, not a
technical one.) 
5. Issues concerning partially nested feeds. For instance, one may
wish to incorporate a single entry from a feed into another feed. If the
approach is to simply nest the source feed, can a partial feed be nested? If
so, what feed metadata should be maintained in the nested feed? 
6. Concern that "Feed of Feeds" really doesn't buy you much that
Head In Entry doesn't already provide in the normal case. One advantage
provided by Feed of Feeds is that feed metadata would not be repeated in the
case of multiple entries from a single feed being incorporated into another.
However, this may not be the normal case. The requirement for "feed of
feeds" is primarily driven by searching and matching engines and other entry
aggregators that tend not to experience enough locality of reference in
their results to have large numbers of results from a single feed. In this
case, the occasional repetition of feed meta data in  elements is
probably acceptable.

I may have forgotten some of the arguments, but this should provide
a good refresher and/or catch-up on the basic issues...

bob wyman

Re: Signatures in feeds of Aggregated Entry Documents

[Antone Roundy]

On Sunday, January 9, 2005, at 03:18  AM, Eric Scheid wrote:
sidebar: does the signature technology we use for the atom format 
allow us
to state that certain child elements are not to be included in the 
signature
algorithm. I'm thinking of something along the lines of the 
following...


...



... 






This has come up before[1], but I don't think a Pace was ever 
written--a "not-signed" attribute seemed to be preferred early in the 
discussion.  One drawback vs. a "not-signed" attribute is that 
applications would have to be able to recognize that 's 
children belong at the level where the annotation element itself lives. 
 The obvious advantage of  would be that the annotation 
itself could be signed, a la:


...



... 







 could also be useful as a means of tracking where 
annotations to an entry came from.  Only the original publisher might 
be allowed to add data outside of an annotation element.  Applications 
merging entries might do so and put everything outside of annotation 
elements, but they could be required to generate a new ID for the 
entry, thus not asserting that it was an instance of one of the source 
entries.

[1] http://www.imc.org/atom-syntax/mail-archive/msg09534.html

Re: Signatures in feeds of Aggregated Entry Documents

[Antone Roundy]

On Saturday, January 8, 2005, at 09:41  PM, Bob Wyman wrote:
As Robert Sayre recently wrote:
>DSig and XMLEnc are in core.
>http://atompub.org/2004/10/20/draft-ietf-atompub-format- 
03.html#rfc.section.7

However, the text says:
“The document element of an Atom document (i.e., atom:feed in an Atom  
Feed Document, atom:entry in an Atom Entry Document) MAY have an  
Enveloped Signature” … “Other elements in an Atom document MUST NOT be  
signed unless their definitions explicitly specify such a capability.”
...
I can’t remember if this has been discussed before. I’m tempted to  
write a Pace which would specify that any atom:entry can be signed –  
whether it is found in an Atom Feed Document or an Atom Entry  
Document. Before doing so, I would appreciate if someone could explain  
if the constraint in the current specification is intentional. Why  
would a signature not be permitted on an atom:entry found in an Atom  
Feed Document?

Might this constraint have grown out of  
http://www.imc.org/atom-syntax/mail-archive/msg09550.html - which I  
don't read as meaning what's in the current draft?  Perhaps the  
original intent was to impose the following constraints, and the  
restriction on other elements being signed slipped in inadvertantly:

* Document elements may only be signed using DSig.
* Document elements may only use enveloped signatures (as opposed to  
enveloping, sibling...).
and perhaps:
* If other elements are signed, they must use enveloped signatures,  
unless their definitions explicitly specify a capability to use  
enveloping, etc., signatures.

Thinking about it, I haven't been able to come up with a reason to  
forbid the signing of other elements, and I don't recall discussion of  
such a restriction either.

Re: PaceFeedRecursive

[Graham]

On 10 Jan 2005, at 4:10 am, Roy T. Fielding wrote:
On Jan 9, 2005, at 5:38 PM, Graham wrote:
-1; Conceptual masturbation.
Wow, you like it that much?  It must be a really good idea, then,
since we are all just doing this to keep you stimulated.
Sarcasm and everything. Wow. Seriously, though, all you've done is not 
bothered to flatten the data at any point. While this may please you, 
all it means is the software at the far end has to wade through a few 
more sets of angle brackets and implement a couple of stacks. Don't 
think for a second that your format contains more data that the current 
flat format, because since it's all implicit, it's worthless. If say, 
entries appear in two separate groups in a feed, it might mean that 
they came from separate sources, or it might nor it might not mean 
anything. Why not just make it explicit?

Graham

smime.p7s
Description: S/MIME cryptographic signature

Re: Atom Link element

[Danny Ayers]

On Sun, 09 Jan 2005 19:29:45 -0500, Robert Sayre <[EMAIL PROTECTED]> wrote:

To jump in late on -

> That's not my point. My point is that there's a staggering amount of
> data currently living in RDBMSes, and people aren't going to
> re-architect their storage to use Atom.

True, but they don't have to. Taking the RDF case (as something the
far side of Atom+extensions), it's reasonably straightforward to
project RDBMS data as triples, such  as RDF/XML and the representation
of n-ary relations is quite well documented (e.g. [1]). SQL views are
*very* handy.

(Incidentally a simple way of re-architecting would be to replace
existing tables with views that have exactly the same layout,
projected from a triple store/table).

But that's just working on material that's already in the existing
domain of the RDBMS. Where it gets more interesting is with
(potentially unknown) extensions. I reckon it's entirely feasible to
use a triplestore for these bits, leaving the core work to
conventional (existing) tables.

Somewhere around the middle of my to-do list is to take one of the
open source CMSs and add FOAF support. It's easy to imagine a
separate, bolted on RDF store, perhaps using a three-column table in
the existing database. But the tricky (i.e. interesting) part is how
to integrate existing user handling - usernames, access rights etc -
with the new store.

I think the simplest approach would be to cleanly isolate the existing
'username' tables (if necessary) then swap those tables out for SQL
views of a triple table. I've tried stuff similar to this, and it's
pretty straightforward.

What would be better still would be to leave the existing tables
entirely in place, and use joins between those tables and the triple
store. I'm not entirely sure how much work would be involved with this
approach, having yet to experiment.

I reckon in general that the fact that both the RDBMS and RDF are
based on relational models, there's a wide band of overlap that can
simplify interoperability. This isn't really the case with
XML-oriented stores, RDF/XML being a bit of a red herring. It would be
nice for Atom to get the best of both worlds.

Cheers,
Danny.

[1] http://www.w3.org/TR/2004/WD-swbp-n-aryRelations-20040721/
-- 

http://dannyayers.com

Re: PaceFeedRecursive

[Danny Ayers]

On Sun, 9 Jan 2005 16:36:04 -0800, Roy T. Fielding <[EMAIL PROTECTED]> wrote:

>http://www.intertwingly.net/wiki/pie/PaceFeedRecursive

I like it, but seem to remember a similar proposal being rejected - anyone..?

This approach should be pretty straightforward to program against, and
what's more should offer easy processing/data access through
XSLT/XQuery and simple mapping to RDF (essentially using striped
RDF/XML).

The only issue that springs to mind is that a feed could end up with a
huge amount of redundant chars if the same feeds/entries appeared
multiple times in different branches of the hierarchy. A simple
mechanism for substituting a feed/entry with its URI might do, or
alternately an in-document #id kind of cross reference to the first
occurence of the feed entry.

Cheers,
Danny.



-- 

http://dannyayers.com

Re: Regarding Graphs

[Danny Ayers]

On Sun, 9 Jan 2005 15:20:56 -0800, Roy T. Fielding <[EMAIL PROTECTED]> wrote:

> > For example:
> >
> > 
> >
> >http://example.org/feed"/>
> > ...
> >
> >
> >   http://example.org/entry
> >   http://example.org/feed"; />
> > ...
> >
> > 
> >
> > If resources are view as nodes, then http://example.org/feed has two
> > parents. The containment tree is violated.
> 
> Nonsense.  The containment tree tells us what the tail of the link
> is, not the target of those links.  The information is going to
> have far more relationships just by virtue of the content text,
> and thus the information will be a graph even if the relations
> are not made explicit via links. 

Well yes, that was really what I was trying to say, that there are
more relationships than those expressed by the tree.

Their containment is only a
> very small subset of those relationships and cannot be violated
> by the mere presence of other types of links.

If you restrict the set of entities and relationships under discussion
to those directly involved in containment relationships, then sure,
containment will not be violated.

> The reason this topic came up was because people wanted to
> know how the format is extensible given the implicit relationship
> between feed, entry, and entry elements.  Containment is the only
> answer needed because all other relationships are explicitly
> targeted by a URI.

Other relationships can be targetted by a URI, and this with
containment can be enough to describe all the relationships needed.
But my original point was that it wasn't being made explicit.

> Personally, what I would change in the format is elimination
> of head and make feed a recursive element.  Then there would be
> no doubt as to the hierarchical relations and feed vacuums can
> compose multiple feeds to their heart's delight without changing
> the entries at all.

I think this approach was suggested fairly early on, I'm not sure why
it didn't make it through, possibly the argument that flatter is
simpler (for non-Functional developers). The (recursive) nesting
approach can certainly work well, I've seen striped RDF/XML that looks
like this, even the overstretched OPML (sometimes) works because of
it.

I'm not sure how you'd deal with multiple occurrences of the same
entry/feed in different layers. I suppose they could be referred to
through their URIs.

Cheers,
Danny. 

-- 

http://dannyayers.com