Subject: Re: Identity conundrum

From: Mark Baker <[email-masked]>
Date: Sun, 1 Aug 2004 08:24:31 -0400

On Fri, Jul 30, 2004 at 02:08:13PM -0400, Norman Walsh wrote:
> One idea of identity is that entries have immutable identity. That is,
> an atom:id identifies an atom:entry that cannot change.
[snip]
> Another view of identity is that entries are snapshots of an
> abstraction that has identity.

I'd just like to point out that the former is a special case of the
latter, where a particular instance of an entry is the "abstraction
that has identity".

I believe we should support the more general model.

Mark.

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Sun, 01 Aug 2004 21:22:22 +0200

On Fri, 30 Jul 2004 14:08:13 -0400, Norman Walsh <[email-masked]> wrote:

> It seems to me that we have conflicting ideas about what identity
> means and that it might help to look directly at that issue, so here
> goes. [...]

Although I don't disagree with your conceptions, I have another set of  
terms and ideas attached to them:

   «Dynamic resource» or «Streaming resource»

     This is a resource that is dynamically updated by either new
     revisions or modifications to the same subject (aka story),
     or by representing many different resources about the same
     type of subject.

     Examples of dynamic resources is the front page of a web site,
     an RSS or Atom feed, chaning (aka non-stable) RSS or Atom
     entries and a web page or Atom entry representing «Tomorrow's
     weather reports».

   «Static (aka stable) resource»

     This is a resource that is created and issued only once, and
     will never change to give or have another meaning. It will
     always be about one single subject, and the view on that
     subject will always be the same, whenever you retrieve the
     resource.

     Examples of static resources is revisioned Atom entries, the
     individual versions of a given specification, or any other
     resource that is issued only once.

-- 
Asbjørn Ulsberg         -=|=-        [email-masked]
«He's a loathsome offensive brute, yet I can't look away»

---

From: "Laurent Le Meur" <[email-masked]>
Date: Mon, 2 Aug 2004 11:55:48 +0200

The unique identity of an entry is particularly useful in two situations: 
1/ asserting that two entries at different location, and maybe in a
different physical form, convey the same meaning (i.e are exactly the same
or are snapshots of the same abstraction), and so avoiding duplicates.
2/ being able to link unambiguously and in a permanent way an entry to
another entry.

Let's imagine a comment about an opinion. If the author of the opinion
changes his mind after the comment is published, and updates his entry
without any change of identification, the comment will become totally out of
sync with the linked entry. 

If the update of an entry is really significant (if its meaning/semantics
has changed) then can it still really be the same entry? I suggest that it
should rather be a new entry *derived from* (or superceding as in [1] if I
understand correctly) the previous one. 

Is it something worth mentioning in the 4.2.6 ("atom:id" Element) paragraph?

On the other side a/ for metadata modification or content corrections, which
do not imply a change of meaning of the content and b/ for dynamic resources
[2] like the front page of a web site or the TOC of a document, links to the
entry don't risk being semantically broken. It may then be useful to put a
revision mechanism in place and be able to link to a certain revision of the
entry but it is not required (the NewsML and LSID URI schemes support
revisions but many URI schemes don't).

Note: the debate on "update date-time" is related to this notion of identity
of an item and significant changes; given the moratorium on dates, I won't
comment on this part now.

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

Laurent Le Meur
Agence France Presse

  > -----Message d'origine-----
  > De : [email-masked] [mailto:owner-atom-
  > [email-masked]] De la part de Asbjørn Ulsberg
  > Envoyé : dimanche 1 août 2004 21:22
  > À : Norman Walsh
  > Cc : Atom-Syntax
  > Objet : Re: Identity conundrum
  > 
  >

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Mon, 02 Aug 2004 16:08:52 +0200

On Mon, 2 Aug 2004 11:55:48 +0200, Laurent Le Meur  
<[email-masked]> wrote:

> without any change of identification, the comment will become totally  
> out of sync with the linked entry.

Yep. This is right on the nail and the exact thing I've tried to express  
all along. Consensus seem to be (but I'm not sure) that such a model is  
too much to require from a blog tool, which I am not the right person to  
either validate or invalidate.

> has changed) then can it still really be the same entry? I suggest that  
> it should rather be a new entry *derived from* (or superceding as in [1]
> if I understand correctly) the previous one.

Indeed.

> Is it something worth mentioning in the 4.2.6 ("atom:id" Element)  

I'm not sure. That probably depends on what conensus is that atom:id  
should identify. If it's only going to identify what I call «a story» and  
not «story instances» or «versions», such language would not fit in the  
core specification. I think the core specification should say something  
about this, but I'm not sure what.

What I am sure of, is that the versioning and more professional publishing  
model should be reflected with an extension. How this extension may look  
like is still very blue-ish, but I think Ken's very old proposal of just  
having a <profile> element in the <feed>, that exists in a known  
namespace, would be a good solution. Se this message for more details:

<url: http://www.imc.org/atom-syntax/mail-archive/msg08221.html>

> On the other side a/ for metadata modification or content corrections,  
> which do not imply a change of meaning of the content and b/ for dynamic  
> resources [2] like the front page of a web site or the TOC of a document,
> links to the entry don't risk being semantically broken.

Correct. I'm in no doubt that the better of the two models, in my opinion,  
is the versioning one. The problem is that I don't think we can enforce  
this model on anyone. Those who want it should be able to pick it, but  
those who don't should be able to pick that as well.

> It may then be useful to put a revision mechanism in place and be able
> to link to a certain revision of the entry but it is not required (the
> NewsML and LSID URI schemes support revisions but many URI schemes  
> don't).

Yes. That's why an extension mechanism that alters the semantics of  
atom:id also can alter the requirements for atom:id. Such an extension (or  
rather; profile) could state that «The content of atom:id MUST be created  
in a URI scheme that supports versioning», or even «The content of atom:id  
MUST be a NewsML URN».

> Note: the debate on "update date-time" is related to this notion of  
> identity of an item and significant changes; given the moratorium on
> dates, I won't comment on this part now.

You're right, but I'll pipe down on the subject as well. :-)

---

From: Dave Pawson <[email-masked]>
Date: Mon, 02 Aug 2004 19:04:01 +0100

Could someone explain the motivation to  generate a unique ID
value, URI or otherwise, for the manual blog author?

Seems fine to argue over the minute detail of comparing two,
I'm curious what happens when 3000 http://example.com 'id' values
show up in blogspace?

Curious DaveP.

---

From: Dare Obasanjo <[email-masked]>
Date: Mon, 2 Aug 2004 11:24:17 -0700 (PDT)

> http://example.com 'id' values

http://www.imc.org/atom-syntax/mail-archive/msg07874.html

=====
THINGS TO DO IF I BECOME AN EVIL OVERLORD #25
No matter how well it would perform, I will never construct any sort of machinery which is completely indestructible except for one small and virtually inaccessible vulnerable spot.

__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail

---

From: Sam Ruby <[email-masked]>
Date: Mon, 02 Aug 2004 14:25:47 -0400

> I'm curious what happens when 3000 http://example.com 'id' values

Simple answer: last one wins.

A frequent complaint that aggregator authors receive is that users get 
to see entries multiple times.  One reason for this is the lack of feeds 
consistently providing ids.  Another is that sites that republish other 
feeds typically assign a new id.

If we can make meaningful progress towards addressing these two 
problems, then aggregators can identify whether or not the user has seen 
this entry before.

Once we get that far, there are more questions.  What if the content is 
different than was seen previously?  One school of thought is to 
disallow this, and require that all changes require new a id to be 
assigned.  Another is to allow the producer to provide some sort of 
indication as to whether this was a minor change unworthy of attention 
or significant - something Tim Bray attempts to accomplish today by 
changing pubDate, with some success in NetNewsWire and without success 
in RssBandit.

- Sam Ruby

---

From: Ken MacLeod <[email-masked]>
Date: 02 Aug 2004 13:27:04 -0500

Dave Pawson <[email-masked]> writes:

> Seems fine to argue over the minute detail of comparing two, I'm
> curious what happens when 3000 http://example.com 'id' values show
> up in blogspace?

Newsreaders that support IDs (guid in RSS 2.0, rdf:about in RSS 1.0)
will only display one copy of an entry with the same ID.  Other
entries will be discarded.

> Could someone explain the motivation to generate a unique ID value,
> URI or otherwise, for the manual blog author?

The motivation for *having* an ID is to know when to entries *are* the
same entry, so they are not redisplayed as new.  Some newsreaders will
go a little further and indicate if an "already seen" entry has
changed, but it won't be reported as a new entry (ie. won't pop to the
"top" of the list, it'll only be highlighted or flagged in some way).

The way this was done prior to guid/rdf:about depended on the title or
permalink not changing (where many permalinks are based on the title
anyway), but that has a lot of other problems.

  -- Ken

---

From: Dave Pawson <[email-masked]>
Date: Mon, 02 Aug 2004 20:04:16 +0100

On Mon, 2004-08-02 at 19:27, Ken MacLeod wrote:

> same entry, so they are not redisplayed as new. 

I see this as a 'reader' view? 
Dare notes, pragmatically, that if an author cares, 
<quote> The point is that experience has taught us
that if people can use HTTP URLs as identifiers, they
will use permalinks not some abstract "globally unique
identifier".</quote>

Sam notes
<quote>A frequent complaint that aggregator authors receive is that users get 
to see entries multiple times.  One reason for this is the lack of feeds
consistently providing ids.</quote>

Is the implication that I'll only seek to use a unique ID
value if I care about how my musings are collated/distributed?
Dare I say vanity?

Is that sufficient motivation?
Instance:
A new author, hasn't bought a domain name, isn't using blogging atom
software, where does he dream up his uri?

Will Atom provide a stream of these?

What will the blogging software do? Use the product uri+... something?
Dare's solution is pragmatic for some cases, where they can be
de-referenced. For other cases?

-- 
Regards DaveP.
XSLT&Docbook  FAQ
http://www.dpawson.co.uk/xsl

---

From: Sam Ruby <[email-masked]>
Date: Mon, 02 Aug 2004 17:26:41 -0400

> value if I care about how my musings are collated/distributed?

Fetch http://www.intertwingly.net/blog/index.atom, and you will see 
approximately 20 entries.  Fetch it each hour, on the hour, you will see 
a total of 480 entries.  Many of them you will have seen before.

Now, fetch http://www.planetapache.org/rss10.xml.  You will see some of 
the same entries.  Now start fetching that feed hourly.

Pretty soon you will be wanting an algorithm which allows you to 
determine if you have seen an entry before.

A first order approximation would be to use the link element.  This 
works very well if you are very careful, and works reasonably well if 
you aren't.

Unfortunately, if you are a consumer, reasonably well times dozens of 
feeds over a period of months means that you will see failures.  And if 
you are an aggregator vendor with hundreds, if not thousands, of users, 
that means that you will hear complaints daily.

That's why there is so much interest in picking an id scheme that 
encourages best practices.

- Sam Ruby

P.S.  Your XSLT faq was *very* helpful when I was learning XSLT nearly 
four years ago.  I still reference it periodically.  Thanks!

---

From: "Laurent Le Meur" <[email-masked]>
Date: Wed, 4 Aug 2004 10:38:57 +0200

> namespace, would be a good solution. 

[llm] It is only a personal opinion, but I believe that an Atom professional
extension not supported by the news industry will be a loss of time. This is
why synchronization between Atom and NewsML 2 would still be worth studying
(that was briefly discussed during the News Standards Summit in Philadelphia
last winter http://www.idealliance.org/news-summit/, and an article written
by F.Zimmerman some time ago discusses this view at
http://www.wfzimmerman.com/article.php/20040504183303433).

  > atom:id also can alter the requirements for atom:id. Such an extension
  > (or rather; profile) could state that <The content of atom:id MUST be
  > created in a URI scheme that supports versioning>, or even 
  > <The content of atom:id MUST be a NewsML URN>.
  > 
[llm] I'm concerned by the idea of having varying semantics for a given
element: a conceptual model should be stable. But I would perfectly
understand profiles applied to the processing model (at a given level the
processor must do this and that, and maybe yes, a given element value must
fulfill this and that requirement).

Amts
llm

---

From: Walter Underwood <[email-masked]>
Date: Sun, 08 Aug 2004 15:51:38 -0700

--On Sunday, August 1, 2004 9:22 PM +0200 Asbjørn Ulsberg <[email-masked]> wrote:
>
> ... a web page or Atom entry representing «Tomorrow's weather reports».

I know this is a bit pedantic, but "reports" are measurements of current
or past weather and "forecasts" are about the future. Reports don't
change ("static resources"), forecasts do ("dynamic resources").

I like the distinction, though I would not say "never change" for
general resources. HTML static resources change a lot, with rotating ads,
site redesigns, related headlines, while remaining the same resource.

wunder
--
Walter Underwood
Principal Architect, Verity