Re: How to express dereferenceability? (ISSUE-91)

On 2015-01-19 16:13, Ruben Verborgh wrote:
>> 	• Is being dereferenceable a characteristic (I hesitate to say "property" as that's a somewhat loaded term) of the URI or the resource that URI identifies?
>
> That's a crucial issue IMHO.
> Following the RDF spec, the properties/objects we add
> are characteristics of the underlying resource,
> not of the IRI by which its happens to be referred.
>
> As such, I think both proposed solutions
> (hydra:Resource / hydra:dereferenceable)
> are in conflict with the RDF spec.
>
> Note BTW that I personally don't agree
> that a server should express dereferenceability:
> - the server doesn't know what the client wants to do
> - the client can deference easily anyway
> However, I launched this issue because others think differently.
>

I do agree with Ruben in part. The server should not explicitly state 
that a resource is or even is not dereferencable. Given the nature of 
HTTP URIs we could assume that any single one is dereferencable or not. 
If a resource is not intended to be referenced it is in a way contrary 
to the point of Linked Data and an API. Either a literal not could be 
used (much like schema has contentURL for images) or maybe the resource 
shouldn't be included in the representation at all?

However it is true what others say, that the API, which Hydra is all 
about, should let the client which links to follow next given any 
resource. I have said it before, that I think properties should bear 
that responsibility. However I don't think any generic property is good 
enough. From the perspective of a developer designing an API, I think 
I'd want my API clean so that is mostly consists of terms, which are 
important for my domain. I think that introducing too much 
hydra:Resource / hydra:dereferencable / owl:sameAs will be mostly 
confusing to newcomers and simply clutter.

> Best,
>
> Ruben
>

Received on Monday, 19 January 2015 21:39:33 UTC