Re: [Specifications] Native SHACL support (#214)

>I've had issues with expect support for things that cannot be dereferenced

This should be fixed now as both `hydra:expects` and `hydra:returns` has `hydra:Resource` in their range (a class of dereferencable resources, which I think should be true in most cases).

>say, any schema.org class

Terms from schema.org are quite dereferencable - HTML returned contains some markup that carries RDF details (I don't remember whether it was Microdata or RDFa). While not that common and difficult to process by clients, it's RDF.

>I have had the same issue, which i've described at length before, where I do wish to document those things alongside the ApiDocumentation documents, so that a browser could do useful displaying of those.

I think that is not the purpose of hydra. You should use any of the mentioned schemas here to describe your data. Hydra should enable you to make some of those displayed things links or buttons.

>The specification itself never says that a browser or a client should know about rdfs at all

Good point. I just think that when working with RDF, rdfs is a must. Basic RDF concepts are formalized in RDFs, thus simple use of `rdfs:type` enforces a client to understand RDFs.

>All this to say two things: I don't really like breaking changes if I can avoid them

I agree. That's why I tend to hold some horses here :)

>It looks to me like it's never been tied to any schema system explictly so far, and I think it would benefit from not doing so.

That's right - hydra never coupled itself with any specific external vocabulary. I prefer to enable hydra for extension rather than to bind it to some other vocab.

>If we move everything to SHACL, then that's a breaking change

I don't think it'll gonna happen.

>I would suggest relaxing payload descriptions and supported classes

That's why I've pointed to it at the very beginning of the discussion: `I'd look rather at hydra:property or hydra:supportedClass so these can accept SHACL constructs.`

>I'm not even sure Hydra should provide its own MVP schema language out of the box

Let me help you - it shouldn't. I don't think hydra should come with neither data structure definition language nor query language.

>An extension specification that bridges SHACL and Hydra would get my vote, though. And I do think such a spec could be embraced as an official recommendation for a "Hydra Standard Profile".

My initial thought on using SHACL was a soft recommendation within the spec but some RDF constructs opening hydra for extensions is welcomed.

-- 
GitHub Notification of comment by alien-mcl
Please view or discuss this issue at https://github.com/HydraCG/Specifications/issues/214#issuecomment-633692657 using your GitHub account

Received on Monday, 25 May 2020 19:27:16 UTC