Comments on: Approaches to Publishing Linked Data via Named Graphs http://www.ldodds.com/blog/2009/12/approaches-to-publishing-linked-data-via-named-graphs/ A journal of no fixed aims or direction, by Leigh Dodds Fri, 10 Dec 2010 14:02:04 -0500 http://wordpress.org/?v=2.8.1 hourly 1 By: admin http://www.ldodds.com/blog/2009/12/approaches-to-publishing-linked-data-via-named-graphs/comment-page-1/#comment-393 admin Mon, 21 Dec 2009 15:59:59 +0000 http://www.ldodds.com/blog/?p=386#comment-393 Hi Michael, Thanks for the pointer I'll take a look at the paper. I've read your recent blog posts about RDF & REST as its an area that I'm particularly interested in: the two are very well aligned in my view. Cheers, L. Hi Michael,

Thanks for the pointer I’ll take a look at the paper. I’ve read your recent blog posts about RDF & REST as its an area that I’m particularly interested in: the two are very well aligned in my view.

Cheers,

L.

]]> By: admin http://www.ldodds.com/blog/2009/12/approaches-to-publishing-linked-data-via-named-graphs/comment-page-1/#comment-392 admin Mon, 21 Dec 2009 15:58:30 +0000 http://www.ldodds.com/blog/?p=386#comment-392 Hi Benji, Thanks for the comment, that's another interesting variant and one that I hadn't considered. L. Hi Benji,

Thanks for the comment, that’s another interesting variant and one that I hadn’t considered.

L.

]]> By: Benjamin Nowack http://www.ldodds.com/blog/2009/12/approaches-to-publishing-linked-data-via-named-graphs/comment-page-1/#comment-391 Benjamin Nowack Mon, 21 Dec 2009 08:27:01 +0000 http://www.ldodds.com/blog/?p=386#comment-391 Hi Leigh, I'm generally using multiple graphs per resource, where each graph is associated with a certain front-end operation, e.g. the "basic details"-form for resource writes into graph , the "friends"-manager saves data in , interests go into etc. This requires a graph look-up when a resource is going to be deleted, but it makes managing sub-chunks of a resource description quite hassle-free. I can simply replace the respective graph w/o messing with the data that's meant to be kept. Caching and RDF serving is then based on the resource view (which is built from multiple graphs), i.e. a new, app-specific graph is exposed to consuming applications. To support the larger number of graphs backend-wise, I've normalized/separated the "graph" URI from the triple parts so that typical/non-graph queries can work with a compact triple table. On the down-side, certain GRAPH patterns (e.g. in OPTIONALs) become rather painful due to the larger number of table joins. Hi Leigh,

I’m generally using multiple graphs per resource, where each graph is associated with a certain front-end operation, e.g. the “basic details”-form for resource writes into graph , the “friends”-manager saves data in , interests go into etc.

This requires a graph look-up when a resource is going to be deleted, but it makes managing sub-chunks of a resource description quite hassle-free. I can simply replace the respective graph w/o messing with the data that’s meant to be kept.

Caching and RDF serving is then based on the resource view (which is built from multiple graphs), i.e. a new, app-specific graph is exposed to consuming applications.

To support the larger number of graphs backend-wise, I’ve normalized/separated the “graph” URI from the triple parts so that typical/non-graph queries can work with a compact triple table. On the down-side, certain GRAPH patterns (e.g. in OPTIONALs) become rather painful due to the larger number of table joins.

]]> By: Michael Hausenblas http://www.ldodds.com/blog/2009/12/approaches-to-publishing-linked-data-via-named-graphs/comment-page-1/#comment-386 Michael Hausenblas Sun, 20 Dec 2009 14:07:43 +0000 http://www.ldodds.com/blog/?p=386#comment-386 Thanks for this Leigh, very valuable write-up! I agree, it's an important issue and we should start collecting good practices. Note that we've recently looked into this issue as well (http://sw-app.org/pub/restful-sparql.pdf) Cheers, Michael Thanks for this Leigh, very valuable write-up! I agree, it’s an important issue and we should start collecting good practices. Note that we’ve recently looked into this issue as well (http://sw-app.org/pub/restful-sparql.pdf)

Cheers,
Michael

]]> By: uberVU - social comments http://www.ldodds.com/blog/2009/12/approaches-to-publishing-linked-data-via-named-graphs/comment-page-1/#comment-385 uberVU - social comments Sun, 20 Dec 2009 13:47:10 +0000 http://www.ldodds.com/blog/?p=386#comment-385 <strong>Social comments and analytics for this post...</strong> This post was mentioned on Twitter by ldodds: New blog post: Approaches to Publishing Linked Data via Named Graphs. http://bit.ly/6ZspJH #rdf #linkeddata #REST... Social comments and analytics for this post…

This post was mentioned on Twitter by ldodds: New blog post: Approaches to Publishing Linked Data via Named Graphs. http://bit.ly/6ZspJH #rdf #linkeddata #REST…

]]> By: Justin Cormack http://www.ldodds.com/blog/2009/12/approaches-to-publishing-linked-data-via-named-graphs/comment-page-1/#comment-384 Justin Cormack Sun, 20 Dec 2009 13:37:19 +0000 http://www.ldodds.com/blog/?p=386#comment-384 I have been thinking about the first case in fairly similar terms for a while. A queue based model with eventual consistency has also been my preferred choice, although I think you may need to build up more general collection objects than full triplestores to efficiently answer specific queries. I am glad there is some recognition in the W3C now that it is necessary to talk about RDF and SPARQL outside a pure document context and recognize that the (only significant) use case is on the web and issues about REST, the resource model and updates matter. We need to get away from Prolog in XML to get stuff used. I have been thinking about the first case in fairly similar terms for a while. A queue based model with eventual consistency has also been my preferred choice, although I think you may need to build up more general collection objects than full triplestores to efficiently answer specific queries.

I am glad there is some recognition in the W3C now that it is necessary to talk about RDF and SPARQL outside a pure document context and recognize that the (only significant) use case is on the web and issues about REST, the resource model and updates matter. We need to get away from Prolog in XML to get stuff used.

]]>