OK, thanks. I would really prefer that the discussion not focus on
specific applications (e.g. Jena). We really need to avoid assumptions
based on current implementations. And there also is a desire to be open
to non-SPARQL applications as well as ones implemented using SPARQL.
Let's try to keep clear what we're talking about.
kc
On 4/14/15 4:56 PM, Holger Knublauch wrote:
> On 4/15/2015 9:46, Karen Coyle wrote:
>> Holger, is this explanation solely SPARQL specific? If so, if SPARQL
>> is not being used, what is the meaning of dataset? Is as Corey defined?
>
> Direct pick-and-choose access to named graphs is indeed only relevant
> for SPARQL, via GRAPH or FROM keywords. If you have generic constraints
> such as checking the cardinality of a property and the properties are
> distributed across multiple named graphs, then the "default graph" of
> the dataset would be used, and that could very well be the union of
> multiple graphs.
>
>> And I'm not sure how graph "implementations" can be wrappers of remote
>> graphs. This may be important for us, as we do have the issue of of
>> needing to access external graphs to complete validation.
>
> This is a fairly technical topic, and I was referring to Jena
> implementations and interfaces. Jena does have adapters (Graph
> implementations) for all kinds of databases from different vendors. It
> is also straight-forward to create a Graph implementation that delegates
> all queries to a SPARQL end point. Optimizations of this access are IMHO
> implementation-specific and can be handled by a SHACL engine and the
> Dataset implementation. Likewise, a SHACL engine could modify the
> default SPARQL queries that it gets so that they have better performance
> (e.g. inlining sh:allowedValues).
>
> Holger
>
--
Karen Coyle
[log in to unmask] http://kcoyle.net
m: 1-510-435-8234
skype: kcoylenet/+1-510-984-3600
|