epos-dcat-ap_shapes update test on dcat:accessURL

[sgrellet]

Testing on WP15 files, Shacl playground complains about
dcat:accessURL pointing to a epos:WebService;
However a epos:WebService; is a rdfs:subClassOf rdfs:Resource ;
it seems the subtyping is not taken into account.
=> Need to add [
sh:class epos:WebService;
]

to the following test

sh:property [
sh:path dcat:accessURL ;
sh:or (
[
sh:class rdfs:Resource ;
]
[
sh:class hydra:Operation ;
]
[
sh:datatype xsd:anyURI ;
]
) ;
sh:minCount 1 ;
] ;

[rpaciello]

@sgrellet
If the type of Distribution is WEB SERVICE, dcat:accessURL refers to the Operation of the Web Service to which the Distribution conforms; while dct:conformsTo refers to the Web Service.

I corrected your WP15 RDF file.

[sgrellet]

@rpaciello
the pattern dcat:accessUrl -> webservice/operation and explicitely copy/pasting the hydra:entrypoint value into the hydra:template of the operation is weird to us

indeed a webservice having 1 entrypoint can have several hydra:operation(s). That's the case for all OGC services (don’t have time today to type it in our ttl).

In the proposed approach you allow to provide a different entrypoint value through the hydra:template (or copy/pasting that value could cause an issue for maintenance).

Best would be, for us, at the client level to 'concatenate'
hydra:entrypoint with information from hydra:template for the operation your client wants to activate

But we’ll talk about this afterwards the demonstrator :)

[ltrani]

Best would be, for us, at the client level to 'concatenate'
hydra:entrypoint with information from hydra:template for the operation your client wants to activate

I agree with this change. By using the relative path in Operation we would also avoid duplications when the same Webservice is deployed in multiple sites.
Indeed a good topic for discussions in Barcelona!