# Base: http://bblfish.net/work/atom-owl/2004-08-12/ @prefix xsd: . @prefix rdf: . @prefix foaf: . @prefix : . :entry-location . a :Entry ; :alternate [ a :Link ; :href ; :mime-type "text/html"^^xsd:string ; :text "html blog entry"^^xsd:string ] ; :author [ a foaf:Person ; foaf:homepage ; foaf:mbox ; foaf:name "H. Story"^^xsd:string ] ; :content [ a :Content ; :data """To start off let us look at the feed files. There are two sets of these files:

feed.n3, which is the head of the feed, the dynamic file that changes whenever a new entry is added to the blog. This is the file that blog readers will be polling every so often.
feed-entries_0_to_3.n3, feed-entries_x_to_y.n3,... each of which is an archive of older feed entries. These files SHOULD NOT change, making them prime candidates for cacheing.

Each of these files is a part of the whole result. I don't yet have a concept yet the union of all the content in these files. This may be something that needs adding. Each file points to the previous results with code such as

    <>   :previous
              [ a       :Link ;
                :href   <feed-entries_0_to_3.n3> ;
                :mime-type \"application/rdf+n3\"^^xsd:string ;
                :text   \"previous 4 entries\"^^xsd:string 
              ] .

which says that the previous entries can be found at the resource <feed-entries_0_to_3.n3>. <feed-entries_0_to_3.n3> itself points to the dynamic element of the feed thus

  <>   a       :Feed ;
      :about  <blog.n3> ;
      :dynamic <feed.n3> ;

which points to the dynamic part of the feed. It also points to the blog file that contains the so called 'introspection' information about the blog: namely where the url for adding new entries is located, and other things which I know are not yet fully thought through.

Notice: The current feeds contain very little information. They point to the entries themselves. feed.n3 for example points to four (only four for illustrative purposes) entries as shown here:

<>    a       :Feed ;
      :dynamic <> ;
      :entry  <entry.2004-08-13-1047.n3> , <entry.2004-08-13-1445.n3> ,
               <entry.2004-08-13-1752.n3> , <entry.2004-08-13-1632.n3> ;

To help clients tell which entries they have or have not downloaded we can add further information such as the EntryID and the EntryVersion of each of these entries. That is done further down in the feed.n3 file:

<entry.2004-08-13-1047.n3>
      :entry-version <tag:bblfish.net/20040813/1047/blog1#version1> ;
      :id     <tag:bblfish.net/20040813/1047/blog1> .

<entry.2004-08-13-1445.n3>
      :entry-version <tag:bblfish.net/20040813/1445/blog1#version1> ;
      :id     <tag:bblfish.net/20040813/1445/blog1> .

Clearly a lot more could be added. One could add the title (an obvious addition), perhaps the publication date, the last changed date... One could of course add everything, as with the AllInOneDatabase.n3, but that would be extreemely wasteful in bandwidth and very un-RESTful. What to add and not to add is really an empirical research topic. Having very little information is not really a problem. As long as the client can determine where the entries are and which entries it allready has fetched (hence the entry-version field) it will only need to fetch the content once. With HTTP 1.1 Persistent Connections, having to make multiple requests is not at all a problem. """^^xsd:string ; :mime-type "text/html"^^xsd:string ] ; :copyright ; :created "2004-08-13T10:47:00+0200"^^xsd:dateTime ; :entry-version ; :id ; :in-reply-to ; :title [ a :Content ; :data "N3 illustration - The Feed"^^xsd:string ; :mime-type "text/simple"^^xsd:string ] .