TemplatedLink cannot formally have supportedOperation

[alien-mcl]

TemplatedLink cannot formally have supportedOperation predicate

Currently, hydra:Link is allowed in domain of supportedOperation, but the hydra:TemplatedLink is not mentioned. I think this renders templated links incapable of having supported operations which is essential for defining operations with IRI template.

[tpluscode]

I kinda assumed that was immediately possible already.

What was the state of this in previous discussions?

[angelo-v]

This is related to https://github.com/HydraCG/Specifications/issues/196

[angelo-v]

Could you post a code example of what you want to do? What I understand from https://github.com/HydraCG/Specifications/issues/196 the domain of supportedOperation should only be hydra:Class and we should remove hydra:Link from the domain

[tpluscode]

I think... I agree

[angelo-v]

By the way my understanding of domain in RDF is different. stating ?property domain ?class does not limit the use of ?property to that class. It just means, that if the property is used on something, this can be assumed to be of type ?class. So if we actually put hydra:TemplatedLink to the domain of supportedOperation one could reason, that the resource that has the supportedOperation is of type hydra:TemplatedLink which will not be true in any case.

[angelo-v]

I just see, that the definition of schema:domainIncludes is indeed different from that of rdfs, but I still do not see, that it forbids the usage on other types

[tpluscode]

The assumption could be made with rdfs:domain. Hydra consciously uses schema:domainIncludes not to enforce these strong semantics. It is more of a hint AFAICT.

[tpluscode]

Of course you technically can use any property, anywhere. But we should define a framework of the "appropriate" usages so that APIs can act in expected ways.

Back to the initial subject. @alien-mcl, would it make sense to make TemplatedLink inherit from Link instead?

[alien-mcl]

Back to the initial subject. @alien-mcl, would it make sense to make TemplatedLink inherit from Link instead?

That was my first idea. TemplatedLink is logically a Link, thus I'm somehow surprised it is not stated that way. Other approach would be to add TemplatedLink to the domainIncludes where approriate - need to analyze possible consequences (especially when it comes to backward compatibility)

[angelo-v]

From the conference call: I understand a hydra:Link to refer to something that is dereferencable. But a hydra:TemplatedLink does mostly refer to a blank node, that is not dereferencable.

[tpluscode]

I'm still not sure about this. In practice I could accept an API where a property is used both with a concrete URI as well as a template. The client would have to decide how to act based on what the object is (either present a form or a link). Makes sense?

I'm mildly in favour of keeping the current solution. hydra:Link does have a fairly weak semantics. An indirect link could be acceptable.

But a hydra:TemplatedLink does mostly refer to a blank node, that is not dereferencable.

See, technically, the presence of an URL identifier determines (potential) dereferencability. Link is an additional hint to prevent clients from blindly GETing everything. A templated link is not so different, only with the URL being constructed by the client with extra input.

[angelo-v]

@tpluscode We can do it like this (it's quite pragmatical I guess), but than we should clearly state this in the spec.

[alien-mcl]

OK - I'll extend the PR related with proper spec change to clarify.

[alien-mcl]

Closing as it was resolved with PR #198