Re: Anyone have recipes for ephemeral use of Jena SPARQL + Colab notebooks?

[Nicola Vitucci]

Hi Dan,

Have you thought about launching Fuseki (for instance as a standalone
server) and using Python's SPARQLWrapper to wrap and query the endpoint?

Nicola

Il giorno mer 3 giu 2020 alle ore 21:55 Dan Brickley  ha
scritto:

> Hi folks
>
> I'm digging around to see if I'm re-inventing wheels here, ...
>
> Trying to use Jena's SPARQL support from within Google Colab. This is a
> python notebook hosting service that gives you ephemeral environment where
> you can install Java and commandline tools etc., populate with data, and
> run python notebook style analysis against them.
>
> Any example of doing it wrong is in
>
> https://colab.sandbox.google.com/drive/1GVQaP5t8G-NRLAmEvVSp8k5MnsrfttDP#
>
> - it only uses commandline tools
> - it doesn't pull the SPARQL results back into Python
> - I didn't investigate Fuseki
>
> Has anyone glued these things together in a more robust manner?
>
> Thanks for any pointers,
>
> Dan
>
> >
>

Re: one jena-shacl question - was Re: two jena-shacl questions

[Chris Tomlinson]

Hi Andy,

Thank you so much for your patience and help. I think I’ve got a handle on 
things now and will forge ahead. 

I appreciate you raising JENA-1905 
, JENA-1906 
, and JENA-1907 
. I’ll comment on the issues 
as appropriate.

Thank you again,
Chris


> On Jun 1, 2020, at 4:44 PM, Andy Seaborne  wrote:
> 
> 
> 
> On 01/06/2020 21:08, Chris Tomlinson wrote:
>> Hi Andy,
>> Not trying to be pedantic below but I’m trying to understand how to think in 
>> shacl and establish some expectations of the validation process.
> 
> If it help, the general pattern is
> 
> Target ->
>  (Node shape -> property shape->)*
>  Constraint*
> 
>>> On May 31, 2020, at 9:40 AM, Andy Seaborne  wrote:
>>> 
>>> Do we agree that this is a test case?
>>> (one file, data and shapes combined)
>>> Only command line tools needed.
>> I agree that the combined data and shapes file exhibits differences in 
>> report results, when interchanging bds:PersonShape and bds:PersonLocalShape.
>>> 
>>> @prefix rdf:    .
>>> @prefix rdfs:   .
>>> @prefix sh: .
>>> @prefix bdo:    .
>>> @prefix bdr:    .
>>> @prefix bds:    .
>>> 
>>> ## Data:
>>> 
>>> bdr:NM0895CB6787E8AC6E
>>> a   bdo:PersonName ;
>>> .
>>> 
>>> bdr:P707  a  bdo:Person ;
>>>bdo:personName   bdr:NM0895CB6787E8AC6E ;
>>> .
>>> 
>>> ## Shapes:
>>> 
>>> #bds:PersonShape   # 2
>>> bds:PersonLocalShape  # 1
>>>sh:property bds:PersonShape-personName ;
>>>sh:targetClass  bdo:Person ;
>>> .
>>> 
>>> bds:PersonShape-personName
>>>sh:message  "PersonName is not well-formed, wrong Class or missing 
>>> rdfs:label"@en ;
>>>sh:node bds:PersonNameShape ;
>>>sh:path bdo:personName ;
>>> .
>>> 
>>> bds:PersonNameShape  a  sh:NodeShape ;
>>>sh:property bds:PersonNameShape-personNameLabel ;
>>>sh:targetClass  bdo:PersonName ;
>>> .
>>> 
>>> bds:PersonNameShape-personNameLabel
>>>sh:message  ":PersonName must have exactly one rdfs:label"@en ;
>>>sh:minCount 1 ;
>>>sh:path rdfs:label ;
>>> .
>>> 
>>> 
>>> The differences seems to be that the hash order is different and it affects 
>>> finding targets, combined with the fact that targets are nested:
>> I see JENA-1907  raises the 
>> issue; I understand:
>>> If A is processed first as a target then the parser shapes now includes B 
>>> so processing B is skipped.
>>> Note - the effect is only in the number of times constriants are executed , 
>>> once or twice, not whether they are omitted.
>> to say that, in the current test case w/ the hash order issue, when nesting 
>> occurs owing to sh:node, then when a violation is found by (A) 
>> bds:PersonShape-personName, then the validation does not "go deeper" to 
>> consider (B) bds:PersonNameShape, by itself. W/o sh:node, in 
>> bds:PersonShape-personName, then both  bds:PersonShape-personName and 
>> bds:PersonNameShape are parsed as independent targets and  executed 
>> independently.
>>> bds:PersonLocalShape (target)
>>> -> bds:PersonLocalShape
>>>   -> bds:PersonNameShape (target)
>>> -> bds:PersonNameShape-personNameLabel
>> I think the second line above is supposed to be
>> -> bds:PersonShape-personName
>>> Both targets match bdr:P707, one by class, one by property.
>> I understand the NodeShape, bds:PersonLocalShape, matching bdr:P707, 
>> meaning, to me, that the constraints expressed in that shape need to be 
>> evaluated w/ P707 being the subject (== focus node). I take this to be “by 
>> class”.
>> I do not understand how NodeShape, bds:PersonNameShape, matches bdr:P707. I 
>> think bds:PersonNameShape matches bdr:NM0895CB6787E8AC6E because of 
>> sh:targetClass bdo:PersonName.
> 
> 1/
> bds:PersonShape
>  sh:targetClass  bdo:Person
>  -> bdr:P707
> 
> and is has
>  sh:property bds:PersonShape-personName ;
> ->
> sh:node bds:PersonNameShape ;
> ->
> sh:property bds:PersonNameShape-personNameLabel ;
> 
> 2/
> bds:PersonNameShape  a  sh:NodeShape ;
>sh:property bds:PersonNameShape-personNameLabel ;
>sh:targetClass  bdo:PersonName ; <-- which is part of bdr:P707
> ->  bdr:NM0895CB6787E8AC6E ;
> 
> so two ways to get to bds:PersonNameShape-personNameLabel from target 
> declarations.
> 
> (try "shacl validate -v")
> 
> In case1: you can see the paths:
> 2 targets.
> each with one focus node
> leading to the same property shape /PersonNameShape-personNameLabel
> which has a constraint.
> 
> (I checked the spec and it is onlt says to execute once if the same 

Anyone have recipes for ephemeral use of Jena SPARQL + Colab notebooks?

[Dan Brickley]

Hi folks

I'm digging around to see if I'm re-inventing wheels here, ...

Trying to use Jena's SPARQL support from within Google Colab. This is a
python notebook hosting service that gives you ephemeral environment where
you can install Java and commandline tools etc., populate with data, and
run python notebook style analysis against them.

Any example of doing it wrong is in

https://colab.sandbox.google.com/drive/1GVQaP5t8G-NRLAmEvVSp8k5MnsrfttDP#

- it only uses commandline tools
- it doesn't pull the SPARQL results back into Python
- I didn't investigate Fuseki

Has anyone glued these things together in a more robust manner?

Thanks for any pointers,

Dan

>