Re: [Specifications] How to document forbidden dereferencability (#216)

I'll clarify as it seems to me my pont has been stretched beyond my assertion.

I never stated that I wanted to *prevent* anyone from doing an HTTP GET on a URI they find, that'd be impossible by definition. I've stated that I didn't want to make assertions that I know not to be true, aka use schema:Person as an entity body in a request, even though such resources are not adressable directly in my API. You may or may not object that its good design, it's however implementations that are very common in ReSTful APIs, be it that they're RDF-centred first or not.

>> This is the issue - one of our community members has issues with this assumption.
> That's how Web architecture works though.

We use IRI identifiers for things that sometimes can or cannot be dereferenced, and we know, as an API, that fact, most of the time. The distinction is simple: A UA would render an `@id` as a clickable link if it can be resolved, and would not if it cannot. Having clickable URIs that lead to nowhere is just not a good sell for an API.

By making things hydra:Resource resolvable full stop, as the spec does right now, you can't *not* make it clickable. So I'm stuck. I expect: a schema:Person in that operation, and it does have an ID, but it's not an information resource, I know that. No way to communicate the fact.

Worse, hash URIs cannot be dereferenced over http by definition of the protocol (removing the hash is not the same URI anymore sincew we've had a URI spec, so the UA behaviour is beyond the point), even though they may be used as identifiers, making the whole dereferenceable statement pretty strange to begin with.

See fragid conversations around https://www.w3.org/2001/tag/issues.html#abstractComponentRefs-37

So right now as per the spec i can't decide to make the distinction between things that are supposed to be resolvable and which ones are not. If the guarantee was never intended, let's remove it and introduce another mechanism by which an API can declare that the `@id` can be de-referenced and make that guarantee a thing. Or we jsut remove it all and unless a GET is defined as an operation, we say there is no declared operation, and we consider the issue a done deal.

The conversations that go beyond that simple scenario I can't implement with the spec as it exists without doing some unnatural rdf gymnastics, bring in another specification along or what not, is not something i feel i can add to.

-- 
GitHub Notification of comment by serialseb
Please view or discuss this issue at https://github.com/HydraCG/Specifications/issues/216#issuecomment-640849961 using your GitHub account

Received on Monday, 8 June 2020 19:48:52 UTC