Subject: geolocation in atom:author?

From: Eric Scheid <[email-masked]>
Date: Mon, 22 Aug 2005 00:17:17 +1000

In this example, can anything intelligent be said about the various
different locations? Is my intent clear, or are there clear ambiguities?

<feed ...>
  ...
  <geo:coords>location#1</geo:coords>
  <author>
    <name>foo</name>
    <geo:coords>location#2</geo:coords>
  </author>
  <entry>
    <author>
      <name>foo</name>
      <geo:coords>location#3</geo:coords>
    </author>
    <geo:coords>location#4</geo:coords>
    <content>...</content>
    ...
  </entry>
</feed>

e.

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 21 Aug 2005 08:45:22 -0700

>     <geo:coords>location#4</geo:coords>

#2 through #4 seem understandable, but what the heck is #1? "The 
place where this feed was put together"? "The place where this feed 
was originally grabbed from"?

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: [email-masked] (Peter Robinson)
Date: Sun, 21 Aug 2005 19:24:51 +0100

> was originally grabbed from"?

I do something similar, intending it to mean "the location of the items
described by this feed" (when there is a single location).  I don't know
whether any software understands my intent...

<http://www.ticketswitch.com/cgi-bin/atom_feed.exe?s_geo=53.82:-3.05:10>

Regards,

Peter
-- 
Peter Robinson <http://www.ticketswitch.com/>

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 21 Aug 2005 12:46:54 -0700

At 7:24 PM +0100 8/21/05, Peter Robinson wrote:
>described by this feed" (when there is a single location).

Ah, I had missed that. This leads to a question for the mailing list. 
Does an informative extension that appears at the feed level (as 
compared to in entries) indicate:

a) this information pertains to each entry

b) this information pertains to the feed itself

c) this information pertains to each entry and to the feed itself

d) completely unknown unless specified in the extension definition

--Paul Hoffman, Director

---

From: David Powell <[email-masked]>
Date: Sun, 21 Aug 2005 21:22:31 +0100

> d) completely unknown unless specified in the extension definition

In my RDF model, feed extensions (together with properties such as
atom:generator), are considered to be properties of the FeedInstance.

EntryInstance's are related to FeedInstance's using containingFeed and
sourceFeed properties.

(Entry's and Feed's can have multiple EntryInstance's and
FeedInstance's, but that's not really relevant...)

So, feed extensions don't automatically inherit to entries in the
model (unlike atom:author which does), but for a given entry you can
locate its feed and take a look at its extension properties, so it
isn't like the information is lost.

So I'd say b); but as long as you aren't throwing away atom:feed data,
that shouldn't prevent an application using feed extensions to do a)
or c).

I think that the interpretation b) is probably what is supported by
section 6 in the absence of any talk about extension inheritance.

-- 
Dave

---

From: "A. Pagaltzis" <[email-masked]>
Date: Sun, 21 Aug 2005 22:42:31 +0200

* Paul Hoffman <[email-masked]> [2005-08-21 21:55]:
> Ah, I had missed that. This leads to a question for the mailing
> list. Does an informative extension that appears at the feed
> level (as compared to in entries) indicate:
> 

Atom itself has precedent for both b) and c). So I would say
it’s d) – but also that aggregators should assume b) when they
don’t know any better.

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>

---

From: "Bob Wyman" <[email-masked]>
Date: Sun, 21 Aug 2005 17:10:06 -0400

Paul Hoffman asked:
> Does an informative extension that appears at the feed level
> (as compared to in entries) indicate:

I believe the correct answer is "e":

  e) Unless otherwise specified, this information pertains to the feed only.

		bob wyman

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 21 Aug 2005 15:04:18 -0700

>   e) Unless otherwise specified, this information pertains to the feed only.

Er, right. Change that list to:

a) this information pertains to each entry (unless otherwise specified)
b) this information pertains to the feed itself (unless otherwise specified)
c) this information pertains to each entry and to the feed itself 
(unless otherwise specified)
d) completely unknown unless specified in the extension definition

--Paul Hoffman, Director

---

From: James M Snell <[email-masked]>
Date: Sun, 21 Aug 2005 15:35:00 -0700

> --Internet Mail Consortium
IMHO, it depends entirely on how the extension is defined.  The various 
extensions I have put together (e.g. comments, expires, etc), the 
metadata can be placed on the feed/source level but is only relevant on 
the entry level (same model as <author />).  One could easily imagine, 
however, that other extensions would apply only on the feed level.  It's 
entirely up to the extension and implementors should make no assumptions.

- James

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 21 Aug 2005 15:54:28 -0700

At 3:35 PM -0700 8/21/05, James M Snell wrote:
>IMHO, it depends entirely on how the extension is defined.  The 
>various extensions I have put together (e.g. comments, expires, 
>etc), the metadata can be placed on the feed/source level but is 
>only relevant on the entry level (same model as <author />).  One 
>could easily imagine, however, that other extensions would apply 
>only on the feed level.  It's entirely up to the extension and 
>implementors should make no assumptions.

The crux of the question is: what happens when an extension that does 
not specify the scope appears at the feed level?

--Paul Hoffman, Director

---

From: Robert Sayre <[email-masked]>
Date: Sun, 21 Aug 2005 19:22:38 -0400

On 8/21/05, Paul Hoffman <[email-masked]> wrote:
> >only relevant on the entry level (same model as <author />). 

4.1.1
"The 'atom:feed' element is the document (i.e., top-level) element of
an Atom Feed Document, acting as a container for metadata and data
associated with the feed."

4.2.1
"The 'atom:author' element is a Person construct that indicates the
author of the entry or feed."

> One

I'm not sure why this question is interesting. What sort of
application would need to know?

Robert Sayre

---

From: "Bob Wyman" <[email-masked]>
Date: Sun, 21 Aug 2005 20:28:32 -0400

Paul Hoffman wrote: 
> The crux of the question is: what happens when an extension that
> does not specify the scope appears at the feed level?
> application would need to know?
I ask:
	What should an aggregate feed generator like PubSub do when it finds
an entry in a feed that contains unscoped extensions as children of the
feed? 
	* Would you expect us to include these extension elements in an
atom:source element if we use the entry in one of our feeds?
	* Should we include in the source elements we generate even things
that we don't understand?
	* What should we do if the entry already has a source element but
that source element doesn't include the extension elements? Should we
publish the source element as we find it? Or, should we modify the source
element to include the extensions? (assuming there are no signatures...)

		bob wyman

---

From: Eric Scheid <[email-masked]>
Date: Mon, 22 Aug 2005 10:34:07 +1000

> application would need to know?

a search engine which provides more than simply keyword searching?

e.

---

From: "A. Pagaltzis" <[email-masked]>
Date: Mon, 22 Aug 2005 02:50:12 +0200

* Paul Hoffman <[email-masked]> [2005-08-22 01:00]:
> The crux of the question is: what happens when an extension
> that does not specify the scope appears at the feed level?

Let me step back to look at the larger issue for a moment.

That issue is inheritance.

atom:author is the only precedent for it in Atom. It works
because each entry ALWAYS has at least one author; the override
mechanism is simple. Additionally, all Atom processors are aware
of it by definition.

But atom:author is not a model to emulate. It works only because
it falls within a narrowly defined set of circumstances.

The WG wisely avoided attempting to specify inheritance for
atom:contributor. An entry MAY have no contributors at all, and
this would require complications to express if feed-level
atom:contributor elements inherited to entries.

My point of view is that the default interpretation should avoid
forcing extensions to specify complicated mechanisms that the WG
avoided introducing when specifying atom:contributor, when an
extension element’s semantics are the same as those of
atom:contributor.

And with that, getting back to your question, the answer seems
pretty clear: it depends on whether the extension element is more
like atom:contributor, ie defines a property which an entry may
or may not have, or more like atom:author, ie defines a property
that every entry inevitably has.

But because that is a matter of interpretation, I would strongly
prefer to say that if the extension does not specify a meaning
for an element at the feed level, then the meaning is undefined. 

On the other, related point, the same principle of avoiding the
necessity of complicated override mechanisms is why I say that
aggregators should assume that unknown extension elements (which
therefore have *unknown* as opposed to *undefined* semantics)
pertain only to the feed, not to its entries.

Regards,

---

From: Eric Scheid <[email-masked]>
Date: Mon, 22 Aug 2005 10:57:56 +1000

> an entry in a feed that contains unscoped extensions as children of the

It's an interesting problem. A pity now that the idea of segregating
entry-defaults at the feed level didn't get sufficient momentum.

But what if there was an widely known extension developed for just this
purpose -- providing entry metadata at the feed level. Possibly in a
wrapper, possibly by flagging with an attribute.

Like this...

<feed ...>
    ...
    <entry:defaults>
        <ext1:foo ../>
        <ext2:bar ../>
        <ext3:qaz ../>
    </entry:defaults>
    <entry>
        ...
    </entry>
</feed>

or like this ...

<feed ...>
    ...
    <ext1:foo .. entry:default="true"/>
    <ext2:bar .. entry:default="true"/>
    <ext3:qaz .. entry:default="true"/>
    <entry>
        ...
    </entry>
</feed>

e.

---

From: "Bob Wyman" <[email-masked]>
Date: Sun, 21 Aug 2005 22:07:55 -0400

> That issue is inheritance.
	Let me give an example of problematic inheritance...
	Some have suggested that there be a "License" that you can associate
with Atom feeds and entries. However, scoping becomes very important in this
case because of some peculiarities of the legal system.
	One can copyright an individual thing and one can copyright a
collection of things. A claim of copyright in a collection is not, however,
necessarily a claim of copyright over the elements of the collection.
Similarly, a claim of copyright over an element of the collection doesn't
reduce any claim of copyright in the collection itself.
	If we assume inheritance from feed elements, then without further
specification, it isn't possible to claim copyright in the collection that
is the feed without claiming copyright in its individual parts. What you'd
have to do is create two distinct types of claim (one for collection and one
for item. That's messy.)
	I'm sure that copyright and licenses aren't the only problematic
contexts here.

		bob wyman

---

From: "Bob Wyman" <[email-masked]>
Date: Sun, 21 Aug 2005 22:14:53 -0400

Eric Scheid wrote:
> But what if there was an widely known extension developed for just
> this purpose -- providing entry metadata at the feed level. Possibly
> in a wrapper, possibly by flagging with an attribute.
	It ain't pretty. But, it would definitely help resolve a great deal
of ambiguity if there was a means by which publishers could provide this
sort of processing hint to intermediaries in the channel. (Consider this
sort of thing to be very much like the cache control hints that folk insert
in the headers of HTTP packets. Sometimes, you have to give the
intermediaries like proxies, publish/subscriber routers or brokers, search
engines, etc. some hints to get them to work properly.)

	bob wyman

---

From: James M Snell <[email-masked]>
Date: Sun, 21 Aug 2005 19:42:28 -0700

>pertain only to the feed, not to its entries.
Ok, I retract my earlier comment about apps not making any assumptions 
about unknown extensions.  This is better. 

Regarding Bob Wyman's separate note about what aggregators like pubsub 
should do, If the aggregator is generating the source element, the 
aggregator should include everything it finds in the feed.. even if it 
does not understand it.  If the entry already contains a source element, 
leave it as is.

- James

---

From: "A. Pagaltzis" <[email-masked]>
Date: Mon, 22 Aug 2005 05:26:16 +0200

* Robin Cover <[email-masked]> [2005-08-22 05:05]:
> On Mon, 22 Aug 2005, A. Pagaltzis wrote:
> > atom:author is the only precedent for it in Atom.
> 
> If "it" in "only precedent for it" refers to inhertance, can
> you explain the sense in which "atom:author is the only
> precedent" ?
> 
> xml:lang,

Sure, then you can also cite xml:base and possibly more. But
these are irrelevant – they they work on a different layer and
have no concept of “feed-level” or “entry-level.” They’re
possibly better described as annotations at the XML level, as
opposed to metadata at the Atom model level.

And with both of them being attributes, the cardinality is
trivial and known in advance: zero or one. Thus the override
mechanism is universally obvious in advance.

They have nothing in common with extension elements as per the
semantics defined in the Atom Format specification.

Regards,

---

From: James M Snell <[email-masked]>
Date: Sun, 21 Aug 2005 20:25:45 -0700

>	I'm sure that copyright and licenses aren't the only problematic
 From the format text: "If an atom:entry element does not contain 
atom:author elements, then the atom:author elements of the contained 
atom:source element are considered to apply. In an Atom Feed Document, 
the atom:author elements of the containing atom:feed element are 
considered to apply to the entry if there are no atom:author elements in 
the locations described above."

This really does not describe an inheritance model*.  This describes a 
scoping model.  If an entry does not contain an author, the author on 
the feed is said to apply.  If the entry does happen to have an author, 
it doesn't matter if the feed also has an author, it is the author 
element on the entry that applies to the entry.  Same thing with the 
license extension (for example).  If both the feed and entry contain 
license links, it is the license link on the entry that is relevant to 
the entry.  If the entry does not contain a license, it looks to the 
feed level.  Placing a license on the feed level does not change the 
license of the entry if the entry already has a license. 

There is another example of this kind of scoping that we're all 
intimately familiar with:

  <x:a xmlns:x="urn:namespace-1" xmlns="urn:namespace-2">
    <x:b xmlns:x="urn:namespace-3">
      <c />
    </x:b>
  </x:a>

 From Section 5.1 of Namespaces in XML: "The namespace declaration is 
considered to apply to the element where it is specified and to all 
elements within the content of that element, unless overridden by 
another namespace declaration" 
(http://www.w3.org/TR/REC-xml-names/#scoping)

To directly address Bob's point that "it isn't possible to claim 
copyright in the collection that is the feed without claiming copyright 
in its individual parts" -- it IS possible if we are looking at this in 
terms of relevant scope as opposed to inherited properties.

Note to self: I need to fix the license spec to address this.  Currently 
the spec limits the license relevance to entries without providing a 
mechanism for attaching a license to the feed itself.

Second note to self: After thinking about this a bit more, I would also 
need a way of specifying a null license (e.g. the lack of a license).  
For instance, what if an entry that does not contain a license is 
aggregated into a feed that has a license.  The original lack-of-license 
still applies to that entry regardless of what is specified on the feed 
level.  Golly Bob, you're right, this is rather messy ain't it. Hmm...

- James

* I've called this inheritance in the past but now I do believe that I 
was mistaken.

---

From: James M Snell <[email-masked]>
Date: Sun, 21 Aug 2005 20:35:58 -0700

>opposed to metadata at the Atom model level.
And yet in the spec we constrain the relevance of xml:lang and xml:base 
to specific elements.  Sure, they operate on the XML level, but they do 
have relevance on the feed/entry level.  Not that this changes your 
argument, it's just an observation that xml:lang and xml:base are not 
entirely dissimilar to atom:author.

- James

---

From: "'A. Pagaltzis'" <[email-masked]>
Date: Mon, 22 Aug 2005 05:52:52 +0200

* James M Snell <[email-masked]> [2005-08-22 05:30]:
> Second note to self: After thinking about this a bit more, I
> would also need a way of specifying a null license (e.g. the
> lack of a license). For instance, what if an entry that does
> not contain a license is aggregated into a feed that has a
> license. The original lack-of-license still applies to that
> entry regardless of what is specified on the feed level. Golly
> Bob, you're right, this is rather messy ain't it. Hmm...

This is exactly the point I was making about atom:contributor.

Regards,

---

From: [email-masked] (Peter Robinson)
Date: Mon, 22 Aug 2005 08:36:16 +0100

> <http://www.ticketswitch.com/cgi-bin/atom_feed.exe?s_geo=53.82:-3.05:10>

To the person looking for items near Park Avenue & 38th, New York.  The
third bit of s_geo is a radius (in km) and it's required.  Try this:

http://www.ticketswitch.com/cgi-bin/atom_feed.exe?s_geo=40.75:-73.98:10

Regards,

Big Brother

---

From: Bill de hÓra <[email-masked]>
Date: Mon, 22 Aug 2005 16:49:01 +0100

James M Snell wrote:
> the feed is said to apply.  

"scope" v "inheritance": call what you like, it's still undefined.

1. We didn't do that, I imagine because it was 'simpler' to say nothing
than introduce formalism. The only person that has tried to formally
define the relationship is Henry afaik. Unless we have defined clearly
the semantics of the relationship between a feed and a entry*, we're
hosed if we start trying to figure out the logical implications of
domain and range of metadata - whatever we conclude, unless it gets
baked into a spec as a patch, somebody with running code will be sure to
conclude otherwise.  Coincidentally I posted a rant about this kind of
specification on xml-dev the other day mentioning feed/entry.

2. It's easy to be tricked by the document structure into thinking there
is some form of natural scoping mechanism. If Atom looked like this

 atom:feed
  atom:feed-metadata-container
  atom:entries-container
     atom:entry

or

 atom:feed
  atom:entries-container
     atom:entry@rel='feed-metadata'
     atom:entry

We probably wouldn't be having this discussion.

> level.  Golly Bob, you're right, this is rather messy ain't it. Hmm...

This is not new ground for the WG.  We've been through it and my
understanding is that feed level metadata does not inherit/cascade/scope
over entries. I seem to recall thinking that atom:author percolating
down from the feed is essentially broken, but the consensus was it
should do that. It's an exception, not a precedent.

As we have no processing model for this, my answer to Paul's question is
that feed level extensions do not inherit/cascade/scope over entry level
ones, irrespective of whether they're foreign or not, and that the best
way to think about atom:author is as a frozen accident.

[I hope the folks working on the APP are paying attention.]

cheers
Bill

* Tangentially touched upon here:
http://www.dehora.net/journal/2004/06/atomrss_relating_entries_and_feeds.html.

---

From: James M Snell <[email-masked]>
Date: Mon, 22 Aug 2005 09:29:19 -0700

>way to think about atom:author is as a frozen accident.
Ok, this is absolutely fine.  I'll go back through and update my various 
extension proposals to reflect this train of thought. 

- James

---

From: Henry Story <[email-masked]>
Date: Mon, 22 Aug 2005 18:56:53 +0200

>> way to think about atom:author is as a frozen accident.

+1

>>
> Ok, this is absolutely fine.  I'll go back through and update my  
> various extension proposals to reflect this train of thought.
> - James
>

---

From: [email-masked] (Peter Robinson)
Date: Mon, 22 Aug 2005 23:01:04 +0100

>   e) Unless otherwise specified, this information pertains to the feed only.

I agree.  Once you've accepted that there's a difference between "the
feed itself" and "the set of all past, present and future articles in
the feed" (which there certainly is in the general case) then you really
have to accept e) as the only possibility for unknown metadata in the
feed head section.

Regards,

Peter

---

From: Tim Bray <[email-masked]>
Date: Mon, 22 Aug 2005 15:32:17 -0700

> it’s d) – but also that aggregators should assume b) when they

Right, the only possible answer. -Tim

---

From: "Bob Wyman" <[email-masked]>
Date: Mon, 22 Aug 2005 19:00:29 -0400

James M Snell wrote:
> Second note to self: After thinking about this a bit more, I would
> also need a way of specifying a null license (e.g. the lack of a license).

> aggregated into a feed that has a license.  The original
> lack-of-license still applies to that entry regardless of what is
> specified on the feed  level.  Golly Bob, you're right, this is
> rather messy ain't it. Hmm...

	My apologies for not having more clearly pointed this out in my
original message. The problem is exacerbated for folk like us at PubSub
since we would feel completely comfortable in claiming copyright over the
"collection" of entries that we pass along to our subscribers, however,
there is *no way* that we could even hint at claiming copyright over the
individual entries themselves. If statements made at the feed level are
"inherited by" or "in the scope of" the entries, then we would not be able
to assert a copyright claim at the feed level since it would "leak" down to
the entries. 
	Of course, one might argue that since we at PubSub will virtually
always ensure that any entry we publish has an atom:source element, one
could argue that we don't have to worry about this scope leakage. But, we're
a special case in this regard. The general issue of scope exists in cases
where the atom:source element is not present.

	bob wyman

---

From: Robert Sayre <[email-masked]>
Date: Mon, 22 Aug 2005 19:36:09 -0400

> way to think about atom:author is as a frozen accident.

I always assumed (and objected, mildly) that the atom:author stuff was
the WG's way of saying you had better write something similar to this
code, which I spotted in the wild (ooh, what's this? A rarely seen RDF
parser... sshh):

item.author = getRDFTargetValue(ds, itemResource, DC_CREATOR)
                                    || getRDFTargetValue(ds, channel,
DC_CREATOR)
                                    || theFeed.title
                                    || item.author;

I didn't really agree that we should say anything about it, but most
other folks did, and I see it more as a fact of life than something
that could be cleared up with a formal model. There will always be
some new extension getting wedged in the search sequence. Which
reminds me, I should write a patch for iTunesRSS.

Robert Sayre

---

From: Karl Dubost <[email-masked]>
Date: Tue, 23 Aug 2005 23:02:50 -0400

> was originally grabbed from"?

hmmm really?

>     <geo:coords>location#2</geo:coords>

What is location#2?
     a. The usual location of the author as in the place is living  
right now?
     b. The place of his origins?
     c. The place where he's blogging right now?
     d. The place he was when he had written the story that he will  
published in a few seconds but two days late with regards to the  
event date?

I say that because for example in my case.

a. My apartment, Montréal, Canada
b. Rouen, France
c. Cafe Laika, Montréal, Canada
d. London, UK

There's exactly the same kind of problems with photos. The location  
where the photos is taken, or the location of (one or more) regions  
in the photos.

It's not that easy to answer at any level.

-- 
Karl Dubost - http://www.w3.org/People/karl/
W3C Conformance Manager
*** Be Strict To Be Cool ***

---

From: Eric Scheid <[email-masked]>
Date: Wed, 24 Aug 2005 16:04:39 +1000

On 24/8/05 1:02 PM, "Karl Dubost" <[email-masked]> wrote:

>> <feed>

c. and d. would be <entry><geo:coords> in their respective entries

b. that would be <geneology:origins><geo:coords> or some variant

a. as a general statement, that matches closely with a semantic reading:
here is a feed by an author who, unless stated otherwise in specific
entries, can be found at <geo:coords>. At least for purposes of this
particular feed.

e.

---

From: Eric Scheid <[email-masked]>
Date: Wed, 24 Aug 2005 16:03:14 +1000

On 22/8/05 1:45 AM, "Paul Hoffman" <[email-masked]> wrote:

> #2 through #4 seem understandable, but what the heck is #1?
> [a] "The place where this feed was put together"?
> [b] "The place where this feed was originally grabbed from"?

[a] would suffer the AOL problem, no? According to my webserver logs, I have
several million visitors from Virginia, and quite a few less from the other
49 US states.
[b] similarly. who cares where the server hardware is.

My intention is perhaps better expressed with this example:

<feed>
    <title>Memoirs from Paris, France</title>
    <geo:coords>location#1 = Paris, France</geo:coords>
    <author>
        <name>Some old digger</name>
        <geo:coords>location#2 = Suva, Fiji</geo:coords>
    </author>

Thus, the feed is a collection of entries to do with some place in France,
written by some old fart laying on the beach in Sunny Fiji. Occasionally he
might write an entry regarding a location in London, UK, and occasionally he
might write an entry during a quick popover to Sydney, Australia.

Nonetheless, if you are looking for a <feed> which could be loosely
categorised as regarding Paris France, then this is one such feed.

e.