- From: Karen Coyle <kcoyle@kcoyle.net>
- Date: Sun, 29 Mar 2015 08:34:09 -0700
- To: public-data-shapes-wg@w3.org
On 3/29/15 5:30 AM, Richard Cyganiak wrote: > >> On 29 Mar 2015, at 08:19, Holger Knublauch <holger@topquadrant.com> wrote: >> >> Another aspect is that having to produce and parse new SPARQL strings repeatedly is very slow. Pre-binding a variable in an already parsed SPARQL query object is usually much faster. > > That’s an implementation detail. +1 >> In my current design, templates can set a flag to indicate whether they also need to see the graph containing the constraint definitions in their WHERE clause. This means that most operations can be very fast, and only access the query graph. Other operations may need to see the constraints graph too, and these may be slower. > > Wouldn’t this be better solved with named graphs? Have the data under validation in the default graph, and pass in a variable like ?constraintGraphName that could be used like this to access the constraint graph: > > GRAPH ?constraintGraphName { … } > > Implementations could detect whether ?constraintGraphName is actually used in the template, and optimise the case where it’s not. > This though assumes that you have control over the instance data, which is not always the case. So although this may work for some applications, others will be operating over data created by third parties who have their own data model. I mention this just so we can keep in mind that we have both situations to address. kc > Richard > -- Karen Coyle kcoyle@kcoyle.net http://kcoyle.net m: 1-510-435-8234 skype: kcoylenet/+1-510-984-3600
Received on Sunday, 29 March 2015 15:34:39 UTC