- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Fri, 20 Feb 2015 15:44:03 -0500
- To: public-lod@w3.org
- Message-ID: <54E79C93.3040601@openlinksw.com>
On 2/20/15 1:19 PM, Graham Klyne wrote: > Hi Stian, > > Thanks for the mention :) > >> Graham Klyne's Annalist is perhaps not quite what you are thinking of >> (I don't think it can connect to an arbitrary SPARQL endpoint), but I >> would consider it as falling under a similar category, as you have a >> user interface to define record types and forms, browse and edit >> records, with views defined for different record types. Under the >> surface it is however all RDF and REST - so you are making a schema by >> stealth. >> >> http://annalist.net/ >> http://demo.annalist.net/ > > Annalist is still in its prototype phase, but it's available to play > with if anyone wants to try stuff. See also > https://github.com/gklyne/annalist for source. There's also a > Dockerized version. > > It's true that Annalist does not currently connect to a SPARQL > endpoint, but have recently been doing some RDF data wrangling and > starting to think about how to connect to public RDF (e.g. > http://demo.annalist.net/annalist/c/CALMA_data/d/ is a first attempt > at creating an editable version of some music data from your colleague > Sean). In this case, the record types and views have been created > automatically from the raw data, and are pretty basic - but that > automatic extraction can serve as a starting point for subsequent > editing. (The reverse of this, creating an actual schema from the > defined types and views, is an exercise for the future, or maybe even > for a reader :) ) > > Internally, the underlying data access is isolated in a single module, > intended to facilitate connecting to alternative backends, which could > be via SPARQL access. (I'd also like to connect up with the linked > data fragments work at some stage.) > > If this looks like something that could be useful to anyone out there, > about now might be a good time to offer feedback. Once I have what I > feel is a minimum viable product release, hopefully not too long now, > I'm hoping to use feedback and collaborations to prioritize ongoing > developments. > > #g > -- It is very good and useful, in my eyes! My enhancement requests would be that you consider supporting of at least one of the following, in regards to storage I/O: 1. LDP 2. WebDAV 3. SPARQL Graph Protocol 4. SPARQL 1.1 Insert, Update, Delete. As for Access Controls on the target storage destinations, don't worry about that in the RDF editor itself, leave that to the storage provider [1] that supports any combination of the protocols above. Links: [1] http://kidehen.blogspot.com/2014/07/loosely-coupled-read-write-interactions.html -- Loosely-Coupled Read-Write Web pattern example. -- Regards, Kingsley Idehen Founder & CEO OpenLink Software Company Web: http://www.openlinksw.com Personal Weblog 1: http://kidehen.blogspot.com Personal Weblog 2: http://www.openlinksw.com/blog/~kidehen Twitter Profile: https://twitter.com/kidehen Google+ Profile: https://plus.google.com/+KingsleyIdehen/about LinkedIn Profile: http://www.linkedin.com/in/kidehen Personal WebID: http://kingsley.idehen.net/dataspace/person/kidehen#this
Attachments
- application/pkcs7-signature attachment: S/MIME Cryptographic Signature
Received on Friday, 20 February 2015 20:44:27 UTC