ATOM IRC Chat Logs for 2004-06-22

00:01:01 <bitsko> is it ok to conduct straw polls on the wiki? ie. for PaceLinkParent, can we add a section for "parent" vs. "in-reply-to" and get an idea of who's in favor? not a vote, mind

00:01:50 <rubys> IETF would prefer straw polls be on the list

00:02:19 <rubys> that's a good poll, it doesn't so much matter which is picked, merely that ONE is picked.

00:02:45 <bitsko> ah, "IETF says", cool ;)

00:03:54 <sbp> heh: [[[

00:03:55 <sbp> Thanks for considering us! Let's stay in touch :)

00:03:55 <sbp> *

00:03:55 <sbp> Dan Brickley (W3C, Semantic Web Interest Group chair)

00:03:55 <sbp> *

00:03:55 <sbp> MattMay (W3C, Web Accessibility Initiative)

00:03:57 <sbp> *

00:03:59 <sbp> KarlDubost (W3C, Conformance Manager, QA WG Chair)

00:04:01 <sbp> *

00:04:03 <sbp> Max Froumentin (W3C, Interaction Domain)

00:04:05 <sbp> ]]] - http://www.intertwingly.net/wiki/pie/IetfVersusW3cVote

00:04:11 <sbp> odd HTML -> Text, Firefox

00:04:34 <sbp> ah, <p>s inside the <li>s

01:53:46 <sayrer> markp: good to see you on atom-syntax again

01:53:56 <markp> it's joe's fault

01:54:05 <jcgregorio> hehe

01:54:23 <bitsko> ruh roh ;)

01:54:37 <markp> mostly i'm using it to test out gmail

01:54:48 <markp> which totally rocks for following mailing lists

01:55:05 <markp> bummer about that whole "discrimating against the blind" thing, though

01:55:18 <markp> discriminating

01:56:04 * sayrer blames jcgregorio

01:59:46 <markp> but anyway, i have more free time now

01:59:53 <markp> book has gone to the printer

01:59:58 <markp> new job has settled down

02:00:05 <sayrer> what is the title of chapter 17?

02:00:17 <markp> i forget which we finally chose

02:00:19 <markp> :)

02:00:24 <sayrer> heh

02:19:19 <jcgregorio> sayrer: what operating system do you run?

02:26:00 <sayrer> I run OS X if I have a choice, otherwise it's usually Windows

02:27:32 <sayrer> Windows is not that bad with Emacs, Python, Perl, and Windows Services for Unix installed

02:27:54 <jcgregorio> ok, I am setting up the subversion acccess which requires ssh in some form

02:28:06 <sayrer> I have subversion everywhere

02:28:25 <jcgregorio> cool

02:29:20 <jcgregorio> could you generate a key and send it to me? that may make things easier

02:30:03 <sayrer> yeah

02:31:26 <sayrer> "ssh-keygen -t rsa" ok?

02:33:12 <jcgregorio> yes

02:37:32 <sayrer> sent

02:37:57 <sayrer> already found the .xml version on your server, btw

02:38:29 <imajes_> imajes_ is now known as imajes

02:40:48 <jcgregorio> ok, now try logging on to bitworking.org with that key

02:42:15 <jcgregorio> you should get something like:

02:42:26 <jcgregorio> ( success ( 1 2 ( ANONYMOUS EXTERNAL ) ( edit-pipeline ) ) )

02:46:35 <bitsko> random question: rel="parent", same host only or distributed?

02:46:49 <bitsko> s/host/feed/

02:47:15 <jcgregorio> I prefer 'inReplyTo' and to have it distributed

02:48:39 <jcgregorio> thus completing the circle and turning this all back into usenet

02:56:30 <bitsko> or UseNet2, where every source is verified.

02:59:18 <bitsko> verified != spam free, but far more resilent to abuse of any kind.

02:59:18 <bitsko> resilient, even

03:00:50 <jcgregorio> yeah, and I think domainkeys + Atom gets you the verified part

03:02:33 <bitsko> I was thinking of the opt-in subscriptions

03:03:22 <jcgregorio> ahh, I was thinking of CommentAPI like usage of the AtomAPI + DomainKeys

03:09:49 <bitsko> I know several sites that have turned off comments specifically with the intent that people host their own comments. some have even stated it in almost those words.

03:32:14 <markp_> markp_ is now known as markp

04:04:10 <bitsko> grrr, and off-by-2 error on the atom-syntax mailing list between the entire-arch.txt and the message numbers generated by imc.org

04:04:33 <jcgregorio> ouch

04:37:18 <bitsko> hmm, if <feed><link rel="prev">, what's the point of replicating all the "feed metadata". seems to me it's not "feed metadata" but "site metadata".

04:41:23 <rubys___________> rubys___________ is now known as rubys

05:03:39 <bitsko> hmmm. why is link/@type required?

05:05:34 <bitsko> application/i-dont-care seems to validate...

07:24:44 * avk thinks TYPE should be removed

07:24:47 <avk>http://annevankesteren.nl/archives/2004/06/hreflang-and-type

07:25:09 <avk> "you can't give metadata about a link when that metadata relies on content negotiation"

10:32:13 <bblfish> Atom in N3 example http://bblfish.net/programming/atom-owl/examples/2004-06-22/

10:37:38 <bblfish> uses the feedIsAEntry model

10:37:39 <bblfish> entries can turn into feeds when people post comments, as shown by entry entry.2004-05-10.2020.n3

10:46:07 <bblfish> Also the main feed (which only has two entries) points to the two older entries

10:47:38 <bblfish> these are located in feed.bblfish.older.n3

10:52:05 * bblfish is off to lunch

13:39:28 <bitsko> danja_: why the emphasis on representation equivalence? how different is "different"?

13:40:36 <bitsko> for example, I was just now reading RFC2822 and it says this about message identity:

13:40:38 <bitsko> Note: There are many instances when messages are "changed", but those

13:40:39 <bitsko> changes do not constitute a new instantiation of that message, and

13:40:39 <bitsko> therefore the message would not get a new message identifier. For

13:40:39 <bitsko> example, when messages are introduced into the transport system, they

13:40:39 <bitsko> are often prepended with additional header fields such as trace

13:40:40 <bitsko> fields (described in section 3.6.7) and resent fields (described in

13:40:42 <bitsko> section 3.6.6). The addition of such header fields does not change

13:40:44 <bitsko> the identity of the message and therefore the original "Message-ID:"

13:40:45 <bitsko> field is retained. In all cases, it is the meaning that the sender

13:40:48 <bitsko> of the message wishes to convey (i.e., whether this is the same

13:40:52 <bitsko> message or a different message) that determines whether or not the

13:40:53 <bitsko> "Message-ID:" field changes, not any particular syntactic difference

13:40:56 <bitsko> that appears (or does not appear) in the message.

14:03:24 <bitsko> yow. some of those "Proceed" Paces have some odd quirks. <author><ipaddr>?!!

14:08:04 <sayrer> Sam Ruby: "Proceed" simply means that I recommend that this Pace proceed to closure - either by incorporation or rejection.

14:09:52 <rubys>http://www.intertwingly.net/wiki/pie/AtomPubIssuesList

14:18:42 <bblfish> hi

14:19:41 <danja_> bitsko: sorry, was out with dog

14:19:57 <bitsko> np, I think the followups address the question

14:20:03 <bblfish> hi danja!

14:20:13 <bblfish> I have an atom in N3 example now at http://bblfish.net/work/atom-owl/2004-06-22/blogexample.html

14:21:41 <bblfish> It's an ugly looking feed, but it should help explain how I am thinking of this.

14:22:36 <bblfish> I have removed the State object now.

14:23:16 <danja_> nice view

14:23:53 <bblfish> It is incredibly simple really.

14:24:02 <danja_> entries with entries?

14:24:05 <danja_> within

14:24:23 <bblfish> no Feeds only point to Entries.

14:24:30 <bblfish> But Entries can also be Feeds

14:24:32 <bblfish> :-)

14:24:55 <danja_> bitsko, yep - MarkB's clock example was a beaut

14:25:57 <bitsko> bblfish: I don't recall your position on "entries are all peers"

14:26:23 <bblfish> I am not sure... can you expand? may have been someone else.

14:27:12 <bblfish> I think this model shows how entries should all be GET able. It makes things very convenient

14:27:26 <bblfish> (they can also have ids)

14:27:32 * danja_ better leave for now - got 20 pages to write today ;-)

14:27:45 <bblfish> ok. see you.

14:28:42 <bblfish> Any coments? Does it look good enough to post to the list?

14:29:31 <bitsko> "entries are all peers" deprecates the significance of a feed class by instead supporting specific relations between entries. where "entries can also be Feeds" implies a feed, "entries are all peers" says that child entries have a "parent" or "in-reply-to" property that links to the parent entry.

14:30:12 <bblfish> This is very close to that position I think.

14:31:07 <bblfish> When you know that something is a Feed in my model, you also know that it has various types of extra properties you can look for.

14:32:27 <bblfish> Namely if you look at http://bblfish.net/work/atom-owl/2004-06-22/feed.bblfish.n3 it has atom:entry links to other entries and also link objects to a url with more such atom:entry relations

14:35:54 <bblfish> The whole thing could be made still much more elegant in N3 than it currently is. For example the link object in the above file has a pointer to a string uri. In N3 the link should point to a resource, which could be described.

14:36:32 <bblfish> But for the moment this mirrors much more closely the Atom api which makes it easier to understand.

14:38:50 <bblfish> So any extra questions?

14:40:19 <avk> I have a different question, what is the best location to documentate rel="about" and such?

14:40:24 <avk> we have /LinksLog

14:41:49 <avk> no-one here with a idea?

14:42:11 <bblfish> on the wiki?

14:42:13 <bitsko> PaceLinkConstruct is at the top section of the issues list, and it has the list of link types

14:43:13 <bitsko> the best place to edit would be LinkTagMeaning

14:43:37 <bitsko> presumably, PaceLinkConstruct is getting its input from LinkTagMeaning

14:45:31 <sayrer> bitsko: been thinking about the feed :: collection thing

14:46:18 <sayrer> thinking about an optional element for feed that links to the collection it's derived from

14:46:54 <sayrer> rather than getting into feed paging and querying

14:47:59 <bitsko> collection or collection(s)?

14:48:50 <sayrer> collection

17:43:54 <markp_> markp_ is now known as markp

17:56:25 <quarkie> anyone here interested in the 'in-re' vs 'in-reply-to' vs 'parent' discussion?

17:56:32 <quarkie> I just have some questions

18:12:58 <avk> quarkie, still there?

18:18:35 <bitsko> I am, obviously ;)

18:18:57 <bitsko> interested, that is. here now for a moment

18:20:18 <bitsko> for reference, distributed commenting is a separate issue from what the relation is named.

18:27:56 <avk> bitsko, what is your name on the list?

18:39:34 * bblfish phew. lots of fixes to atom in N3

18:42:24 <avk> bblfish, what is n3?

18:42:53 <bblfish> N3 is Tim Berners Lee's elegant shorthand for RDF

18:43:16 <avk> bblfish, is it an abbreviation?

18:43:22 <bblfish> you can see it here: http://bblfish.net/work/atom-owl/2004-06-22/feed.bblfish.n3

18:43:38 <bblfish> It just look good, is easy to read.

18:43:43 <avk> I have some trouble retrieving pages at the moment

18:44:04 <avk> bblfish, does the syntax uses caps, camelcase?

18:44:13 <bblfish> see: http://infomesh.net/2002/notation3/#this

18:44:53 <avk> bblfish, is that some shorthand syntax?

18:45:01 <markp_> ooh

18:45:03 <markp_>http://www.w3.org/DesignIssues/Notation3.html

18:45:06 * avk thinks it doesn't look like XML, the .n3 example

18:45:10 <markp_> "N3 files are encoded in UTF-8 (See RFC2279), in normalized in Normalization Form C."

18:45:36 <petey> not sure if "easy to read" is the right way to describe it ;)

18:45:44 <markp_> markp_ is now known as markp

18:45:44 <bblfish> yes. It is shorthand way of writing Semantic Web stuff, to put it simply. It can be translated automatically into XML

18:46:00 <bblfish> well. It is easier to read than RDF in XML that is for sure.

18:46:02 <markp> i knew about it, but i didn't know it mandated utf-8

18:46:04 <markp> utf8++

18:46:20 <avk> yeah, transform the web to utf-8!

18:46:24 <bblfish> utf is good. :-)

18:46:26 <bblfish> Neither did I.

18:46:35 * markp wonders what "normalized form c" is

18:46:40 <markp> and down the rabbit hole we go

18:46:58 <avk> :author [ a :Person ;

18:46:59 <avk> :email "hjs@bblfish.net" ;

18:47:01 <avk> :name "Henry Story" ;

18:47:02 <avk> :url "http://bblfish.net/"

18:47:04 <avk> is considered readable?

18:47:13 <markp> it beats the rdf/xml alternative

18:47:37 <avk> actually, it is readable :)

18:47:39 <bblfish> you left the object out.

18:47:48 <bitsko> avk: bitsko == Ken MacLeod

18:48:07 <avk> bitsko, I think I just responded to you then, about the LINK stuff

18:48:23 <bblfish> the object is <>

18:48:50 <avk> so this is RDF without namespaces?

18:48:58 <bblfish> it says the current document (<>) has author a Person whose email is hjs@bblfish.net

18:49:31 <bblfish> it has namespaces. I just added them.

18:49:53 <bblfish> (but perhaps I have misunderstood.) what do you mean by namespaces?

18:49:59 <avk> bblfish, doesn't it say the ENTRY element has a author? (just guessing here)

18:50:19 <avk> bblfish, I meant the extremely complex RDF syntax that I don't find in this syntax ;)

18:50:23 <bblfish> yes the document <> is an Entry

18:50:47 <bblfish> <> a :Feed , :Entry ;

18:51:03 <bblfish> that says: the current document is a Feed and an Entry

18:51:44 <avk> bblfish, hmm, so it doesn't explicitely mention ENTRY is a child of FEED

18:51:58 <bblfish> No that is in the OWL document.

18:52:11 <bblfish> The OWL document is in RDF, but I can convert it to N3...

18:52:50 <bblfish> This is the ugly old rdf: http://bblfish.net/work/atom-owl/2004-06-22/atom.owl

18:53:26 <avk> heh

18:53:32 <avk> that looks a bit difficult

18:53:47 <avk> understanble probably, but difficult

18:53:57 <avk> standable*

18:54:50 <bblfish> I just converted that to N3: http://bblfish.net/work/atom-owl/2004-06-22/atom.n3

18:55:41 <bblfish> The OWL document states that an Entry is a Feed in this passage:

18:55:43 <bblfish> ns:Feed a owl:Class;

18:55:45 <bblfish> :comment """A feed

18:55:46 <bblfish> The Atom entry id is the object's resource URI (So there is no id property) """^^XML:string;

18:55:47 <bblfish> :subClassOf ns:Entry,

18:56:32 <bblfish> That should be much easier to understand.

18:57:07 <avk> a bit

18:57:38 <avk> when Google is going to use RDF heavily I will know it, hopefully

18:57:45 <bblfish> So. You write an OWL document, using the WYSIWIG Protégé editor http://protege.stanford.edu/

18:57:47 <bblfish> which gives you your ontology

18:58:03 <bblfish> That essentially gives you a spec.

18:59:25 <bblfish> You can draw a UML diagram from it if you want, that makes it easier to understand

19:00:13 <bblfish> the way I did here: http://bblfish.net/work/atom-owl/2004-06-22/blogexample.html

19:01:18 <bblfish> There is not much behind all of this. It takes a little getting to know. :-) The first people to do it always find the paths most difficult to tread. The rest often just use the motorway.

19:01:29 <avk> looks interesting

19:01:50 <bblfish> very :-) very flexible.

19:01:57 <avk> I should probably take a look here http://www.w3.org/TR/owl-guide/

19:02:10 <avk> but why do we need OWL, was RDF not flexible enough?

19:02:27 <avk> or did RDF they dislike the RDF syntax as much as I do?

19:02:40 <avk> s/RDF//

19:02:43 <bblfish> It would be easier to understand OWL if you just play with Protége. It is free and written in Java

19:03:05 <bblfish> OWL is a layer above RDF

19:03:09 <bitsko> OWL is to RDF as XML Schema/RelaxNG are to XML

19:03:21 <bblfish> good comparison

19:03:44 <avk> ah

19:03:50 <avk> I know a bit XML Schema

19:04:18 <bblfish> I knew nothing about Blogging, Atom, OWL or RDF three months ago.

19:04:21 <avk> So OWL describes the RDF?

19:04:31 <bitsko> OWL does a lot more things than just define "schema", though, such as define how classes and properties are derived and compare to other classes and properties.

19:04:45 <bblfish> OWL is like writing your java classes

19:05:02 <bitsko> OWL lets us say atom:author "is the same as saying" dc:creator

19:05:16 <avk> ah ok

19:05:32 <bblfish> If you think UML it makes it very easy.

19:05:45 <avk> UML?

19:05:51 * bitsko has made that comparison before ;)

19:06:34 <bblfish> the diagram http://bblfish.net/work/atom-owl/2004-06-22/blogexample.html is in UML

19:06:43 <bblfish> Uniform Modelling Language.

19:06:50 <bblfish> :-)

19:07:06 <bblfish> You see them all the time when you learn OO programming

19:07:22 <bitsko> http://bitsko.slc.ut.us/blog/rdf-relational.html , where I describe how RDF is a lot like a relational model, a la UML

19:07:24 <avk> so much to learn :)

19:07:43 <bblfish> yeah. Its kindof fun bitsko, OWL is turning XML into a real OO programming language

19:07:56 <bblfish> (and a lot more of course )

19:07:59 <bitsko> egads, I hope not! ;)

19:08:50 <bblfish> yea. I leanrt most of this in 3-4 months. So it is not hugely difficult.

19:08:52 <bblfish> If you take Protége, and load the OWL model above it will make sense

19:08:57 <bitsko> if they ever conflate behavior with state, I might have to do something drastic

19:09:37 <bitsko> OO so tightly bound behavior and state that we're still digging out from that fiasco

19:09:56 <bblfish> I don't think so. OWL comes from Description Logics. It is derived from a logical theory, with a mathematical backbone.

19:10:22 <bitsko> k, mostly just kidding. time for a topic change,

19:10:43 <bitsko> avk, what did you mean by "This is the same for |rel="related"|, |rel="via"| and I don't see you use for a restriction on |rel="about"| either."

19:10:52 <bitsko> either or both parts of that

19:11:23 <bitsko> are you saying that related, via, and about are all refinements of parent also?

19:11:36 <avk> bitsko, "An atom:entry MAY have one or more parent links."

19:11:53 <avk> bitsko, it was related to exactly that sentence, I should have been more explicit

19:12:12 <bitsko> oh, I took that straight from PaceLinkParent. the earlier statements were informal, not spec copy

19:12:36 <bblfish> thanks for the pointer bitsko

19:13:26 <bblfish> (to your blog)

19:14:10 <bitsko> 'welcome

19:14:50 <bitsko> avk: do you see having separate "profiles" for link blogs vs. other atom feeds?

19:15:04 <avk> bitsko, not really

19:15:31 <avk> bitsko, I probably shouldn't have mentioned that as well, since it was pretty clear already

19:15:34 <bitsko> so it would make sense to have link relations be "universal", when that's appropriate?

19:15:47 <avk> bitsko, I think it might always be appropriate

19:16:09 <avk> since you could go into length commenting on a single post (about)

19:16:25 <avk> which would be more appropriate for a weblog entry

19:16:58 <avk> and not a link log entry, which is for short pointers with funny or sarcastic lines :)

19:17:49 <avk> bitsko, also, you could have several related posts you have written in the past, or posts other people have written etc.

19:18:02 <avk> bitsko, you post could be a comment as well (parent)

19:18:04 <avk> your

19:18:13 <bitsko> that's what I meant about "off topic" in reply to your "What would a off-topic comment look like?", maybe I misunderstood what you meant by off-topic

19:18:17 <avk> only in the form of a individual weblog entry

19:18:58 <avk> bitsko, somebody makes a comment on a weblog saying: "Your comment system doesn't work as expected: point 1, 2 etc."

19:19:12 <avk> when the post is actually about CSS 3 selectors

19:19:20 <avk> that isn't a reply

19:19:29 <avk> that is off-topic

19:19:38 <avk> it is still a parent/child relation though

19:21:14 <bitsko> ah, ok. what do you think of the gallery->photo use case. also parent/child?

19:23:41 <avk> bitsko, each photo is its own ENTRY pointing towards 1 ENTRY being the gallery?

19:23:47 <avk> bitsko, using parent?

19:24:31 <bitsko> yes

19:24:53 <avk> yeah, that would be a correct example

19:25:44 <bitsko> you would expect an aggregator to both: display the gallery entry and then also show each individual photo entry as "replies"

19:26:08 <avk> bitsko, as in a tree view, or similar

19:26:25 <avk> bitsko, options for expanding the parent entry for example

19:26:56 <avk> bitsko, like with directories

19:27:26 <avk> note that I'm not a UI person, so there is a fair chance I'm missing something here

19:27:31 <bitsko> ok. do you navigate directories the same way you navigate threaded conversations?

19:28:24 <avk> In Mozilla mail I do

19:28:56 <avk> having multiple mail boxes which I can expend on one side

19:29:08 <avk> on the other side appear the e-mails, threaded

19:29:21 <avk> and everything can be collapsed, uncollapsed

19:29:46 <bitsko> and the threaded emails can be just like files in a directory?

19:30:23 <bitsko> more importantly, you'd expect to see the root message have, say, 12 photos, and then the next message "in the thread" is photo 1 of 12.

19:30:55 <avk> bitsko, I expect them to be ordered by date

19:31:05 <bitsko> "root message" == "first message in thread"

19:31:44 <avk> bitsko, note that within a thread a comment can become a new "root"

19:31:46 <bitsko> not ordered and nested by thread, at least optionally?

19:32:04 <avk> bitsko, actually, ordering etc. should be up to the aggregator

19:32:26 <avk> I think Atom provides enough information to the aggregator to come up with a lot of alternatives if desired

19:32:56 <avk> We could mention something non normative, but I'm not sure how that would be useful

19:33:03 <avk> I tutorial might have more effect

19:39:14 <bitsko> ok, my specific concern is that we're *not* providing an aggregator the right information that allows them to intelligently display a "directory of files" any differently than "a threaded discussion".

19:39:56 <avk> how, it does have that information?

19:40:44 <avk> bitsko, off-topic where did you find this high 1 and 2 for footnotes, does a high e exists as well, so I don't have to use <sup>?

19:41:17 <bitsko> I found it in a character table once. I think there's a 3, but I'm not aware of any others.

19:41:52 <bitsko> is a high e a math symbol? you might find it there.

19:42:13 <bitsko> there's no full "high character set", unfortunately.

19:42:28 <bitsko> heh, they'd have to replicate virtually all of Unicode to do that ;)

19:43:19 <bitsko> back to threading. in mail readers, mail readers have thread relations that let them render properly nested threaded replies.

19:43:49 <avk> no dutch for second is "tweede" which becomes 2^e

19:44:00 <bitsko> ah

19:44:04 <avk> I might have luck here": http://www.unicode.org/charts/PDF/U2070.pdf

19:44:26 <avk> not

19:44:36 <avk> that only covers numbers and some special characters

19:45:43 <bitsko> if Atom allows "entries as feeds", then an entry would be a feed of its comments, and replies to comments would seem to fork off another feed. that's doable, of course, but excessive.

19:46:19 <avk> bitsko, an aggregator doesn't think in feeds

19:46:20 <bitsko> but it preserves the "threading view" because specific replies are attached to their parent messages. note, hey, I used "parent" to refer to a message!

19:46:21 <avk> I hope

19:46:28 <avk> Since feeds are not permanent

19:47:03 <bitsko> right, the better aggregators are starting to keep a back-feed of entries.

19:47:22 <bitsko> but, if they're using wfw:commentRss, for example, then their comments "all line up"

19:47:51 <bitsko> RSS doesn't support nested comments, afaik, but there's a lot of publishers now that do. that's a use case.

19:48:29 <bitsko> <avk> bitsko, an aggregator doesn't think in feeds

19:48:47 <bitsko> Dare seemed to indicate that that is exactly how RSS Bandit handles wfw:commentRss comment feeds.

19:49:08 <avk> Maybe he is doing the wrong thing?

19:50:10 <bitsko> I'

19:50:33 <bitsko> I'm not aware of any thing else available currently

19:51:03 <avk> That supports that?

19:51:34 <avk> I know that bloglines backups all entries, for example

19:51:38 <avk> and metadata

19:51:46 <bitsko> that supports comments to entries, threaded or otherwise

19:52:37 <avk> o

19:53:14 <bblfish> I am trying to follow this conversation a little. How does this realte to FeedIsAEntry? Any ideas?

19:53:27 <avk> what is that?

19:53:35 <avk> Mixing FEED with ENTRY?

19:54:00 <bblfish> Well in my model, a Feed is simply an Entry that points to other entries.

19:54:32 <avk> bblfish, using feed>entry

19:54:38 <avk> bblfish, or feed>content

19:54:56 <bblfish> the first

19:55:18 <avk> bblfish, what is the problem with that?

19:55:23 <avk> seems to be valid already

19:56:13 <bblfish> Oh. yes. But a Entry can turn into a Feed

19:56:17 <bblfish> in my model

19:56:35 <bitsko> bblfish: how does FeedIsAnEntry handle nested, threaded comments where replies can reply-to other replies?

19:56:48 <bitsko> each "branch" is a FeedIsAnEntry?

19:57:01 <bblfish> yes

19:57:09 <bblfish>http://bblfish.net/work/atom-owl/2004-06-22/blogexample.html

19:57:15 <bitsko> do you have an Atom XML example?

19:57:54 <bblfish> I posted the beginning of one. In modelling terms I can get it in N3. It should be possible to specify it in simple XML way too

19:57:56 <bitsko> that's good enough

19:58:45 <bblfish> the entry with the diagram started off being only an entry

19:58:59 <bblfish> Then someone posted a reply and it turned into this: http://bblfish.net/work/atom-owl/2004-06-22/entry.2004-05-10.2020.n3

19:59:13 <bitsko> what is the relation between a FeedIsAnEntry and the web resource normally called, a "feed"?

19:59:54 <bblfish> in the UML model you see that Feed subclasses Entry

20:00:10 <bitsko> how about in the interaction model?

20:00:10 <bblfish> Ie a feed has all the same properties as an entry

20:00:28 <bblfish> what do you mean interaction model?

20:00:53 <bitsko> the web accessible resource representation. the URI where a feed can be accessed.

20:01:11 <bblfish> They should be the same.

20:01:17 <bblfish> in N3 they can be the same

20:01:21 <bitsko> even for feeds of feeds?

20:01:43 <bblfish> A feed of feeds is a feed of entries, each entry of which is a feed

20:02:38 <bitsko> but those feeds are not necessarily URI accessible, or if they are (GETable entries), do they include or not include their, uhm, children?

20:03:42 <bblfish> http://bblfish.net/work/atom-owl/2004-06-22/entry.2004-05-10.2020.n3 is an Entry

20:03:49 <bblfish> it is GET able

20:04:05 <bblfish> it points to entry

20:04:07 <bblfish> :entry <entry.2004-05-20.2320.n3> , <entry.2004-05-21.0913.n3> , <entry.2004-05-21.1055.n3> ;

20:04:24 <bblfish> These Entries are GETable, and could each of them be Feeds

20:05:08 <bblfish> The first entry is here: http://bblfish.net/work/atom-owl/2004-06-22/entry.2004-05-20.2320.n3

20:05:09 <bitsko> k, what's the URI that tells me what "all the newly changed resources (Feed, Entry) are"?

20:05:21 <bitsko> and what is that resource called?

20:05:23 <bblfish> It is not a feed, but it could have been, or it could still be

20:06:00 <bblfish> A you want a feed of all changed entries in your set of feeds?

20:06:21 <bblfish> s/A/Ahh/

20:06:43 <bitsko> yes, that is the interaction model for "feeds".

20:06:45 <avk> g'nite all

20:07:35 <bblfish> Mhh. I am sure it can be done.

20:07:49 <bitsko> but, the current model isn't necessarily what I "want". I don't think we need to UML model anything called a "feed" *at all*.

20:08:00 <bblfish> So you have Feed1, Feed2, Feed3

20:08:02 <bblfish> And you want a Feed of the changes in those Feeds?

20:08:37 * quarkie declares update failure and hopes someone can bring him into pace :)

20:08:50 <quarkie> *up to pace, even

20:09:10 <bblfish> Well it is useful to think of a feed.

20:09:14 <quarkie> what's the current topic?

20:09:50 <bitsko> quarkie: FeedIsAnEntry, FeedOfFeeds, and ItsTheEntries

20:09:56 <bblfish> Well bitsko was talking to avk about something which I thought could perhaps be modelled by FeedIsAnEntry

20:10:26 <bblfish> I think I now understand the concept of a Feed of Feeds.

20:10:42 <bblfish> A feed of feeds keeps you updated on the changes to a number of feeds...

20:11:16 <bblfish> so in your feed reader it will alert you of all the new interesting entries in those feeds.

20:11:21 <bblfish> is that rights bitsko?

20:11:22 <bitsko> which segued into defining what a "feed" is and whether that's a useful modelling construct at all

20:12:20 <bblfish> ?

20:12:46 <bitsko> there are three principle interaction models for Atom, of which we've really only focused on two: what RSS currently does, and are called "feeds"; the Atom API; and Archives (the one we haven't talked about)

20:13:20 <quarkie> ok, thanks for the summary

20:13:23 <bitsko> RSS feeds are a web accessible resource that lists the most recently changed items within the provenance of that feed

20:13:38 <bblfish> ok

20:13:40 <quarkie> did you discuss anything about 'parent' versus 'in-reply-to'?

20:13:42 <bblfish> I can model that

20:14:02 <bitsko> RSS feeds have some bookkeeping information that indicates who runs the feed, the last time it was changed, and some default parameters that are used by all items within the feed.

20:14:25 <bblfish> ok. Some of that is not needed

20:16:25 <bblfish> quarkie: we may come to that parent vers 'in-reply-to'. Just wainting to understand what bitsko is coming up with.

20:16:36 <bitsko> quarkie: we were, http://www.ilrt.bris.ac.uk/discovery/chatlogs/atom/2004-06-22.html#T19-10-43

20:17:57 <bblfish> what are feeds of feeds then bitsko?

20:17:59 <bitsko> later, RSS feeds (the files, not necessarily the UML entity) were created to capture comment feeds. each entry would link to an RSS file that contained the comments for that entry (wfw:commentRss). These comments are "flat" (afaik)

20:18:46 <bblfish> ok. My model deals with that better. Since an Entry can turn into a feed. No need for another entity

20:18:57 <bitsko> In other cases, Feeds (the files) are used to provide "recently changed" information according to topics, or categories

20:19:23 <bblfish> ok. That's just a specialised feed.

20:19:27 <bitsko> where there's the possibility of having both a "main feed" (all entries) and "category feeds" (specific entries)

20:19:55 <bblfish> ok. So we have feeds that speak about the same entries.

20:19:57 <bitsko> recently, we have the addition of "side feeds", including link logs and photoblogs

20:20:14 <bblfish> That is kind of new to me.

20:20:45 <bblfish> Are those not just feeds pointing to say different types of entries?

20:20:56 <bitsko> the original idea for "Feed of Feeds" was to be able to take all these various feeds and put them in one file, so that clients would only have to poll one web resource to get changes from them all

20:21:13 <bblfish> Ok.

20:21:55 <bitsko> bblfish: the side feeds aren't necessarily different "types" of entries so much as they are "lesser scoped" than, say, the "main feed"

20:22:06 <bblfish> So what we want is a number of feeds all pointing to different sets of the same entries.

20:22:14 <bblfish> Ok.

20:22:17 <bitsko> often there's a good correlation between a feed file and a digest web paeg

20:22:35 <bblfish> You mean you want less info about each entry in those feeds?

20:22:40 <bitsko> a digest web page being the one with a series of entries on it, as opposed to a single entry's web page

20:23:30 * bitsko was most rambling along there in one stream and apologizes to bblfish for not really replying point-by-point

20:23:57 <bblfish> I was just ok ing what you said mostly

20:24:12 <bblfish> Can I recapitulate?

20:24:19 <bitsko> what I think is that a "feed" as a UML modeled entity has completely lost its purpose, particularly with respect to the current interaction modeled uses of feeds.

20:24:42 <bblfish> I understand.

20:24:48 * bblfish I think

20:24:56 <bitsko> and that the current interaction modeled uses of feeds is based almost entirely on an "archaic" implementation use-case

20:25:05 <bblfish> ok bitsko.

20:25:18 <bblfish> why is that?

20:25:42 <bblfish> Is that because the feed as currently defined requires a lot more information than you want?

20:25:46 <bitsko> because we've had a rich model of independent entries.

20:25:50 <bblfish> ok

20:25:54 <bitsko> never had

20:26:15 <bblfish> Now the nice thing is that in N3, you can put as much info about the entries in a feed as you want.

20:27:01 <bblfish> In my example I only currently point to the name of the entries

20:27:03 <bblfish> :entry <entry.2004-05-20.2320.n3> , <entry.2004-05-21.0913.n3> , <entry.2004-05-21.1055.n3> ;

20:27:21 <bblfish> I could of course also give the title, and the sumary.

20:27:33 <bblfish> But I did not. Yet it is still good N3.

20:27:44 <bitsko> understood

20:27:54 <bblfish> If the feed reader wants more info about the feed he can just resolve those urls

20:28:02 <bblfish> sorry

20:28:08 <bitsko> you mean about the entries, no?

20:28:11 <bblfish> If the feed reader wants more info about the entries he can just resolve those urls

20:28:13 <bblfish> yes

20:28:36 <bblfish> Does that solve the problem?

20:29:22 <bblfish> eg. the first entry has all its content at this location: http://bblfish.net/work/atom-owl/2004-06-22/entry.2004-05-20.2320.n3

20:29:57 <bitsko> have you considered a model where there are no feeds, only entries?

20:30:11 <bblfish> Well what I have is pretty much that.

20:31:00 <bblfish> It just helps with the semantics a little to have a distinction. Not the only one mind you. Perhaps an entry can be subclassed in other ways...

20:31:49 <bblfish> In fact all a feed gives you is the ability to use a certain named pointer to another entry. You could put that in the Entry too of course

20:31:51 <bitsko> if I see the example correctly, the entries are forward-chained rather than backward-chained. that is to say, an entry tells you what "its entries are", rather than the child entries saying what their parent is. correct?

20:31:57 <bblfish> And then there would be no distintion

20:32:19 <bblfish> Correct. I have not implemented any backward chainging yet.

20:32:27 <bblfish> That was on my todo list.

20:33:32 <bitsko> and of course, an entry can appear in multiple category feeds (forward or backward).

20:33:48 <bitsko> how will this look in Atom XML?

20:34:06 <bblfish> But it is easy in some way. I could just add the

20:34:08 <bblfish> entry.2004-05-10.2020.n3 :Entry <>

20:34:09 <bblfish> in the Entry <entry.2004-05-20.2320.n3>

20:34:42 <bblfish> sorry that should be

20:34:44 <bblfish> <entry.2004-05-10.2020.n3> :Entry <>

20:35:06 <bblfish> where <entry.2004-05-10.2020.n3> is the Entry that turned into a feed

20:35:18 <bblfish> how to turn this into Atom XML :-)

20:35:32 <bblfish> That is a good question

20:36:41 <bblfish> But if we agree that this would satisfy you, then at least we know one thing.

20:37:12 <bblfish> Then the question would be how to move on to get this done in Atom. But we would know what we are speaking about.

20:37:30 <bitsko> by comparison, when I think of a model of only entries, everything is done with back-chaining. logically, of course, the forward chain could be constructed, but for the most part back-chaining handles all the work of indicating parents, categories, which stream of entries (nee feed)

20:38:03 <bblfish> if you think in terms of RDF triples. It does not matter where you put your facts.

20:38:04 <bitsko> an Atom feed is just <feed><entry><entry><entry><entry></feed>

20:38:25 <bblfish> Think

20:38:26 <bblfish> John --fatherOf-->Mark

20:38:42 <bblfish> is that backward chaining or forward chainging?

20:38:49 <bitsko> forward chaining.

20:38:59 <bitsko> you're adding a property to the source subject.

20:39:13 <rubys> an Atom feed is just <feed><entry/><entry/><entry/><entry/></feed>

20:39:25 <bblfish> if you know who Mark is but don't know who the father is you can go from Mark to John using that sentence

20:39:41 <bitsko> bblfish: yes, the logic is fine.

20:39:48 <bblfish> Iok :-)

20:40:10 * bitsko thought about mentioning to ignore his pseudo-XML ;)

20:40:33 * rubys mutters about damn liberals

20:40:34 <bblfish> yes. Perhaps it Atom it would be better to get rid of the feed construct...

20:41:01 <bitsko> I'm talking more about physical access. it's easy for a "new" entry at a new URL to back-link to all the resources it wants to.

20:41:47 <bitsko> it is... inefficient... to have to update all the resources that exist elsewhere to forward-chain to the new resource.

20:42:02 <bblfish> Since an Entry could be part of an infinte number of feeds, surely you don't want the entry to point back to all of them?

20:42:09 <bitsko> I don't mean "database" inefficient. an RDF store has no problem with it, of course

20:42:38 <bitsko> but suddenly, the resources at all the other URLs have changed, have been <modified>

20:43:37 <bitsko> aha! that's where the schism is between a physical feed and a logical "something else"

20:44:18 <bblfish> have you just had a new idea?

20:44:58 <bitsko> no, it's the first mention that's been made in this discussion.

20:45:14 <bblfish> What does the Aha refere to?

20:45:32 <bitsko> "exactly!"

20:45:56 <bblfish> I mean what was your thought when you excalimed "aha!"?

20:45:56 <bitsko> <bblfish> Since an Entry could be part of an infinte number of feeds, surely you don't want the entry to point back to all of them?

20:45:59 <bitsko> exactly!

20:46:04 <bblfish> ok

20:46:53 <bitsko> that's what distinguishes a physical feed from some logical relationship between entries that is not being properly modeled yet. it's *not* "feeds"

20:47:13 <bblfish> does that change your position or mine? I am not sure it is a thought that just occurred to me?

20:47:24 <bitsko> maybe it's "site", maybe it's "category", maybe it's "author".

20:47:27 <bblfish> s/?$/./

20:47:47 <bitsko> it's a data point that I hope to change your position.

20:47:58 <bblfish> that should be s/\?$/\./

20:48:02 <bitsko> :)

20:48:18 <bblfish> :-)

20:48:50 <bblfish> yes. It does make backward chaining difficult.

20:49:15 <bblfish> You can always backward chain to your parent entry/feed.

20:49:24 <bblfish> but not to all the other.

20:49:43 <bitsko> infinite feeds doesn't make backward chaining difficult, because I'm not suggesting backlinking to any kind of physical feed.

20:50:11 <bitsko> infinite feeds are derived from properties of individual entries.

20:50:16 <bblfish> what is your suggestion then. I am not sure I know.

20:50:57 <bitsko> and by infinite feeds I mean in the pubsub.com sense, where synthesized feeds are created from various sources.

20:51:41 <bitsko> my hope is that we can reduce the number of physical feeds that sites must publish.

20:52:12 * bblfish need to look at pubsub.com

20:54:27 <bitsko> I'm suggesting that if entries were more independent, they could more easily be: 1) super-aggregated into synthesized feeds, 2) be available at their own URLs, 3) be able to make references to other entries without those other entries having to be modified to refer to them.

20:54:46 <bblfish> Ah ok.

20:55:09 <bblfish> +10 for making Entries independent. I do that in my example. They have their own uris.

20:55:38 <bitsko> there's also the case where an entry on my site refers to an entry on your site. I couldn't "forward chain" from your site to mine even if I wanted to.

20:56:06 <bblfish> but my entry could become part of your feed/entry :-)

20:56:43 <bblfish> My model already works like that.

20:57:00 <bitsko> right, I think when you're saying "FeedIsAnEntry" you are also taking what is conceptually thought of as "feed information" and putting it into the entry, which aids in making the entry independent. for that, I'm suggesting we can lose the legacy bit about "feed"

20:57:49 <bblfish> yes. In my N3 model the Feed does no harm

20:58:06 <bitsko> except clutter the model?

20:58:14 <bblfish> in Atom XML as it currently is, it is a burden

20:58:18 <bblfish> oh that is true

20:58:38 <bblfish> it clutters the model a little. But no great harm.

20:59:24 * bblfish if we go on simplifying at this pace, we are going to be left with very little :-)

20:59:32 <bitsko> woot!

20:59:43 <bblfish> woot?

21:00:03 <bblfish> what does "woot" mean? is that an ircism?

21:00:25 <bitsko>http://www.urbandictionary.com/define.php?term=woot

21:00:53 <bblfish> :-)

21:00:55 <bitsko> "To emphasize something, be happy."

21:01:11 <bblfish> bookmarked

21:01:50 <bblfish> this whole thing is fun. It is amusing how simple blogs are.

21:01:52 <bitsko> so where this fits with parent and in-reply-to, both parent and in-reply-to are the back-links from children to parents.

21:02:36 <bblfish> yes. good I understand. I am behind the no more feeds in Atom. Count me in.

21:02:51 <bblfish> (I can keep them in my N3 model though hehe)

21:03:17 <bitsko> my beef is that in-reply-to is a child to parent relationship but not all child to parent relationships are replies.

21:03:32 <bblfish> ok

21:04:07 * bitsko wakes quarkie

21:04:24 <bblfish> what about just simply <link src=urltoanentry>

21:04:45 <bitsko> what's that?

21:05:01 <bblfish> entries can have links to other entries

21:05:18 <bblfish> these are the links we think of as feeds having to their entries

21:06:23 <bblfish> The problem I suppose is that people don't want to download an entry with a huge number of links to other entries

21:06:41 <bitsko> would there be more than one?

21:06:59 <bblfish> oh. I see

21:07:19 <bblfish> The problem is how do you find the new entries?

21:07:45 <bitsko> finding new entries is easy, that's what physical feeds do ;)

21:07:58 <bblfish> Ah so you still have feeds...

21:08:34 <bblfish> I thought you wanted no feeds.

21:09:06 <bitsko> no, just no logical feeds.

21:09:59 <bblfish> what is a logical feed? A feed that has entries than don't recognise it as their parent?

21:11:39 <bblfish> or is your feed just a list of links?

21:11:54 <bblfish> your feed != logical feed

21:12:40 <bitsko> todays feeds have a loose correspondence to their web browser representation. the "front page" corresponds to the "main feed", each category page has a feed, each entry has a feed of comments, each side blog has a feed. that's a lot of physical feeds to poll to find out when entries change.

21:13:09 <bblfish> yep

21:13:32 <bblfish> and how would your feed solve that?

21:13:36 <bitsko> if one were to merge all those physical feeds into, say, one main feed, is it still a group of "logical feeds", or is it really something else we've never thought to name and model?

21:14:01 <bblfish> mmh. My thought is you can have both.

21:14:25 <bblfish> A site can have a feed that contains just pointers to all the entries on the site

21:14:29 <bitsko> you can have both. there's good reason to have a physical category feed if you're only interested in those category entries.

21:14:43 <bitsko> for example

21:14:55 <bblfish> yes.

21:15:48 <bblfish> So you want

21:15:50 <bblfish> 1. Entries to have their url

21:15:51 <bblfish> 2. Feeds to point to those url

21:15:53 <bblfish> 3. A meta feed that points to all the entries on a site.

21:15:58 <bitsko> taking comments as an easy one, it's really easy to have a single comments physical feed, and have each of those comments have in-reply-to links to their parent comments and entries

21:16:11 <bblfish> yes.

21:17:10 <bitsko> 1 and 2 are optimizations that can be considered separetly from 3. 1 and 2 are PaceSimplifiedFeedFormat

21:17:37 <bitsko> actually, 2 is PaceSimplifiedFeedFormat and 1 is "GETable entries", which has no Pace yet.

21:17:48 <bitsko> but you need 1 for 2

21:17:53 <bblfish> there should be a Pace for that

21:18:00 <bblfish> yes

21:18:16 <bblfish> so the most important Pace is GETableEntries

21:18:51 <bitsko> re 3, I'm not all that concerned about how many feeds there really are, 1, 2, 5, many. I figure I'll likely just have to suck them all in to create a pool of entries.

21:19:21 <bblfish> ok.

21:19:55 <bblfish> Do we then agree?

21:20:07 <bitsko> I'll note, however, that once you have 1 and 2, there's no reason for more than one feed if it's the entries themselves can "arrange themselves"

21:20:29 <bblfish> ah.

21:21:09 <bblfish> Well it can help if you only want to listen to responses to your entry...

21:21:32 <bblfish> But then again my feed is an entry works out nicely, because I can poll my entry as a feed

21:22:11 <bblfish> s/as a feed/as if it were a feed/

21:22:47 <bblfish> But I think we are onto something.

21:22:54 <bblfish> And I think I have the solution.

21:23:19 <bblfish> Let me show you how it is done again in my example.

21:23:48 <bblfish> This is my main feed: http://bblfish.net/work/atom-owl/2004-06-22/feed.bblfish.n3

21:23:56 <bblfish> (It is an entry too as you know)

21:24:47 <bblfish> it has a list of links to its entries.

21:24:49 <bblfish> and when those get to be too long it also can have a link to another file

21:24:50 <bblfish> :link [ a :Link ;

21:24:52 <bblfish> :href "feed.bblfish.older.n3" ;

21:24:53 <bblfish> :rel "next" ;

21:24:55 <bblfish> :type "application/n3"

21:24:56 <bblfish> ] ;

21:25:01 <bblfish> (that is ugly btw, not good N3, but nevermind)

21:25:30 <bblfish> if you look at http://bblfish.net/work/atom-owl/2004-06-22/feed.bblfish.older.n3

21:25:56 <sbp> s/:href "feed.bblfish.older.n3"/:href <feed.bblfish.older.n3>/

21:26:03 <bblfish> you will see that unlike a the other files it does not start with <>

21:26:28 <bblfish> but points back to its original entry

21:26:29 <bblfish> <feed.bblfish.n3>

21:26:31 <bblfish> a :Feed , :Entry ;

21:26:56 <bblfish> If you can come up with simple xml syntax for the RDF phobic to do that you have solved your problem

21:26:59 <sbp> bblfish: same with ":url"'s object too

21:27:11 <bblfish> yes. will do that next.

21:27:24 <bblfish> bitsko: does that make sense?

21:28:19 <bblfish> So this is how you can have Atom where there are only entries.

21:29:01 <bblfish> thanks sbp. I need to remodel that thing.

21:29:50 <bblfish> bitsko: you still here?

21:29:59 <bitsko> the site summary makes sense, yes, that's just like how it's been proposed for Atom XML, too.

21:30:34 <bblfish> Do you think that solves your problem?

21:30:36 <bitsko> then just applying the same thing about what we said about feed <-> entry

21:31:21 <bblfish> if a feed is going to be an entry, then there has to be a way to store away the older links that people don't want to download when they subscribe to a feed.

21:31:44 <bitsko> yes, that part's already been working ;)

21:31:55 <bblfish> how?

21:32:17 <bblfish> not in atom, since in atom currently there is a well distinguished feed object

21:32:33 <bitsko> http://intertwingly.net/wiki/pie/LinkTagMeaning defines "prev" for linking back to archive feeds, for example

21:33:22 <bitsko> there's a very good description of this use case somewhere, but I don't recall where. rubys?

21:34:59 <bitsko> the example is that you can have a "dynamic" current feed that lists, say, the last 24 hours of changes (because clients poll every hour usually), and then have that feed link to pretty-much static feed for, say, the last month's entries. that feed would link back to the previous month.

21:35:43 <bitsko> so every archive or site summary feed is static, which is an immense boon for caching HTTP servers and such.

21:36:34 <bitsko> our (1) and (2) cases above (PaceSimplifiedFeedFormat) could make those files smaller while also making their entries individually available at their own URL.

21:37:17 <bblfish> ah yes.

21:37:45 <rubys> I don't recall the use case description, but:

21:38:03 <bitsko> ah, another note on back-linking instead of forward-linking, that includes HTTP caching. with forward-links you have to have a fairly short expiry time on then entry, where with backward-links published entries are fairly static.

21:38:16 <rubys> I could easily imagine organizing all of my entries into weekly (or monthy) archives, and having a single feed which points back to history...

21:38:24 <rubys> follow the linked list, and you have my entire weblog.

21:38:40 <bblfish> good idea.

21:39:07 <bitsko> ah, I thought it was written up somewhere

21:39:16 <rubys> might have been

21:39:35 <bitsko> in any case, prev/next on LinkTagMeaning capture that use-case

21:40:09 <bblfish> I got it.

21:40:37 <bblfish> So again the most important thing in all of this is PaceGETAbleEntries

21:42:03 <bblfish> is that a good conlcusion to come to?

21:42:38 <bitsko> checking...

21:43:56 <bblfish> PaceGETAbleEntries also make good RESTful sense

21:44:41 <bitsko> I think the more important aspect is independent entries, http://imc.org/atom-syntax/mail-archive/msg04596.html

21:44:54 <bitsko> whether or not they are individually retrievable

21:45:47 <bblfish> Are they not two sides of the same coin?

21:45:50 <bitsko> independent here meaning that you could have every single entry (main, comment, link blog, photo blog) appear between the <feed> and </feed> and have them make sense relative to each other.

21:47:43 <bitsko> no, independent entries is the one that unties the data in the entry from the data in the feed (no more implied inheritance)

21:47:57 <bitsko> author, copyright, blog-title

21:48:34 <bblfish> Well the easiest and surest way of making entries independent is to give each one of them its own url

21:48:54 <bitsko> that would seem to make the issue more obvious, yes ;)

21:49:34 <bblfish> and obvious I think is good if you want people to follow without thinking, which the masses are prone to do :-)

21:49:49 <bitsko> but even if entries were not wholly independent, they could be superaggregated and live at their own URL and then link back to their "home" or origin feed. that's the part about not being independent

21:51:01 <bblfish> well nothing on the web is that independent. Things always link up to other things

21:52:24 <bitsko> of course. the "litmus test" for independance here is if the entry can arrive to you in a superaggregated feed, and you can list it in your summary pane without making any additional fetches.

21:53:33 <bblfish> I think it is better if each entry has its own url. The superaggregated feed then is just a large list of pointers to entries.

21:53:47 <bitsko> or viewed from the other end, the only time the entry and its content is fetched is when the user takes an action

21:54:24 <bitsko> (that action may be a preconfiguration of pre-caching content for offline viewing, but that's another use-case)

21:54:32 <bblfish> yes. that is the consequence of what I was puting forward.

21:55:24 <bblfish> Whent the user takes action a GET request for the feed url is made

21:55:36 <bblfish> s/feed url/entry url/

21:55:53 <bblfish> Whent the user takes action a GET request for the entry url is made

21:56:10 <bitsko> the physical feed should contain enough metadata to allow a summary listing pane to be displayed without fetching the entry. This includes author, date(s), title, blog-title, parent (in-reply-to), in addition to the link to the entry.

21:57:30 <bitsko> In NNTP this is called "overview" data. IMAP has a similar feature, iirc.

21:57:31 <bblfish> yes. What should *not* be in the feed?

21:57:41 <bitsko> why, everything else, of course ;)

21:57:53 <bblfish> content, etc...

21:58:00 <bblfish> ok.

21:59:37 <bblfish> I think we have covered this issue quite thoroughly.

22:00:47 <bblfish> I need to put more data in the enties of my example, to make it more compliant with this.

22:00:50 <bitsko> so PaceIndependentEntry is #1, PaceGetableEntries #2, and PaceSimplifiedFeedFormat #3, importance-wise, and more practically, consensus-wise.

22:01:26 <bblfish> yes. Need to read them carefully. Will do that tomorrow.

22:01:41 <bitsko> two of the three don't exist yet ;/

22:02:07 <bitsko> though (2) really is required and implied by (3)

22:02:20 <bblfish> Ah ok.

22:03:08 <bblfish> Are you going to do that. I still have a lot of work on the FeedIsAEntry, which I think can complement all of the above. Just need to find out how to map it to simple XML.

22:03:21 <bblfish>http://www.imc.org/atom-syntax/mail-archive/msg04893.html

22:03:24 <bitsko> (2) is just a clarification of the Atom API spec that the GETable representation of the entry should be publicly available, noting that publishers may filter elements for non-authorized users.

22:03:29 <bblfish> I did a little bit of it there.

22:04:13 <bblfish> yes

22:05:21 <bitsko> yes, I might be able to take one or both of those on, and maybe get (3) restarted.

22:06:05 <bblfish> It is amazing that something as simple as an Atom can create so much work :-/

22:07:56 <bitsko> and a light forewarning about FeedIsAEntry if you continue to use forward-chaining: if those resources get modified unnecessarily, you will get massive amounts of push-back from the HTTP/REST crowd, especially where back-chaining is a suitable alternative.

22:08:59 <bblfish> You also use forward chaining from your feed to your entry no?

22:10:11 <bitsko> it is kept isolated to only the dynamic feeds. think of it as a notification service more than a changing resource.

22:10:41 <bitsko> one of the reasons for linking to previous feeds is specifically to make the previous feeds capable of being static.

22:11:12 <bitsko> static meaning "firm", not forever "frozen".

22:12:39 <bblfish> so how does my feed is a entry change anything?

22:12:47 <bblfish> It is exactly the same

22:13:58 <bitsko> each entry can be a feed that forward chains to its children, yes? that means each entry is its own dynamic feed? an entry from three months ago can change based on a comment posted today?

22:15:15 <bblfish> Yes. If someone today posts a response to the entry from three months ago.

22:16:01 <bblfish> Then that entry will need to be mutated into a feed.

22:16:27 <bitsko> the HTTP/REST folks who might think PaceGetableEntries is a good idea might not be so inclined if those entries are always changing.

22:17:06 <bblfish> Well that is up to the provider. The provider can decide that you cannot post comments onto old entries.

22:17:50 <bitsko> or we can spec back links only, no?

22:19:02 <bblfish> Need to think about that.

22:19:29 <bitsko> I just want you to be aware of this when you go for consensus on FeedIsAEntry, HTTP/REST folks, like me, will drill on this aspect.

22:19:44 <bblfish> Interesting thought.

22:20:29 <bitsko> other HTTP/REST folks might have some more specific references.

22:20:41 <bitsko> I don't have any handy.

22:21:11 <bitsko> I got to run off. great chat! thanks!

22:21:11 <bblfish> There is a point to what you say. I would need to understand how backlins work.

22:21:23 <bblfish> ok. Thanks too.

22:22:46 <bitsko> when we get a chance to chat again, the back-links I'm talking about are like in-reply-to for comments (that's easy), the more abstract and complex one is how entries are categorized.

22:23:12 <bitsko> bitsko is now known as bitsko|away

22:23:26 <bblfish> sounds interesting. I'll try to follow that.Bye.

22:31:38 <bitsko|away> bitsko|away is now known as bitsko

22:33:59 <bitsko> ok, apparently I chatted for too long and now I'm in the dog-house, but I can chat more. :/

23:05:09 <bblfish> Ah well. Its time for me to go to bed.

23:05:49 <bblfish> bitsko: sorry about that.

23:05:59 <bitsko> heh, np

23:06:15 <bblfish> you are at work?

23:06:26 <bitsko> we definitely had enough to talk and think about

23:06:32 <bitsko> I'm between jobs at the moment

23:06:38 <bitsko> hence all the activity

23:06:42 <bblfish> same with me.

23:06:45 <bblfish> :-)

23:07:08 <bblfish> Well. I think that last point was very well made.

23:07:28 <bblfish> I think that is a very good point agains FeedIsAEntry

23:09:58 <bblfish> It is 1am here for me. So thanks again for the conversation. Gotta go.

23:10:06 <bitsko> g'nite