Re: Question: SHACL for describing parameterized operations?

On 29/08/2017 17:21, Ruben Taelman wrote:
> Dear Holger,
>
> Thank you for your answer.
> I'll try to clarify my use case a bit more.
>
> The operation I mentioned before represents an API call, which is 
> described using the Hydra vocabulary [1].
> At the moment, we describe triple pattern queries as follows:
>
> _:search hydra:template  "http://example.org{?subject,predicate,object}";
>  hydra:variableRepresentation hydra:ExplicitRepresentation;
>  hydra:mapping                        _:subject, _:predicate, _:object;
> _:subject hydra:variable "subject";
> hydra:property rdf:subject.
> _:predicatehydra:variable "predicate";
> hydra:property rdf:predicate.
> _:object hydra:variable "object";
> hydra:property rdf:object.
>
> Next to that, we also want to describe the RDF results of this API call,
> where the _:subject, _:predicate and _:object variables are used as 
> parameters.
> Which we could indeed do using SHACL-SPARQL as you suggested:

In this case you cannot use blank nodes, e.g. _:subject needs to be 
replaced with ex:subject. But compared to the syntax above, you'd get 
the variable name "for free" because it's always the local name of the 
property.

>
> _:search hydra:resultShape ex:findMatchingTriples.
> ex:findMatchingTriples
>     sh:parameter [
>         sh:path _:subject ;
>         sh:order 0 ;
> sh:nodeKind sh:BlankNodeOrIRI ;
>     ] ;
>     sh:parameter [
>         sh:path _:predicate ;
>         sh:order 1 ;
> sh:nodeKind sh:IRI ;
>     ] ;
>     sh:parameter [
>         sh:path _:object ;
>         sh:order 2 ;
>     ] ;
> sh:propertyValidator [
> a sh:SPARQLSelectValidator ;
> sh:select """
> SELECT ?subject ?predicate ?object
> WHERE {
> ?subject ?predicate ?object .
> }
> """
> ] .

I don't think using sh:propertyValidator is the best choice here, nor is 
it necessary since you are not using validation here. Why not just make 
the class of ex:findMatchingTriples a subClass of both 
sh:Parameterizable and sh:SPARQLSelectExecutable, and then use sh:select 
directly as in

_:search hydra:resultShape ex:findMatchingTriples.
ex:findMatchingTriples
     sh:parameter [
         sh:path _:subject ;
         sh:order 0 ;
         sh:nodeKind sh:BlankNodeOrIRI ;
     ] ;
     sh:parameter [
         sh:path _:predicate ;
         sh:order 1 ;
         sh:nodeKind sh:IRI ;
     ] ;
     sh:parameter [
         sh:path _:object ;
         sh:order 2 ;
     ] ;
     sh:prefixes ... (if needed) ;
sh:select """
SELECT ?subject ?predicate ?object
WHERE {
?subject ?predicate ?object .
}
""" .

Are the values always produced by SPARQL queries? Then this sounds like 
a reasonable solution to me.

>
> This seems like a solution that would definitely work,
> but I'm just wondering what the advantage of this SHACL-based definition
> would be compared to a SPIN-based definition, such as the following:
>
> _:search hydra:resultShape ex:findMatchingTriplesAlt.
> ex:findMatchingTriplesAlt
> my:hasParameters ( _:subject, _:predicate, _:object );
>         a sp:Select;
> sp:resultVariables ( _:subject, _:predicate, _:object );
>         sp:where ([
> sp:subject _:subject;
> sp:predicate _:predicate;
> sp:object _:object
>         ]).
>
> One obvious advantage of SHACL is that it's a W3C recommendation.
> But to me, it seems like SPIN might be more fitting to our use case,
> as there is an explicit RDF-based link between the parameters of the 
> API call
> and the parameters within the query.
>
> Furthermore, this might enable other RDF-based techniques (such as 
> reasoners)
> to take advantage of this query structure, which would not be possible 
> with the SHACL definition as the query is text-based.
>
> What is your opinion on using SPIN or SHACL in this case?

For a general comparison between SPIN and SHACL, see

     http://spinrdf.org/spin-shacl.html

I cannot make the decision for you, clearly there are advantages in 
having an explicit representation of queries as RDF triples, but also 
some significant costs (in tooling and readability for humans). The 
SHACL syntax offers the benefit of having an explicit declaration of the 
constraints that apply to the parameters - not just sh:nodeKind but also 
sh:datatype, sh:minInclusive etc - in case these might be of use. And 
yes, SHACL is an official standard for which you may get better buy-in 
from your user community.

Holger


>
> Kind regards,
> Ruben Taelman
>
> [1] http://www.hydra-cg.com/spec/latest/core/
>
> On 29 August 2017 at 01:28:10, Holger Knublauch 
> (holger@topquadrant.com <mailto:holger@topquadrant.com>) wrote:
>
>> Hi Ruben,
>>
>> it is unclear to me what exactly you are attempting to represent. 
>> Below you present an outline for a solution but the problem statement 
>> isn't clear. Could you elaborate a bit?
>>
>> Note that the SHACL vocabulary (see TTL file) includes the class 
>> sh:Parameterizable that can be used as superclass of all kinds of 
>> "templates". For example to state that something takes three 
>> arguments, you could do
>>
>> my:Operation rdfs:subClassOf sh:Parameterizable .
>>
>> ex:findMatchingTriples
>>     a my:Operation ;
>>     sh:parameter [
>>         sh:path ex:subject ;
>>         sh:order 0 ;
>>         sh:nodeKind sh:BlankNodeOrIRI ;
>>     ] ;
>>     sh:parameter [
>>         sh:path ex:predicate ;
>>         sh:order 1 ;
>>         sh:nodeKind sh:IRI ;
>>     ] ;
>>     sh:parameter [
>>         sh:path ex:object ;
>>         sh:order 2 ;
>>     ] ;
>>     ...
>>
>> (and then attach whatever you like as other triples to the 
>> ex:findMatchingTriples - in the case of SHACL-SPARQL there are SPARQL 
>> queries, in the case of SHACL-JS there are JS snippets).
>>
>> The above may be on the wrong meta-level, but as I said I don't 
>> really understand your use case yet.
>>
>> Regards
>> Holger
>>
>>
>>
>> On 28/08/2017 21:41, Ruben Taelman wrote:
>>> Dear all,
>>>
>>> I have a question regarding the potential use of SHACL for a certain 
>>> use-case,
>>> and I'm wondering if someone here can help me identify whether or 
>>> not SHACL is a good solution for this.
>>>
>>> I am looking for a vocabulary that can declaratively describe RDF 
>>> results
>>> of a certain operation, based on certain parameters.
>>>
>>> For example, assume the following operation can evaluate triple 
>>> pattern queries:
>>> findMatchingTriples(subject, predicate, object)
>>>
>>> As far as I can see, SHACL doesn't provide a way to bind 'variables' 
>>> to nodes in a shape.
>>> The closest I have come to describing such a triple pattern operation
>>> is using the following (invalid) SHACL shape:
>>>
>>> _:shape a sh:NodeShape;
>>>       sh:targetNode _:subject;
>>>       sh:property [
>>>           sh:path _:predicate;
>>>           sh:hasValue _:object.
>>>       ].
>>>
>>> _:subject, _:predicate and _:object refer to the variable parameters 
>>> of the operation.
>>>
>>> I assume I need some kind of abstraction layer above SHACL,
>>> that basically 'instantiates' SHACL shapes based on certain parameters.
>>>
>>> So my question is:
>>> is such an abstraction already possible in some form, or are there 
>>> future plans for something like this?
>>> Or would you suggest using a SPARQL-based vocabulary for this, such 
>>> as SPIN,
>>> as I don't really need SHACL's validation and constraint 
>>> checking-features.
>>>
>>> Kind regards,
>>> Ruben Taelman
>>