- From: Holger Knublauch <holger@topquadrant.com>
- Date: Fri, 22 May 2020 15:09:05 +1000
- To: public-shacl@w3.org
On 20/05/2020 20:48, Varytimou, Natasa (Refinitiv) wrote: > Hi all > > We also had a big performance issue with SHACL Sparql Targets which are incredible useful. > Is there anything that can be done to improve performance? > And the same question for Filters ( which I support that are useful to be included), will we have performance issues there as well? Yes, with whatever solution there will be worst case scenarios that may force a SHACL engine to do brute-force computations. With more flexibility comes more responsibility. Just like with a programming language you can implement infinite loops, yet they are incredibly useful in most cases. Holger > > > -----Original Message----- > From: Håvard Ottestad <hmottestad@gmail.com> > Sent: 20 May 2020 11:25 > To: Andy Seaborne <andy@apache.org> > Cc: public-shacl@w3.org > Subject: Re: SHACL target extension > > Hi Andy and Dimitris > > Filters look like particularly useful constructs. They also look very powerful, which is both good and bad. > > It’s quite close to what I want. I would want to have the filter run on all nodes in the data graph, essentially a sh:targetAllSubjects target. I think I saw something along those lines already, but I couldn’t find it now while writing this email. > > I can see that a natural extension would be to allow filters to be used as targets themselves, maybe through the SHACL Advanced sh:target property. > > Håvard > >> On 20 May 2020, at 10:29, Andy Seaborne <andy@apache.org> wrote: >> >> Nice! >> >> That would be a useful addition to SHACL both on targets and on property shapes. And for rules. >> >> Were there any other features that got dropped that the community might be interested in? >> >> Andy >> >> >>>> On 19/05/2020 22:29, Dimitris Kontokostas wrote: >>> Hi Håvard, >>> I think what you are after is something like the filter shape feature >>> (https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww >>> w.w3.org%2FTR%2F2016%2FWD-shacl-201608H%25C3%25A5vard14%2F%23filterSh >>> ape&data=02%7C01%7CNatasa.Varytimou%40refinitiv.com%7Ce6dc14407b7 >>> 34d54b27908d7fca8327d%7C71ad2f6261e244fc9e8586c2827f6de9%7C0%7C0%7C63 >>> 7255671647244813&sdata=9fkMStQVgoP4f8k3OKo4gaq4uampFgxMYbXuPjSH4q >>> A%3D&reserved=0 >>> <https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww >>> w.w3.org%2FTR%2F2016%2FWD-shacl-20160814%2F%23filterShape&data=02 >>> %7C01%7CNatasa.Varytimou%40refinitiv.com%7Ce6dc14407b734d54b27908d7fc >>> a8327d%7C71ad2f6261e244fc9e8586c2827f6de9%7C0%7C0%7C63725567164724481 >>> 3&sdata=dVeAUe7hfKbnliGxy5KVlNTE5Zs%2BE3f81z2GX%2BYFQfc%3D&re >>> served=0>) This is something that existed in the first versions of >>> SHACL but was dropped due to time restrictions near the end of the WG >>> Best, Dimitris >>>> On Tue, May 19, 2020 at 11:05 PM Håvard Ottestad <hmottestad@gmail.com <mailto:hmottestad@gmail.com>> wrote: >>> Hi James and Irene, >>> Thanks for the replies. >>> This is more a question of the standardisation aspect. Did anyone >>> discus including more elaborate target building blocks? There is >>> already sh:targetClass for rdf:type, but did anyone consider other >>> class constructs like skos:inScheme? >>> We already have two functional solutions within the current syntax: >>> - use sh:targetNode with sh:inverseProperty >>> - use SPARQL targets >>> The issue with these solutions are: >>> 1. Using sh:targetNode and sh:inverseProperty are much harder to >>> read than something like the compound target that we we >>> considering introducing. >>> 2. SPARQL targets take took long to evaluate for transactional >>> workloads. >>> Håvard >>>> On 19 May 2020, at 20:37, James Hudson <jameshudson3010@gmail.com >>>> <mailto:jameshudson3010@gmail.com>> wrote: >>>> You may want to check out: >>>> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fquestions%2F61323857%2Fwhat-is-the-difference-between-these-shape-graphs-which-use-shor&data=02%7C01%7CNatasa.Varytimou%40refinitiv.com%7Ce6dc14407b734d54b27908d7fca8327d%7C71ad2f6261e244fc9e8586c2827f6de9%7C0%7C0%7C637255671647244813&sdata=kjaTfSE9gI524M8kypS5LzuVtajKVemL7vMOWxlHfEw%3D&reserved=0 >>>> and >>>> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fquestions%2F61190422%2Fvalidating-that-every-subject-has-a-type-of-class&data=02%7C01%7CNatasa.Varytimou%40refinitiv.com%7Ce6dc14407b734d54b27908d7fca8327d%7C71ad2f6261e244fc9e8586c2827f6de9%7C0%7C0%7C637255671647244813&sdata=skAZd%2BVgGSCgD%2B5wEuPAuRV7XFUEcOlBJ78Ol0oWcGs%3D&reserved=0 >>>> and other SHACL questions and answers I have on SO. They may help >>>> you out. >>>> As Irene already pointed out, SPARQL-based targets will solve >>>> your problem. >>>> On Tue, May 19, 2020 at 11:39 AM Håvard Ottestad >>>> <hmottestad@gmail.com <mailto:hmottestad@gmail.com>> wrote: >>>> Hi, >>>> I’m the developer for the RDF4J SHACL implementation and we >>>> are looking into extending the targeting options in SHACL and >>>> are wondering if this is something that was discussed during >>>> the development of the standard or if anyone else has run >>>> into similar requirements. >>>> Essentially extending the current list of sh:targetNode, >>>> sh:targetClass, sh:targetSubjectsOf and sh:targetObjectsOf. >>>> Our use case can be summed up as. >>>> ex:Håvard ex:nationality ex:Norway; >>>> ex:norwegianID “12345612345”. >>>> Where we would essentially like to be able to add a shape >>>> that says that all Norwegian citizens should have a Norwegian >>>> ID number. >>>> We have been testing out the concept of a compound target. >>>> For our current tests we have used our own namespace like this: >>>> @prefix rdf4j-sh: <https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Frdf4j.org%2Fschema%2Frdf4j-shacl%23&data=02%7C01%7CNatasa.Varytimou%40refinitiv.com%7Ce6dc14407b734d54b27908d7fca8327d%7C71ad2f6261e244fc9e8586c2827f6de9%7C0%7C0%7C637255671647244813&sdata=ZmKYvssWhaW30oRKEkRqDpK6%2FizYr8tDe8xaPfdqvPc%3D&reserved=0> . >>>> ex:PersonShape >>>> a sh:NodeShape ; >>>> rdf4j-sh:compoundTarget [ >>>> rdf4j-sh:targetPredicate ex:nationality; >>>> rdf4j-sh:targetObject ex:Norway >>>> ]; >>>> sh:property [ >>>> sh:path ex:norwegianID ; >>>> sh:minCount 1 ; >>>> sh:maxCount 1 ; >>>> ] . >>>> We have also been thinking about allowing >>>> rdf4j-sh:targetObject to be have multiple values. >>>> I also realise that it’s possible to use inversePath to solve >>>> this same problem, but I feel it becomes hard to read and >>>> grasp the intent. >>>> ex:PersonShape >>>> a sh:NodeShape ; >>>> sh:targetNode ex:Norway; >>>> sh:property [ >>>> sh:path [sh:inversePath ex:nationality ]; >>>> sh:property [ >>>> sh:path ex:norwegianID ; >>>> sh:minCount 1 ; >>>> sh:maxCount 1 ; >>>> ] >>>> ] . >>>> Concurrently we have been testing the SHACL Advanced SPARQL >>>> targets. These allow us to do the same thing, but we are >>>> unable to achieve the same level of performance. In one of >>>> our benchmarks we see that SPARQL targets is 450x slower per >>>> transaction than compound targets. This is mostly due to our >>>> SHACL implementation being able to analyse the transactional >>>> changes and run a very minimal validation for compound >>>> targets. We do think that SPARQL targets could be >>>> considerably faster, but the design choices that allow for >>>> minimal transactional validation are currently also limiting >>>> our options for speeding up SPARQL targets. >>>> Does anyone know if this approach to a more flexible >>>> targeting has been considered as part of the spec? Or if >>>> someone has run into similar needs and is maybe considering >>>> implementing something similar. >>>> Cheers, >>>> Håvard >>> -- >>> Kontokostas Dimitris >
Received on Friday, 22 May 2020 05:09:23 UTC