Re: SHACL to SPARQL

Hi Thomas,

That's probably most similar to my current approach - having a subselect
for selection of nodes then expanding the properties per node ("profiles")
outside of this, as per the example below. I didn't use SPARQL targets,
only SHACL Core, but as mentioned in the original message this required
some interpretation.

CONSTRUCT {
    <construct_triples + construct_tss_list>
}
WHERE {
    # for listing queries only:
    { SELECT ?focus_node <innser_select_vars>
        WHERE {
            <inner_select_tssp_list>
            <inner_select_gpnt>
        }
        ORDER BY <order_by_direction>(<order_by>)
        LIMIT <limit>
        OFFSET <offset>
    }
    <profile_triples>
    <profile_gpnt>
}

David

On Wed, Sep 25, 2024 at 10:50 PM Thomas Francart <thomas.francart@sparna.fr>
wrote:

> Hi
>
> We also have a SHACL-to-SPARQL generator which was designed to extract a
> subset of a larger knowledge that corresponds to the SHACL specification of
> the content of a dataset.
> Form and documentation : https://shacl-play.sparna.fr/play/sparql
> Code :
> https://github.com/sparna-git/shacl-play/tree/master/shacl-sparql-query-gen
>
> Thomas
>
>
> Le lun. 23 sept. 2024 à 14:57, David Habgood <dcchabgood@gmail.com> a
> écrit :
>
>> 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
>>
>
>
> --
>
> *Thomas Francart* -* SPARN**A*
> linked *data* | domain *ontologies* | *knowledge* graphs
> blog : blog.sparna.fr, site : sparna.fr, linkedin :
> fr.linkedin.com/in/thomasfrancart
> tel :  +33 (0)6.71.11.25.97
>