Using Atom/AtomPub for OpenBookmarks
Hadrien Gardeur
First of all, I'm 100% against the suggested format. If we take the XML route, using Atom is much more suited to build a proper protocol where we can properly define and potentially extend things and if we don't, then JSON is a better idea.
I could list dozens of reason why we should use Atom rather than our own XML namespace, but I'll just list a few of them:
- Atom is widely supported with libraries for any modern language, and support for tons of clients. Any browser can display Atom just fine
- Atom is designed to be easily extensible (namespaces, rel values) and since we're going to do a lot of CRUD stuff with OpenBookmark, we can also rely on AtomPub for these interactions
- Excellent overall design decisions, forcing devs to adopt best practices even if they don't understand why they're important
- The container can either be a feed or an entry in Atom, which means that we can distribute individual annotations as easily as a list of annotations
- We can roll our own namespace and rel values when we need them, and rely on widely supported namespaces like DublinCore for the rest
- OPDS (Open Publication Distribution System) is based on Atom and widely supported by the reading systems that are the most likely to support OpenBookmark too (Ibis, Aldiko, BookGlutton). We could easily add support for OpenBookmark in OPDS catalogs if we use Atom/AtomPub for it
- Some of the best examples of properly designed API are in Atom (GData) with a JSON serialization. We should do the same and support both Atom and JSON
- OpenBookmark will be a decentralized protocol and for such protocols, we'll need links with proper mimetypes and relationship values to know how to interact with a service. Atom is designed exactly for such interactions thanks to atom:link
Before we start any work, we also need to study existing technologies.
For example, Adobe has its own format for storing notes locally. Here's an example:
<annotationSet xmlns:xhtml="http://www.w3.org/1999/xhtml" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns="http://ns.adobe.com/digitaleditions/annotations"> <publication> <dc:title>Halting State</dc:title> <dc:creator>Charles Stross</dc:creator> <dc:publisher>Ace</dc:publisher> </publication> <annotation> <dc:identifier>urn:uuid:3F9CA06F-FEEB-2B9B-626E-39CAAF04FA7D</dc:identifier> <dc:date>2010-12-31T00:19:00-00:00</dc:date> <dc:creator>urn:uuid:ec29cb8e-a4dd-4f41-9fe2-dacf6b4299ad</dc:creator> <target> <fragment start="OEBPS/haltingstate_ch12.html#point(/1/2/1/2/1/1/1)" end="OEBPS/haltingstate_ch12.html#point(/1/2/1/2/1/1/1:57)"/> </target> <content> <dc:date>2010-12-31T00:19:05-00:00</dc:date> <text>Test</text> </content> </annotation> </annotationSet>
The IDPF is also working on a format that will enable users to link to EPUB books and we can probably learn a lot or contribute to this effort: http://code.google.com/p/epub-revision/wiki/LinkingImplementationProposals
Before providing an alternative example, just a few more points that I'd like to discuss.
Most of the metadata defined in the current example (title, author, isbn, id) are media specific (if we'd like to support annotations in video, we won't use the same set of metadata) and already exists in other namespaces (DublinCore for example). I don't believe that it should be the responsability of this working group to define such things.
How we point to the start and the end of an annotation is also media specific and we shouldn't be the one defining such things (for EPUB, the EPUB WG is working on a Linking spec).
What we should be working on is how we actually interact with these annotations (autodiscovery and the full CRUD - Create, Read, Update, Delete - operations), and serialize such a protocol in Atom/JSON/RDF. Atom/AtomPub provide a perfect framework for such a protocol, and the only extra things required would be a few relationship values, how we identify an OpenBookmark resource (we need a mimetype) and maybe a few atom:categories.
Based on the EPUB Linking proposal, here's a very basic example of how this could work in Atom/AtomPub:
<entry xmlns:dcterms="http://purl.org/dc/terms/" xmlns="http://www.w3.org/2005/Atom"> <title>Annotation</title> <id>urn:uuid:ec29cb8e-a4dd-4f41-9fe2-dacf6b4299ad</id> <updated>2010-11-29T11:28:14Z</updated> <content type="text">Text of the annotation</content> <link rel="http://www.openbookmarks.org/annotation/start" type="application/epub+zip" href="http://purl.idpf.org/0132366991?file=%2FOEBPS%2FePub-STTP-4.xhtml&fragment-id=toc-anchor-4&text=text+before+annotation" /> <link rel="http://www.openbookmarks.org/annotation/end" type="application/epub+zip" href="http://purl.idpf.org/0132366991?file=%2FOEBPS%2FePub-STTP-4.xhtml&fragment-id=toc-anchor-4&text=text+after+annotation" /> <link rel="edit" href="/annotation/1" /> </entry>
In this (very) basic example, we have:
- the annotation itself (atom:content)
- the start and the end of where we added a note (two atom:link, since they both point to an EPUB, we use the IDPF linking style)
- a link where we can edit (PUT) or delete (DELETE) the annotation (atom:link using an edit relationship value)
- a title and a date where the resource was last updated (we could also include the date when the resource was first created, but Atom only requires the timestamp for the last update)
The only thing that doesn't already exist in another spec for this example are the two relationship values that define the start and the end of the annotation.
Using this example we could then make more advanced examples where we would also include such things as metadata about the book (DublinCore), or the location of the user (geoRSS) for example.
Hadrien
stml
Open Bookmarks format. It's intended to get the ball rolling, and it
has. Good.
Thanks very much for this Hadrien. I know a lot less about Atom than I
do about XML and JSON, so I'd like to hear some more for and against
arguments if people have them. That said, Atom with JSON serialisation
seems like a good fit.
The Adobe example is a good one. I've added it to
http://wiki.openbookmarks.org/Similar_Examples and would appreciate
others doing the same with any examples you have, so we can build up a
library of these.
I'm not entirely sure about your argument against the media-specific
metadata. The metadata here - author, title etc - isn't meant to be
definitive, in the sense that it shouldn't be the main thing used to
determine the provenance of the bookmark - but it is a fallback, and
it makes the annotations more human-readable. I think this is
important: one of the reasons for Open Bookmarks is to make a system a
little looser and more flexible, more deployable and more easily
developed and understood than some of the more academic systems you're
referencing. It's not about video or other media.
I think we absolutely do need to be defining things like how we point
to text: the whole point is to do something that's not media-specific,
and not epub-specific. We want this to work on Kindle, for example.
If I understand your post correctly, you're advocating CRUD over
defining things. I think this is the wrong way round. We're defining a
way of sharing annotations: its ereader vendors, websites, archives
and so on who will do the CRUD.
A really important point with your example: we can't just use the IDPF
linking style, because how then would we import this bookmark into,
say, a Kindle? I'm also not sure - but am happy to be enlightened -
why editing/deleting annotations is such a central concern?
James
On Jan 3, 10:42 pm, Hadrien Gardeur <hadrien.gard...@feedbooks.com>
wrote:
>
> Most of this message was previously posted on the Wiki as a comment about
> the suggested BXML format:http://wiki.openbookmarks.org/Talk:Bookmark_Exchange_Format
>
> First of all, I'm 100% against the suggested format. If we take the XML
> route, using Atom is much more suited to build a proper protocol where we
> can properly define and potentially extend things and if we don't, then JSON
> is a better idea.
>
> I could list dozens of reason why we should use Atom rather than our own XML
> namespace, but I'll just list a few of them:
>
> rely on AtomPub for these interactions
> annotations
> OpenBookmark too (Ibis, Aldiko, BookGlutton). We could easily add support
> for OpenBookmark in OPDS catalogs if we use Atom/AtomPub for it
> JSON
> Before providing an alternative example, just a few more points that I'd
> like to discuss.
>
> Most of the metadata defined in the current example (title, author, isbn,
> id) are media specific (if we'd like to support annotations in video, we
> won't use the same set of metadata) and already exists in other namespaces
> (DublinCore for example). I don't believe that it should be the
> responsability of this working group to define such things.
>
> How we point to the start and the end of an annotation is also media
> specific and we shouldn't be the one defining such things (for EPUB, the
> EPUB WG is working on a Linking spec).
>
> What we should be working on is how we actually interact with these
> annotations (autodiscovery and the full CRUD - Create, Read, Update, Delete
> - operations), and serialize such a protocol in Atom/JSON/RDF. Atom/AtomPub
> provide a perfect framework for such a protocol, and the only extra things
> required would be a few relationship values, how we identify an OpenBookmark
> resource (we need a mimetype) and maybe a few atom:categories.
>
> Based on the EPUB Linking
>
> <entry xmlns:dcterms="http://purl.org/dc/terms/"
> xmlns="http://www.w3.org/2005/Atom">
> <title>Annotation</title>
> <id>urn:uuid:ec29cb8e-a4dd-4f41-9fe2-dacf6b4299ad</id>
> <updated>2010-11-29T11:28:14Z</updated>
> <content type="text">Text of the annotation</content>
> <link rel="http://www.openbookmarks.org/annotation/start"
> type="application/epub+zip"
> href="http://purl.idpf.org/0132366991?file=%2FOEBPS%2FePub-STTP-4.xhtml&fra..."/>
> </entry>
>
> In this (very) basic example, we have:
>
> - the start and the end of where we added a note (two atom:link, since
Dave Pawson
>
> Thanks very much for this Hadrien. I know a lot less about Atom than I
> do about XML and JSON, so I'd like to hear some more for and against
> arguments if people have them. That said, Atom with JSON serialisation
> seems like a good fit.
-1 on json, but it could be derived quite easily if the xml is
carefully designed.
Atom IMHO isn't a good fit. The plus side, atom (or any other XML
wrapper) could carry bm's, same way I use it to carry my blog
content.
Only a part of the metadata would match. Atom has
nothing directly of relevance within the carried content.
If we want dublin core, use it, no need to ride on atom for that.
Use of namespaces seems redundant, especially if json
support is sought.
> I'm not entirely sure about your argument against the media-specific
> metadata. The metadata here - author, title etc - isn't meant to be
> definitive, in the sense that it shouldn't be the main thing used to
> determine the provenance of the bookmark - but it is a fallback, and
> it makes the annotations more human-readable. I think this is
> important: one of the reasons for Open Bookmarks is to make a system a
> little looser and more flexible, more deployable and more easily
> developed and understood than some of the more academic systems you're
> referencing. It's not about video or other media.
Step back a little and put a bookmark alongside a book definition
with full set of metadata? Which metadata belongs where?
Book information IMHO belongs with the book, not a bookmark.
Simply xref the Book info in some catalog.
The media, on the other hand, is very relevant, in fact I'd go
so far as to say it isn't even metadata, rather prime bm content.
>
> I think we absolutely do need to be defining things like how we point
> to text: the whole point is to do something that's not media-specific,
> and not epub-specific. We want this to work on Kindle, for example.
Perhaps steal some of the work done for xlink?
http://www.w3.org/TR/xlink11/
>
> If I understand your post correctly, you're advocating CRUD over
> defining things. I think this is the wrong way round. We're defining a
> way of sharing annotations: its ereader vendors, websites, archives
> and so on who will do the CRUD.
+1. What you do with the data is a higher layer. First define the data.
>
> A really important point with your example: we can't just use the IDPF
> linking style, because how then would we import this bookmark into,
> say, a Kindle? I'm also not sure - but am happy to be enlightened -
> why editing/deleting annotations is such a central concern?
How about out of scope? What is done with the data includes editing,
moving, searchig, but other than for use-cases seems out of scope?
Just my 2cents
--
Dave Pawson
XSLT XSL-FO FAQ.
Docbook FAQ.
http://www.dpawson.co.uk
Hadrien Gardeur
Thanks very much for this Hadrien. I know a lot less about Atom than I
do about XML and JSON, so I'd like to hear some more for and against
arguments if people have them. That said, Atom with JSON serialisation
seems like a good fit.
The Adobe example is a good one. I've added it to
http://wiki.openbookmarks.org/Similar_Examples and would appreciate
others doing the same with any examples you have, so we can build up a
library of these.
I'm not entirely sure about your argument against the media-specific
metadata. The metadata here - author, title etc - isn't meant to be
definitive, in the sense that it shouldn't be the main thing used to
determine the provenance of the bookmark - but it is a fallback, and
it makes the annotations more human-readable. I think this is
important: one of the reasons for Open Bookmarks is to make a system a
little looser and more flexible, more deployable and more easily
developed and understood than some of the more academic systems you're
referencing. It's not about video or other media.
I think we absolutely do need to be defining things like how we point
to text: the whole point is to do something that's not media-specific,
and not epub-specific. We want this to work on Kindle, for example.
If I understand your post correctly, you're advocating CRUD over
defining things. I think this is the wrong way round. We're defining a
way of sharing annotations: its ereader vendors, websites, archives
and so on who will do the CRUD.
A really important point with your example: we can't just use the IDPF
linking style, because how then would we import this bookmark into,
say, a Kindle? I'm also not sure - but am happy to be enlightened -
why editing/deleting annotations is such a central concern?
Dave Pawson
why can't we list required/optional content?
It's only a few minutes work to define a schema given
such a listing, then the debate over syntax and semantics
will actually have some meaning.
HTH
Hadrien Gardeur
Rather than argue over adopting X format,
why can't we list required/optional content?
It's only a few minutes work to define a schema given
such a listing, then the debate over syntax and semantics
will actually have some meaning.
- link to the start of the annotation (mimetype + href + rel)
- link to the end of the annotation (mimetype + href + rel)
- text of the annotation
- timestamps
- optionally, a few categories that we would define
Hadrien Gardeur
-1 on json, but it could be derived quite easily if the xml is
carefully designed.
Atom IMHO isn't a good fit. The plus side, atom (or any other XML
wrapper) could carry bm's, same way I use it to carry my blog
content.
Only a part of the metadata would match. Atom has
nothing directly of relevance within the carried content.
If we want dublin core, use it, no need to ride on atom for that.
Use of namespaces seems redundant, especially if json
support is sought.
Step back a little and put a bookmark alongside a book definitionwith full set of metadata? Which metadata belongs where?
Book information IMHO belongs with the book, not a bookmark.
Simply xref the Book info in some catalog.
The media, on the other hand, is very relevant, in fact I'd go
so far as to say it isn't even metadata, rather prime bm content.
+1. What you do with the data is a higher layer. First define the data.
Dave Pawson
> Basically an annotation is an event and associated to this event we have:
>
> link to the start of the annotation (mimetype + href + rel)
> link to the end of the annotation (mimetype + href + rel)
> text of the annotation
> timestamps
> optionally, a few categories that we would define
>
> The author(s) of the annotation, or the work referenced are all out of scope
> and they're resources (URL) that we should point to in the annotation.
> Hadrien
1. Annotation? I thought we were talking about 'points' in a text, ie
a bookmark?
2. How is the timestamp useful?
3. Categories I can imagine, though for me they'd be of little utility?
4. IMHO the author is important, e.g. if two people read the same book on
the same device? I need to isolate your bm's from mine?
5. Equally, IMHO The work/book/document being bm'd is pretty central?
A BM is of little use in isolation? It is a mark, in a specific document?
I really can't see how the mimetype metadata is of use? Would you
explain please?
regards
Hadrien Gardeur
1. Annotation? I thought we were talking about 'points' in a text, ie
a bookmark?
- a pointer, when both the start and end link point to the same place
- a highlight, when they point to different places
2. How is the timestamp useful?
3. Categories I can imagine, though for me they'd be of little utility?
4. IMHO the author is important, e.g. if two people read the same book on
the same device? I need to isolate your bm's from mine?
5. Equally, IMHO The work/book/document being bm'd is pretty central?
A BM is of little use in isolation? It is a mark, in a specific document?
I really can't see how the mimetype metadata is of use? Would you
explain please?
Dave Pawson
>> 1. Annotation? I thought we were talking about 'points' in a text, ie
>> a bookmark?
>
> It all depends how we define our vocabulary here.
> I'll define the following:
>
> a pointer, when both the start and end link point to the same place
> a highlight, when they point to different places
OK, understood. The title of this group is bookmarks.
Anyone else agree that 'highlights' are out of scope?
>> 2. How is the timestamp useful?
>
> If you're looking for new entries, or updated entries for example.
Suggest this as optional? OK with that?
>
>>
>> 3. Categories I can imagine, though for me they'd be of little utility?
>
> It depends. A pointer for example could be a bookmark (a place I'd like to
> store) or it could be the last position in a book I'm reading. For such use
> cases, it might be useful to use categories to know they're used in a
> different way.
Both are bookmarks. Again, I'd propose as optional.
>
>>
>> 4. IMHO the author is important, e.g. if two people read the same book on
>> the same device? I need to isolate your bm's from mine?
>
> Sure, but it should be a resource (URL). How we would define the metadata
> associated to such a user is out of scope.
I meant the author of the bookmark? Not the author of the book! Sorry
if that wasn't clear. No metadata needed. Just the 'reader'/bookmarker,
whatever we decide.
>
>>
>> 5. Equally, IMHO The work/book/document being bm'd is pretty central?
>> A BM is of little use in isolation? It is a mark, in a specific
>> document?
>
> We already point to the work in a URL. Same thing than for the user:
> work/book/document is a resource (URL), and its metadata are out of scope
> for such a project.
Do 'we'? You've lost me here. What assumptions are you making please?
I was starting from scratch to define a vocabulary. where are you starting from?
>
>
>>
>> I really can't see how the mimetype metadata is of use? Would you
>> explain please?
>
> It'll indicate which type of document is being referenced and based on this
> information, how we link to such documents (for example, if the mimetype is
> application/epub+zip, the client should expect a URL following the IDPF
> linking guidelines).
Simple question. List all the media types vs their 'registered' mime-types.
How complete is the coverage?
If that works, great... But please tell me how a data definition
(the vocab used
for bm's) can link to anything? I'd suggest that is an application
using this data?
In which case out of scope?
Hadrien Gardeur
OK, understood. The title of this group is bookmarks.
Anyone else agree that 'highlights' are out of scope?
Suggest this as optional? OK with that?
Both are bookmarks. Again, I'd propose as optional.
I meant the author of the bookmark? Not the author of the book! Sorryif that wasn't clear. No metadata needed. Just the 'reader'/bookmarker,
whatever we decide.
Do 'we'? You've lost me here. What assumptions are you making please?I was starting from scratch to define a vocabulary. where are you starting from?
Simple question. List all the media types vs their 'registered' mime-types.How complete is the coverage?
If that works, great... But please tell me how a data definition
(the vocab used
for bm's) can link to anything? I'd suggest that is an application
using this data?
In which case out of scope?
Dave Pawson
>> OK, understood. The title of this group is bookmarks.
>> Anyone else agree that 'highlights' are out of scope?
>
> Based on http://wiki.openbookmarks.org/Project_terminology I would say that
> this is 100% within scope.
>
>>
>> Suggest this as optional? OK with that?
>
> I'm not, timestamps are incredibly useful and we should at least require the
> last update.
-1 for me. I'm unlikely to put sufficient bookmarks in one book
to want to distinguish between them?
anyone else?
>> I meant the author of the bookmark? Not the author of the book! Sorry
>> if that wasn't clear. No metadata needed. Just the 'reader'/bookmarker,
>> whatever we decide.
>
> I meant the author of the bookmark too. This should be a URI.
I'm sat there on a pc/using a tablet/my smartphone.
What URI is meant to represent me, the reader?
Do you want every different reader to have their own IRI?
>
>>
>> Do 'we'? You've lost me here. What assumptions are you making please?
>> I was starting from scratch to define a vocabulary. where are you starting
>> from?
>
> Any URL would have to point to the work + provide parameters and/or
> fragments indicating exactly where the URL is pointing to.
> I'm starting from existing work such as using the EPUB Linking spec (for
> EPUB), rather than from scratch.
Perhaps you'd like to add the syntax from there? Plus
an explanation/rationale?
>
>>
>> Simple question. List all the media types vs their 'registered'
>> mime-types.
>> How complete is the coverage?
>> If that works, great... But please tell me how a data definition
>> (the vocab used
>> for bm's) can link to anything? I'd suggest that is an application
>> using this data?
>> In which case out of scope?
>
> All the different type of documents that we're considering here have a
> mimetype (EPUB, HTML, Kindle).
Not so fast. Are they all registered?
If we're to use them (and they are in scope, which I'm querying)
then list them please.
Keith Fahlgren
On Thu, Jan 6, 2011 at 9:46 AM, Dave Pawson <dave....@gmail.com> wrote:
>> I'm not, timestamps are incredibly useful and we should at least require the
>> last update.
>
> -1 for me. I'm unlikely to put sufficient bookmarks in one book
> to want to distinguish between them?
I'm not aware of a single ebook reading system that doesn't order
bookmarks/annotations/highlights.
> What URI is meant to represent me, the reader?
WebFinger has been suggested as a good identifier for people.
> Do you want every different reader to have their own IRI?
Yes, every reader should have at least one identifier.
>> All the different type of documents that we're considering here have a
>> mimetype (EPUB, HTML, Kindle).
>
> Not so fast. Are they all registered?
No, they are not. Here are some that are in use:
application/x-mobipocket-ebook
application/epub+zip
text/html
Please let us know if you have a compelling counterproposal for
identifying different types of ebooks.
Regards,
Keith
Dave Pawson
> Hi,
>
> On Thu, Jan 6, 2011 at 9:46 AM, Dave Pawson <dave....@gmail.com> wrote:
>>> I'm not, timestamps are incredibly useful and we should at least require the
>>> last update.
>>
>> -1 for me. I'm unlikely to put sufficient bookmarks in one book
>> to want to distinguish between them?
>
> I'm not aware of a single ebook reading system that doesn't order
> bookmarks/annotations/highlights.
Whether the ordering is by time or anything else? Regardless of
reader choice?
Save bookmarks as I create them, list them in the same order
and you have your time ordering without a timestamp?
>
>> What URI is meant to represent me, the reader?
>
> WebFinger has been suggested as a good identifier for people.
>
>> Do you want every different reader to have their own IRI?
>
> Yes, every reader should have at least one identifier.
Tell that to the non-geek? Who has heard of Webfinger?
Why not use the name of the reader?
>
>>> All the different type of documents that we're considering here have a
>>> mimetype (EPUB, HTML, Kindle).
>>
>> Not so fast. Are they all registered?
>
> No, they are not. Here are some that are in use:
> application/x-mobipocket-ebook
> application/epub+zip
> text/html
>
> Please let us know if you have a compelling counterproposal for
> identifying different types of ebooks.
See my earlier comment. The use case for mime-types
was for access to an ebook.
IMHO that's outside the scope of defining the data structure
for bookmarks.
regards
Hadrien Gardeur
Whether the ordering is by time or anything else? Regardless of
reader choice?
Save bookmarks as I create them, list them in the same order
and you have your time ordering without a timestamp?
Tell that to the non-geek? Who has heard of Webfinger?Why not use the name of the reader?
Henrik Berggren
On 6 January 2011 15:55, Hadrien Gardeur <hadrien...@feedbooks.com> wrote:OK, understood. The title of this group is bookmarks.Anyone else agree that 'highlights' are out of scope?Based on http://wiki.openbookmarks.org/Project_terminology I would say thatthis is 100% within scope.
Suggest this as optional? OK with that?I'm not, timestamps are incredibly useful and we should at least require thelast update.
-1 for me. I'm unlikely to put sufficient bookmarks in one book
to want to distinguish between them?
anyone else?
Dave Pawson
>> Whether the ordering is by time or anything else? Regardless of
>> reader choice?
>> Save bookmarks as I create them, list them in the same order
>> and you have your time ordering without a timestamp?
>
> That's a timestamp.
Which is clearly redundant?
>
>>
>> Tell that to the non-geek? Who has heard of Webfinger?
>> Why not use the name of the reader?
>
> Non-geeks would say "email address" instead.
And for my mother, using my e-reader... what does she use?
A non-starter from a user perspective.
Dave Pawson
> I'm not, timestamps are incredibly useful and we should at least require the
>
> last update.
>
> -1 for me. I'm unlikely to put sufficient bookmarks in one book
> to want to distinguish between them?
>
> anyone else?
>
> Timestamps are holy when I design API's so definitely in for me.
> Henrik
And ordering isn't sufficient?
I.e. document order in the xml file provides relative age,
without date sort?
regards
Henrik Berggren
Henrik Berggren
> On 6 January 2011 18:07, Henrik Berggren <hen...@henrikberggren.com> wrote:
>
>> I'm not, timestamps are incredibly useful and we should at least require the
>>
>> last update.
>>
>> -1 for me. I'm unlikely to put sufficient bookmarks in one book
>> to want to distinguish between them?
>>
>> anyone else?
>>
>> Timestamps are holy when I design API's so definitely in for me.
>> Henrik
>
>
> And ordering isn't sufficient?
> I.e. document order in the xml file provides relative age,
> without date sort?
Actually no. Since we are talking about doing import/export it's quite good to know when the highlight/bookmark was actually created, not just imported.
Henrik
Hadrien Gardeur
Actually no. Since we are talking about doing import/export it's quite good to know when the highlight/bookmark was actually created, not just imported.
Sarven Capadisli
> First of all, I'm 100% against the suggested format.
I've suggested using the RDF data model here
https://groups.google.com/group/openbookmarks/msg/e257cf1d0762e5b8?dmode=source&output=gplain&noredirect and use any serialization in any application/device.
I'm still curious to hear anything for or against this suggestion.
-Sarven
Hadrien Gardeur
Sarven Capadisli
> I'm fine with RDF as long as we can also serialize things in XML/Atom
> and JSON.
That's not a problem. The key here is to stick to a universal
representation and let the applications and devices decide how they want
to serialize or transform the data.
Also, if bookmark items can be derefenceable URIs, then the whole Web
can make use of them. No need to worry about whether to include or
exclude anything in particular (e.g., discussion on timestamps) since
everyone is free to claim any information. If someone wants to make use
of that in any way, that would be a plus. This scales well and doesn't
set any hard limitations for the future.
-Sarven
Hadrien Gardeur
That's not a problem. The key here is to stick to a universalrepresentation and let the applications and devices decide how they want
to serialize or transform the data.
Also, if bookmark items can be derefenceable URIs, then the whole Web
can make use of them. No need to worry about whether to include or
exclude anything in particular (e.g., discussion on timestamps) since
everyone is free to claim any information. If someone wants to make use
of that in any way, that would be a plus. This scales well and doesn't
set any hard limitations for the future.
Dave Pawson
>> And ordering isn't sufficient?
>> I.e. document order in the xml file provides relative age,
>> without date sort?
>
> Actually no. Since we are talking about doing import/export it's quite good to know when the highlight/bookmark was actually created, not just imported.
I haven't heard a use case for this though, of use to the reader?
Important for an api, important for ???
That's three elements.
Would someone keep a list please?
Dave Pawson
Again 'for an application'
What's the user need you're answering here Hadrien?
Dave Pawson
Lack of comprehension of RDF wrt POXML?
Relative lack of tools for processing RDF?
How many e-readers have RDF tools installed.
Dave Pawson
> Also, if bookmark items can be derefenceable URIs, then the whole Web
> can make use of them. No need to worry about whether to include or
> exclude anything in particular (e.g., discussion on timestamps) since
> everyone is free to claim any information. If someone wants to make use
> of that in any way, that would be a plus. This scales well and doesn't
> set any hard limitations for the future.
I can see your logic.
What I don't see is how my bookmarks, on my e-reader, are web accessible?
Or why I would want them to be?
Bookmarks in the cloud?
Henrik Berggren
On 6 January 2011 18:12, Henrik Berggren <hen...@henrikberggren.com> wrote:And ordering isn't sufficient?I.e. document order in the xml file provides relative age,without date sort?Actually no. Since we are talking about doing import/export it's quite good to know when the highlight/bookmark was actually created, not just imported.
I haven't heard a use case for this though, of use to the reader?
Important for an api, important for ???
That's three elements.
Would someone keep a list please?
Henrik Berggren
>>> Actually no. Since we are talking about doing import/export it's quite
>>> good to know when the highlight/bookmark was actually created, not just
>>> imported.
>>
>> While designing a client, I would also like to know when a
>> highlight/bookmark was updated too.
>
> Again 'for an application'
> What's the user need you're answering here Hadrien?
For us it's a UI thing, being able to display: "Highlighted by Hadrien 2 weeks ago" before each highlight.
Henrik
Dave Pawson
> http://wiki.openbookmarks.org/Use_cases
> It's one of the basic ones.
Comments on the wiki.
How many e-readers have web access? (export the bms)
Or is that a constraint/assumption on this groups work?
Who maintains/pays for/ the cloud service keeping these bms?
I've started two pages on the wiki.
Elements (to capture candidate information items)
Scope (to identify assumptions/constraints)
Dave Pawson
I can accept that, though personally I'd shrug and question how that
is useful to the reader.
I've added it to the wiki
Henrik Berggren
On 7 January 2011 07:20, Henrik Berggren <hen...@henrikberggren.com> wrote:http://wiki.openbookmarks.org/Use_casesIt's one of the basic ones.
Comments on the wiki.
How many e-readers have web access? (export the bms)
Or is that a constraint/assumption on this groups work?
Who maintains/pays for/ the cloud service keeping these bms?
I've started two pages on the wiki.
Elements (to capture candidate information items)
Scope (to identify assumptions/constraints)
Dave Pawson
> On 7 January 2011 07:20, Henrik Berggren <hen...@henrikberggren.com> wrote:
>
> http://wiki.openbookmarks.org/Use_cases
>
> It's one of the basic ones.
>
>
> Comments on the wiki.
> How many e-readers have web access? (export the bms)
> Or is that a constraint/assumption on this groups work?
> Who maintains/pays for/ the cloud service keeping these bms?
>
> I'm building a cloud service for highlights and such as we speak. And my aim
> is to use whatever spec. we come up with in this group so that readers can
> easily work together.
> http://readmill.com/
OK. What % of e-readers have web access to make use of it?
Is that a constraint on the project?
Henrik Berggren
What do you mean by web access? Connected to the internet?
Anyhow, it doesn't really matter, we plan on supporting desktop synced devices as the Sony Reader as well. Having your highlights, notes and reads easy accessible independent of device makes a lot of sense.
Henrik
Dave Pawson
>> Is that a constraint on the project?
>
>
> What do you mean by web access? Connected to the internet?
>
> Anyhow, it doesn't really matter, we plan on supporting desktop synced devices as the Sony Reader as well. Having your highlights, notes and reads easy accessible independent of device makes a lot of sense.
So you are assuming web access (an internet connection), even if indirectly.
To me it sounds like you are looking to define an application, which
happens to need/make use of
an agreed data format (bookmarks). Am I right in this guess? Should
that context be added
as background information?
Which brings up another aspect. Is there a use case for defining
bookmarks without such a connection?
I.e. totally within my e-reader, or perhaps in the context of home
use, i.e. Some mix of my PC
and my e-reader?
Would there be overlap? something like the connected use being a
superset of the 'isolated' use?
That would make sense to me.
Benoît Larroque
If you by e-ereader you mean every "ebook capable" device, that would
be a vast majority (you then have to count phones, ipads...).
If you only mean dedicated readers (let's say only eInk screens), if
you count closed systems (Kindles, Nooks, even FnacBooks...) then
again a majority ! If you are not counting those then not so many with
direct internet access (Cybook Orizon is an example) but all have
indirect internet access. Those ebooks have to come from somewhere !
Regards,
Benoît Larroque
Feedbooks R&D engineer
Dave Pawson
> If you by e-ereader you mean every "ebook capable" device, that would
> be a vast majority (you then have to count phones, ipads...).
>
> If you only mean dedicated readers (let's say only eInk screens), if
> you count closed systems (Kindles, Nooks, even FnacBooks...) then
> again a majority ! If you are not counting those then not so many with
> direct internet access (Cybook Orizon is an example) but all have
> indirect internet access. Those ebooks have to come from somewhere !
Thanks Benoît
I guess we should include any ebook capable device.
PC, smartphone, ipad etc.
Your point on 'closed' systems leaves an open question. Any data format
would need to be very enticing to persuade them to adopt it. Either
at the format level or application support.
So datawise we should then include net access as a context.
Just leave it to an application to ensure a smooth interface when
indirect.
Hadrien Gardeur
I'm building a cloud service for highlights and such as we speak. And my aim is to use whatever spec. we come up with in this group so that readers can easily work together.
Dave Pawson
Again a scope issue? If you want an application that uses bm data,
then you'll need to recognise the reading-device and serve content
accordingly, same way a server does with a client?
IMHO that is not a facet of the data being transported.
Hadrien Gardeur
Dave Pawson
Again scope? I send XML over http, tcp/ip etc. The protocol and the
data sent over
a wire using that protocol are two different things?
How about 'reading device'? But again, that's immaterial if I create a
bookmark on device A
and use it on device B? That is in one of the wiki use cases?
stml
contributions.
A few responses to the above:
* highlights are in scope: they are a form of bookmark, as noted in
this thread and at http://wiki.openbookmarks.org/Project_terminology.
Discussion of these types of bookmark is for another thread.
* I'm seriously opposed to the mimetype approach for the same reason I
am opposed to the epub-based approach. It relies on other, current
technologies, a tiny subset of all literature and literary formats.
We're looking for a way to point at a bit of text in any larger bit of
text, forever. I'd rather we figured out a way of doing this that
worked most of the time, everywhere, rather than all of time, in some
places. This means a more fuzzy way of working based on authors,
titles and strings of text, with identifiers like OL IDs, ISBNs and
formats as a fall-back.
* Authorship of bookmarks is out of scope. This is a transfer
protocol. The identity of who created or owns the bookmark is up for
other systems to manage.
* We're not trying to make a protocol for the whole web. As worthy as
that is, we're trying to solve these problems - http://wiki.openbookmarks.org/Use_cases
- and these problems alone, for now.
* Strongly agree about timestamps. Everything needs a timestamp,
basically: for sorting, for starters.
* I'm supportive of Atom/JSON, less so of RDF, based on previous
experience of working with different protocols. In particular, Atom/
JSON is easier for developers to pick up and run with IMO.
I'd like to keep this format discussion to its own thread too, if
possible! Glad to see the discussion going on though.
Let's take a step back from this thread for a bit: I'm going to post
another discussion question.
On Jan 6, 11:21 pm, Hadrien Gardeur <hadrien.gard...@feedbooks.com>
wrote:
Dave Pawson
> Phew - lots of things happening. Thank you everyone for your
> contributions.
>
> A few responses to the above:
>
> * highlights are in scope:
Simple question. On what authority are you defining in / out of scope?
Sorry to sound ignorant, I thought this to be a group development?
Hadrien Gardeur
* I'm seriously opposed to the mimetype approach for the same reason I
am opposed to the epub-based approach. It relies on other, current
technologies, a tiny subset of all literature and literary formats.
We're looking for a way to point at a bit of text in any larger bit of
text, forever. I'd rather we figured out a way of doing this that
worked most of the time, everywhere, rather than all of time, in some
places. This means a more fuzzy way of working based on authors,
titles and strings of text, with identifiers like OL IDs, ISBNs and
formats as a fall-back.
* Authorship of bookmarks is out of scope. This is a transfer
protocol. The identity of who created or owns the bookmark is up for
other systems to manage.
* We're not trying to make a protocol for the whole web. As worthy as
that is, we're trying to solve these problems - http://wiki.openbookmarks.org/Use_cases
- and these problems alone, for now.
* I'm supportive of Atom/JSON, less so of RDF, based on previous
experience of working with different protocols. In particular, Atom/
JSON is easier for developers to pick up and run with IMO.
Hadrien Gardeur
Simple question. On what authority are you defining in / out of scope?
Sorry to sound ignorant, I thought this to be a group development?
Dave Pawson
No problem with that. Two pointers is reasonable.... two pointers into
a print book is
a waste of time though? Into XML is viable. Into HTML is viable (but messy)
Drives other debates, but I'm more curious on James quite definitive
in/out of scope statements.
Sarven Capadisli
> On 6 January 2011 18:43, Sarven Capadisli <in...@csarven.ca> wrote:
>
> > Also, if bookmark items can be derefenceable URIs, then the whole Web
> > can make use of them. No need to worry about whether to include or
> > exclude anything in particular (e.g., discussion on timestamps) since
> > everyone is free to claim any information. If someone wants to make use
> > of that in any way, that would be a plus. This scales well and doesn't
> > set any hard limitations for the future.
>
> I can see your logic.
> What I don't see is how my bookmarks, on my e-reader, are web accessible?
> Or why I would want them to be?
>
> Bookmarks in the cloud?
The idea proposed is that if one chooses to publish (whether on their
website, or a 3rd party service) their bookmarks on an HTTP URI, it
opens up the possibility of making references to those bookmarks (see
examples at [1]). Of course, no one is forced to make their bookmarks
public. However, some people would want to share their bookmarks.
-Saven
stml
> The idea proposed is that if one chooses to publish (whether on their
> website, or a 3rd party service) their bookmarks on an HTTP URI, it
> opens up the possibility of making references to those bookmarks (see
> examples at [1]). Of course, no one is forced to make their bookmarks
> public. However, some people would want to share their bookmarks.
passing bookmarks in ebooks from one service or platform to another,
archiving them etc. If that third party chooses to make those
bookmarks available at a particular URI, great. But it's not Open
Bookmarks' responsibility to make that referencing possible - only the
possibility of someone else doing so.
Sarven Capadisli
> On 6 January 2011 18:26, Sarven Capadisli <in...@csarven.ca> wrote:
> > On Mon, 2011-01-03 at 23:42 +0100, Hadrien Gardeur wrote:
> >
> >> First of all, I'm 100% against the suggested format.
> >
> > I've suggested using the RDF data model here
> > https://groups.google.com/group/openbookmarks/msg/e257cf1d0762e5b8?dmode=source&output=gplain&noredirect and use any serialization in any application/device.
> >
> > I'm still curious to hear anything for or against this suggestion.
>
> Lack of comprehension of RDF wrt POXML?
No need to make direct comparison to POXML because RDF is a data model,
and it can be serialized in RDF/XML, RDFa, Turtle, NTriples, JSON. I'm
not sure I understand the real concern behind the comment-question. Is
it a concern for developers?
> Relative lack of tools for processing RDF?
There are *many* RDF tools. http://www.w3.org/2001/sw/wiki/Category:Tool
lists some. I'm sure there are many out there that are not listed.
> How many e-readers have RDF tools installed.
Valid question. I'm not an expert on e-readers, so, I would say I don't
know. But I imagine there are none. However, I would like to know which
tools do e-readers use that can import/export (publish) bookmarks from
desktop/Web?
-Sarven
Sarven Capadisli
RDF satisfies the cases you've outlined. RDF happens to use URIs. Using
URIs gives the ability to identify (naming a thing) a particular
bookmark item. This is the necessary hook for the rest of the Web.
-Sarven
Andrew Bate
Please consider the environment before printing this email.
Find out more about Talis at http://www.talis.com/
shared innovation™
Any views or personal opinions expressed within this email may not be those of Talis Information Ltd or its employees. The content of this email message and any files that may be attached are confidential, and for the usage of the intended recipient only. If you are not the intended recipient, then please return this message to the sender and delete it. Any use of this e-mail by an unauthorised recipient is prohibited.
Talis Information Ltd is a member of the Talis Group of companies and is registered in England No 3638278 with its registered office at Knights Court, Solihull Parkway, Birmingham Business Park, B37 7YB.
Talis North America is Talis Inc., 11400 Branch Ct., Fredericksburg, VA 22408, United States of America.