Re: Implementation feasibility

On Sat, Mar 21, 2015 at 9:32 PM, Jose Emilio Labra Gayo <jelabra@gmail.com>
wrote:

> It depends on what you call "large RDF graphs" and on what you call "work
>>> well". Some of the work has been done precisely to identify tractable
>>> subsets of the language. Much more work can be done to find better
>>> algorithms and optimizations and even to define hybrid implementation that
>>> leverage parts of the implementation to other tools.
>>>
>>
>> What about DBpedia? Around 3B triples in the last release and we expect a
>> big increase in the next one.
>> http://www.slideshare.net/jimkont/dbpedia-dublin-aligned-1
>>
>
> Yes, DBPedia is a very good use case. But precisely for that, I think we
> should try to have a solution that doesn't depend on SPARQL and where SHACL
> processors can be optimized for that kind of data.
>
> If SHACL implementations need to be based on SPARQL, then it will be very
> difficult to optimize SHACL processors given SPARQL's own complexity. While
> if we are able to define a SHACL high-level language with a set of
> constructs that can be implemented without SPARQL, then we are promoting
> the appearance of third party implementations that can be optimized to
> handle those problems.
>

The problem  is that we need solutions that work reliable and fast for
existing systems. We should not be based on what might or might not be
achieved in the future.
There was a recent validation I performed for a paper, can you provide a
time estimate for a ShEx validation on the following setting using your
laptop?
Validate 4M instances from a 62M triple RDF dataset against ~1,500 class
shapes with ~9,500 facets.


> As an example, my ShExcala implementation contained a "validation by
>>> endpoint" extension which allows triples that affect a node to be validated
>>> on demand through an endpoint. This was an experimental feature that I had
>>> no time to fully test due to other obligations. I also think Eric has also
>>> been working extending his implementation in a similar way.
>>>
>>
>> Correct me if I am wrong but IIRC your implementation was just running
>> ShEx on the results of a SPARQL CONSTRUCT query which is more like
>> validating a remote RDF file.
>>
>
> My implementation was validating the triples around a node on demand based
> on an SPARQL endpoint. It was experimental and I didn't have enough time to
> test it or to improve the validator to work, for example, in parallel.
> That's one of the multiple things in my TODO list. Anyway, I think that
> kind of validators can be really useful and DBPedia will be one of the best
> data against which they should be tested.
>

We would happily accept anything that can improve DBpedia.


> The WG can promote the appearance of independent implementations which do
>>> not depend on SPARQL or it can prohibit them by saying that in order to
>>> implement SHACL one needs a SPARQL engine.
>>>
>>
>> So far I didn't hear any WG members in favor of SPARQL object in having a
>> 'SHACL part' (call it whatever) that can be implemented independent of
>> SPARQL
>>
>
> The problem comes when the spec is tied to SPARQL and there is an
> opposition to define the high-level language independent from SPARQL or to
> have a language construct that clearly defines the boundary between
> extensions based on SPARQL and the rest of the SHACL language.
>

There was a WG decision on the F2F meeting to base the semantics on SPARQL,
you did not object then but you seem to object now.
http://www.w3.org/2015/02/18-shapes-minutes.html#resolution02

Personally I have no problem in defining the semantics of the high level
vocabulary without SPARQL but I would be very concerned if SHACL did not
have a native support for SPARQL.
And although Javascript could be considered an extension since it has no
native RDF support, SPARQL is a completely different case.

Best regards,
Dimitris


> Best regards, Jose Labra
>
>
>> Best,
>> Dimitris
>>
>>>
>>> Best regards, Jose Labra
>>>
>>>
>>>
>>>>
>>>> peter
>>>>
>>>> -----BEGIN PGP SIGNATURE-----
>>>> Version: GnuPG v1
>>>>
>>>> iQEcBAEBAgAGBQJVDF5XAAoJECjN6+QThfjzm3QH/jKXikzvRDzt+AiM9+iM5e6X
>>>> NMeBC8TdklOvCaDJRiIW0XgAZcufNeSEhz+ofCd2q6HSWOuXpzWwspRIcUV9N84E
>>>> 6N/oqzFod4B1ClUb2bPQ8bY9CoTIo9ghavNN97va5HsWqoRhmJBpxmT4EvZaSpq1
>>>> wzKy6MrJNJnHhfKH9x4WUDwH5t7FR9RkaB4UiNuVpVBpcLgP2xCiBondDqmXmASz
>>>> AcJB+tw0NY5rHanhCE4bUKGEegojsSjnEWAsdPdT5cb+64FvocM22V0kpAtVKpwd
>>>> AyExxc3fq/Zt74gFldp67vbYHMdGSkjA3taUY3P7d7mOp05ykKSR7HpOVs7RLOg=
>>>> =rc1U
>>>> -----END PGP SIGNATURE-----
>>>>
>>>
>>>
>>>
>>> --
>>> -- Jose Labra
>>>
>>>
>>
>>
>> --
>> Dimitris Kontokostas
>> Department of Computer Science, University of Leipzig
>> Research Group: http://aksw.org
>> Homepage:http://aksw.org/DimitrisKontokostas
>>
>
>
>
> --
> -- Jose Labra
>
>


-- 
Dimitris Kontokostas
Department of Computer Science, University of Leipzig
Research Group: http://aksw.org
Homepage:http://aksw.org/DimitrisKontokostas