Re: comparing to OWL and SPIN

On 07/21/2014 05:55 PM, Peter F. Patel-Schneider wrote:
> I don't think so.
>
> When working against an RDF stream, a ShEx engine has to keep track of 
> the partial matches for each node it has seen, which is roughly of the 
> same size as the graph.
>

Yes, Jerven already corrected me on this.

Staying on this efficiency angle, I bet there's a way to order the 
triples in an RDF serialization so that when systems share a 
shape/constraint declaration, the serialization can be validated without 
any storage.   Obviously the validator would need to be prepared for 
getting things in just the wrong order, in which case it would need to 
store approximately the graph, as you say.

This would require ordering in the shape/constraint language, though, 
which maybe none of the current proposals have in their semantics.

Probably not that important.

     -- Sandro

> peter
>
>
> On 07/21/2014 10:49 AM, Sandro Hawke wrote:
>> On 07/21/2014 08:09 AM, Peter F. Patel-Schneider wrote:
>>>> I could be that the Regular Expression derivatives algorithm, 
>>>> although much
>>>> less expressive then OWL, is outperforming the OWL reasoners.  Only 
>>>> some
>>>> research and testing will give an useful answer, but certainly 
>>>> something
>>>> nice to consider and test.
>>>
>>> Yes, this could be tested.  I expect that StarDog ICV will perform very
>>> well, as it works by translation into SPARQL queries.
>>
>> It looks to me like ShEx could validate a graph serialization in 
>> linear time
>> (with the size of the serialization), with no need for storing the 
>> graph.
>> That's appealing to me when we're talking about validating messages 
>> that are
>> being sent between systems.
>>
>> SPARQL based solutions require storing and searching the graph, which is
>> exponential (and likely slow unless properly indexed), but that's 
>> probably
>> fine if you're just validating data that you need to keep in a SPARQL 
>> system
>> anyway.
>>
>>      -- Sandro
>>
>

Received on Monday, 21 July 2014 22:47:56 UTC