Re: remove hydra:Resource and hydra:Class (ISSUE-90)

> Right, but the goal is not to find out whether they are dereferenceable or
> not but whether it is worth (from the publishers POV) to follow them. 

That's not how they are defined and used in the Hydra Core Vocabulary.

> It's like putting URLs in the content (text) of an HTML document vs. marking
> them up as links.

I disagree.
With Linked Data, URLs in RDF are links, cfr. what Kingsley said:
>> A hyperlink (e.g., HTTP URI) is just a kind of identifier (naming mechanism) for entity identification. That's fundamental, in regards to Web Architecture.

> You could write a regex that finds all URLs in text,
> includes all namespace declaration etc. and follows them. Or you just follow
> things that have been marked as being hyperlinks and thus intended to be
> followed.

Users want to be able to follow any URL.
If a URL is not made “clickable”, it's nearly always omission of the publisher.
Then we default to copy/paste, but still dereference.

>> Indeed, every resource that is _not_ labeled with hydra:Resource,
>> but still dereferences, is by definition a hydra:Resource.
> 
> I can see how you come to that conclusion based on its current definition
> but that wasn't the intention.

Yeah. To me, an indication that we really need something else.

>> So "whether it's worth being checked" cannot be derived
>> from the presence of hydra:Resource,
>> as all (HTTP[S]) resources are worth being checked
>> until indicated otherwise-which hydra:Resource cannot.
> 
> When we discuss these things, we always operate in the context of a specific
> Web API.

I hope not :-) Cooler things are possible if we don't.

> the absence of
> hydra:Resource should be seen as a very strong signal that it isn't worth
> dereferencing a URI.

That interpretation is not possible under the RDF model.
We have a lot of freedom, but we cannot bend the model.

>> I do understand the purpose of hydra:Resource and hydra:Class,
>> but I strongly feel we have chosen the wrong way of addressing that purpose.
> 
> OK, so, in your opinion. How could we address that purpose then?

<resourceA> hydra:dereferenceable true.
<resourceB> hydra:dereferenceable false.

This mechanism allows for both interpretations, without bending the model.

Even though I still doubt the usefulness of marking dereferenceability as such,
if it is necessary for some reason, this seems a more appropriate way.

Note that what you _actually_ want to express is closer to
    <serverX> :says :statementY.
    GRAPH statementY {
        <clientY> :shouldDereference <resourceA>.
        <clientY> :shouldNotDereference <resourceB>.
    }
but nobody, including myself, will want to take things this far :-)
I just added this to show how much of a mismatch we currently have.

Best,

Ruben

Received on Wednesday, 14 January 2015 08:42:45 UTC