-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Hi Zachary,
ICV is indeed something interesting that we briefly expected before.
We didn't use it in the first place since pure SPARQL leaves us in the
smallest technical debt for this task.
Anyhow, we'll have a look at what advantages ICV has to offer.
Cheers,
Marcel
> <mailto:
marcel.k...@springernature.com>> wrote:
>
> Hi Evren, Zachary,
>
> thanks a lot for the explanation and the suggestion. Evren's hint
> should indeed help us to overcome this issue.
>
> Zachary, quick explanation: We automatically process the result of
> different SPARQL queries to make sure that our data follows some
> sort of contract. In this case here, the test passes when the query
> result is empty. But it wasn't - although the data itself was not
> faulty.
>
>
>> Thanks for sharing. Sounds somewhat like what ICV does [1]. Ever
>> try looking into using ICV for what you're doing? It might have
>> some advantages to the approach you're using. I'm just interested
>> in hearing how people are using Stardog, what worked, what
>> didn't, why. etc.
>
>> [1]
http://docs.stardog.com/#_validating_constraints
>
>
>
> Cheers, Marcel
>
>
> On 21/01/2017 23:28, Evren Sirin wrote:
>> Adding "HAVING (bound(?s))" at the end of the query would get
>> rid of the empty result.
>
>> Best, Evren
>
>> On Fri, Jan 20, 2017 at 4:03 PM, Zachary Whitley
>> <
zachary...@wavestrike.com
> <mailto:
zachary...@wavestrike.com>> wrote:
>>> I should probably acknowledge that I only said that I think
>>> the result that you're getting is correct without providing a
>>> solution to your problem. Is there a particular reason why you
>>> can't process that response?
>>>
>>> On Fri, Jan 20, 2017 at 9:51 AM, Zachary Whitley
>>> <
zachary...@wavestrike.com
<
https://groups.google.com/a/clarkparsia.com/forum/#%21topic/stardog/VcO5kylcEgU>
>>>>
>>>>
>>>>
> On Fri, Jan 20, 2017 at 5:36 AM, Marcel Karnstedt-Hulpus
>>>> <
marcel.k...@springernature.com
> <mailto:
marcel.k...@springernature.com>> wrote:
>>>>>
>> Hi,
>
>> when we run queries like
>
>> SELECT ?s (count(DISTINCT ?f) AS ?cnt) WHERE { ?s a nat:ABC . ?f
>> ?p ?o } GROUP BY ?s
>
>> where nat:ABC does not exist (i.e., there is no single binding
>> for ?s), we would expect an empty result.
>
>> But we rather get the result
>
>> s cnt 0
>
>> i.e., no binding for ?s but a 0 for ?cnt.
>
>> Why is that? It unfortunately breaks our automated processing of
>> the query.
>
>
>> Thanks, Marcel
>
>
>>>>>
>>>>> -- -- -- You received this message because you are
>>>>> subscribed to the C&P "Stardog" group. To post to this
>>>>> group, send email to
sta...@clarkparsia.com
>>>>> <mailto:
sta...@clarkparsia.com> To
> unsubscribe from this group,
>>>>> send email to
stardog+u...@clarkparsia.com
> <mailto:
stardog%2Bunsu...@clarkparsia.com> For more
>>>>>
stardog+u...@clarkparsia.com
> <mailto:
stardog%2Bunsu...@clarkparsia.com>.
>>>>>
>>>>
>>>
>>> -- -- -- You received this message because you are subscribed
>>> to the C&P "Stardog" group. To post to this group, send email
>>> to
sta...@clarkparsia.com <mailto:
sta...@clarkparsia.com> To
> unsubscribe from this group, send
>>> email to
stardog+u...@clarkparsia.com
> <mailto:
stardog%2Bunsu...@clarkparsia.com> For more options,
> <
http://groups.google.com/a/clarkparsia.com/group/stardog?hl=en>
>
>
>
> -- -- -- You received this message because you are subscribed to
> the C&P "Stardog" group. To post to this group, send email to
>
sta...@clarkparsia.com <mailto:
sta...@clarkparsia.com> To
> unsubscribe from this group, send email to
>
stardog+u...@clarkparsia.com
> <mailto:
stardog%2Bunsu...@clarkparsia.com> For more options,
>
stardog+u...@clarkparsia.com
> <mailto:
stardog%2Bunsu...@clarkparsia.com>.
>
>
> -- -- -- You received this message because you are subscribed to
> the C&P "Stardog" group. To post to this group, send email to
>
sta...@clarkparsia.com To unsubscribe from this group, send email
> to
stardog+u...@clarkparsia.com For more options, visit this
>
stardog+u...@clarkparsia.com
> <mailto:
stardog+u...@clarkparsia.com>.
iQEbBAEBCgAGBQJYihFEAAoJELjmZAjIQprmdkAH+It2yOt5rNj6uIg9+IG5st34
5gq8oBXmwwjwcSPk9fvtAXKECPGGZI2UM+54x0iECBf77RDT6z8RZAqQwdRUrvtK
Xia7b/VtyUgp7Xg2JMO5hb4m9Gt2zJjZ8ZgKVNh5GOBCbOYEGYC6tLO15v3MKiNh
Jol3PIxD2FHZwlnhsFlAtVKfTuUmaVGnBkSpjcyPC2QoATPnmZKWokH5PZ21hNh1
7pdQvJRSVnPck/J5rNCI//DSAPFaU1DmOF2xbAYgeX96i5wbkPnWAQu+eOOCXuBE
TBEE3XI4C5Hjh4nzsR1dRoO4RKzl4NqtnTsw4nlieS5yGl1qYPZ/An2upFN0EQ==
=CdoA
-----END PGP SIGNATURE-----