Sure-- I've made a page at: https://github.com/apache/incubator-annotator/wiki/LDP-and-Web-Annotation-Protocol-Implementations
although I don't know that there's really a wrong way for us to go about this! :grin: I'm afraid that I'm not aware of any other Web Annotation Protocol-specific impls, but that says more about my ignorance than anything else. On paging in particular, are we committed to building on the Activity Streams model via https://www.w3.org/TR/annotation-protocol/#annotation-pages ? ajs6f > On Jan 23, 2019, at 1:51 PM, Benjamin Young <byo...@bigbluehat.com> wrote: > > Agreed! Perhaps we could start by building a list on the wiki (and later the > site) of LDP and Web Annotation Protocol (specific) implementations. > > Once we have that, I'd reckon some browser-side client plumbing would be in > order (i.e. annotation service discovery, code to get a collection of > annotations based on the current documents URI, pagination across annotation > collections, etc). > > Sound about right? > > > -- > > http://bigbluehat.com/ > > http://linkedin.com/in/benjaminyoung > > ________________________________ > From: Randall Leeds <rand...@apache.org> > Sent: Wednesday, January 23, 2019 1:16 PM > To: dev@annotator.incubator.apache.org > Subject: Re: LDP and persistence Was: introduction > > This makes good sense to me. > > On Wed, Jan 23, 2019, 09:59 ajs6f <aj...@apache.org wrote: > >> Hi, Benjamin-- >> >> No problem. I'm obviously not all that good about quick response myself! :0 >> >> It seems to me that these two things (the relationship to LDP and the >> question of backend persistence) could be connected: is it not possible to >> choose LDP for the data storage abstraction layer for Annotator? Of course, >> we would probably have to pick at least one LDP implementation to package >> with Annotator as a choice for those who "choose not to choose" for >> themselves or for people who are just interested in playing with web >> annotation and don't need to think about production deployment. >> >> If we chose LDP for the abstraction layer, then we could also choose a >> default component that can use whatever we think are appropriate concrete >> forms for persistence. (Benjamin Goering mentioned using widely-available >> RDBMSes, for example, which is certainly a good and common pattern, and >> plenty of LDP impls can use them.) >> >> One reason I suggest this: if we choose for a lower-level persistence >> abstraction (e.g. working directly against an SQL backend) and given that >> the Web Annotation protocol extends LDP, we will find ourselves rewriting >> code that LDP implementations have already written and which already is >> tested in use. >> >> ajs6f >> >>> On Jan 15, 2019, at 9:55 AM, Benjamin Young <byo...@bigbluehat.com> >> wrote: >>> >>> Hey Adam! >>> >>> First, huge apologies for letting this slip through the cracks caused by >> all the holiday-ing (at least for me ;) )! >>> >>> Second, you're spot on about Web Annotation Protocol being essentially >> an extension of the Linked Data Platform (LDP) [1] spec. Also, Web >> Annotations, being based on JSON-LD, can be stored into any triple store. >> The server-side implementations tested by the W3C so far [2] have used the >> filesystem, a relational database, or a JSON-friendly NoSQL database >> (MongoDB, Apache CouchDB, PouchDB, etc). >>> >>> Honestly, database selection is one of the things that has tripped me up >> in contributing a server implementation. I want it to be database/store >> agnostic, ideally, but that comes with it's own "tyranny of choice" among >> data storage abstraction layers. 😋 >>> >>> In the end, it's up to the group to decide what to build and what to >> build on and in what language...etc. >>> >>> Most of the work has gone into the DOM connective tissue code, and I've >> brought over some of the Web Annotation Data Model validation code [3]. >> There's still more to do on all fronts. 😊 >>> >>> Let me know if you have thoughts on the plans here. Your experience with >> Jena (both as a project and a tool) would be very helpful! >>> >>> Cheers! >>> Benjamin >>> >>> >>> [1] https://www.w3.org/TR/ldp/ >>> [2] >> https://github.com/w3c/test-results/tree/gh-pages/annotation-protocol#index-of-implementations-tested >>> [3] >> https://github.com/apache/incubator-annotator/blob/master/test/data-model.mjs >>> >>> >>> -- >>> >>> http://bigbluehat.com/ >>> >>> http://linkedin.com/in/benjaminyoung >>> >>> ________________________________ >>> From: ajs6f <aj...@apache.org> >>> Sent: Wednesday, January 2, 2019 4:14 PM >>> To: dev@annotator.incubator.apache.org >>> Subject: introduction >>> >>> Hi, Annnotator folks! >>> >>> My name is Adam Soroka and I'm a committer for Apache Jena. For a day >> job I work at the Smithsonian Institution and I've been interested in >> semantic technology for quite a while in the context of so-called cultural >> heritage. I watched the W3C Web Annotation WG with interest and I was happy >> to see extensions developed for the International Image Interoperability >> Framework [1]. >>> >>> I'm still a little uncertain about the scope of the Annotator project. >> It seems to include a node.js server component to store and manage >> annotations as well as browser-side tooling. I was under the impression >> (very likely wrong!) that annotations, as RDF graphs, could be stored in >> anything that can store RDF (triplestores, etc.) and that in particular, >> LDP implementations should be able to support the annotation protocol >> (almost?) directly. Is this wrong? Are there special requirements on >> annotation servers that make it appropriate to use a special-purpose part? >>> >>> Thanks for any clarification/info/advice! >>> >>> ajs6f >>> >>> [1] https://iiif.io/api/annex/openannotation/index.html >> >>
