Re: Implementation feasibility

>
> 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.

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.

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.

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