- From: Tomasz Pluskiewicz <tomasz@t-code.pl>
- Date: Tue, 24 Sep 2024 09:49:09 +0200
- To: David Habgood <dcchabgood@gmail.com>
- Cc: public-shacl@w3.org
Hi David I’m the author of hypermedia-app/shape-to-query. Happy to compare notes on query generation any time. I felt like adding the custom SPORule is generally a safe thing to do because ultimately, to generate a query is quite an isolated use case. That said, I do agree with you that SPARQL seems to be missing the means to more accurately define properties. A catch-all is the extreme but I also found myself missing something like an “all except X” path. See https://github.com/w3c/shacl/issues/20 Good day, Tom On 24 September 2024 at 01:50:18, David Habgood (dcchabgood@gmail.com) wrote: > Thanks for the links, I'll have a play with those and see if I can generate > the sorts of queries I'm using. > I was linked to some work recently > https://github.com/hypermedia-app/shape-to-query which had similar > extensions to what I've added e.g. > https://shape-to-query.hypermedia.app/docs/#extension-spo-rule - this > prompted me to ask. > > The other context for the work I'm doing is it needs to combine a number of > things to generate SPARQL queries, some of which are specified in SHACL, > some not. To do this I've implemented the SPARQL Grammar as a set of Python > Pydantic models ( > https://github.com/Kurrawong/sparql-grammar-pydantic/tree/david/wip-complete-grammar/sparql_grammar_pydantic), > which makes it conceptually easy/safe to merge the different inputs and > generate valid/performant SPARQL queries. I might look to extend one of the > existing libraries to optionally produce SPARQL Grammar. > > On Tue, Sep 24, 2024 at 5:43 AM Kurt Cagle wrote: > > > Also, Flores Bakker has been working on an rdf representation of sparql > > that is coming along very well. There may be some overlap here. > > > > On Mon, Sep 23, 2024, 12:40 Kurt Cagle wrote: > > > >> This looks like it may be incredibly useful. > >> > >> On Mon, Sep 23, 2024, 12:07 Vladimir Alexiev < > >> vladimir.alexiev@ontotext.com> wrote: > >> > >>> These may be useful: > >>> > >>> https://shape-fragments.github.io/shape-fragments-spec/ > >>> https://github.com/Shape-Fragments/SHACL2SPARQL > >>> https://github.com/MaximeJakubowski/ssf_project > >>> https://github.com/MaximeJakubowski/sls_project > >>> > >>> > >>> On Mon, Sep 23, 2024 at 2:57 PM David Habgood > >>> wrote: > >>> > >>>> Hi all, > >>>> > >>>> I have a library which generates SPARQL queries from SHACL, mostly to > >>>> support two use cases. The first is listing sets of items, or focus nodes, > >>>> with constraints on which items are selected. I find this one quite > >>>> straightforward in SHACL. The second is describing individual objects, i.e. > >>>> which properties should be included/and or excluded when describing an > >>>> individual focus node. This one I find less clear - I can see there are a > >>>> series of SHACL predicates which are relevant, but it's unclear to me if > >>>> there's a "canonical" way this should be done. > >>>> > >>>> My question is whether there's a canonical way to do Use Case 2, and if > >>>> not, should this form part of the use cases SHACL covers in future or be a > >>>> part of a SHACL extension. > >>>> > >>>> In detail my use cases are: > >>>> > >>>> Use Case 1: > >>>> I want to describe the selection of a set of focus nodes, based on one > >>>> or a combination of the following focus node attributes: > >>>> - the class of the focus nodes > >>>> - the focus nodes' relationship to a specified node (e.g. is member of > >>>> x) > >>>> - the focus nodes' relationship to nodes of a specified class (e.g. the > >>>> dcat:Catalogs that contain any dcat:Dataset, dcat:Resource etc.) > >>>> - the presence or abscence of properties on the focus nodes, including > >>>> via path relations (inverse, sequence etc.) > >>>> > >>>> Use Case 2: > >>>> I want to describe a focus node by choosing one of the following two > >>>> methods: > >>>> 1. > >>>> a. including all direct properties, except: > >>>> - excluding any properties explicitly stated including via path > >>>> relations (inverse, sequence etc.). (e.g. when describing a dcat:Dataset, > >>>> not listing it's large number of members) > >>>> - including any properties explicitly stated via "indirect" path > >>>> relations (inverse, sequence etc.) > >>>> b. inclusion of blank nodes to a specified depth > >>>> > >>>> 2. > >>>> a. excluding all direct/indirect properties, except: > >>>> - including any properties explicitly stated via direct and indirect > >>>> path relations (inverse, sequence etc.) > >>>> b. inclusion of blank nodes to a specified depth > >>>> > >>>> If SHACL predicates are reused across both use cases I want a clear way > >>>> to distinguish which they are being used for. E.g. is a SHACL expression > >>>> which in some way specifies dcterms:hasPart being used to describe how to > >>>> select a set of focus nodes, or how to describe each focus node. At present > >>>> I've used extension predicates for the blank node depth and "include all > >>>> properties" concepts. > >>>> > >>>> Thanks, > >>>> David > >>>> > >>> >
Received on Tuesday, 24 September 2024 07:49:24 UTC