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

On 13 Jan 2015 at 09:51, Ruben Verborgh wrote:
>> On 12 Jan 2015 at 22:22, Ruben Verborgh wrote:
>>> A client's need to dereference something is not influenced in any way
>>> by marking that something as hydra:Class.
>>> Only a mechanism that says something is *not* dereferenceable can have
>>> such an influence.
>> 
>> It's not about the "need". Think of something simpler, something like a
>> crawler. It just follows hyperlinks. It shouldn't have to try to
dereference
>> every identifier it finds..
> 
> We shouldn't forget that an absence of hydra:Resource does not mean
anything.

I fear this will soon get philosophical :-)


> To clarify matters, I will discuss such a crawler in two situations.
> 
> 
> SITUATION 1: WITH HYDRA:RESOURCE
> 
> The crawler receives a document with 35 resources with an HTTP(S) URL.
> 30 of them are explicitly labeled with type hydra:Resource.
> 
> In order to find out whether the other 5 resources are dereferenceable,
> the crawler has to perform 5 GET requests.
> 3 of them dereference, 2 do not.

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. 


> SITUATION 2: WITHOUT HYDRA:RESOURCE
> 
> The crawler receives a document with 35 resources with an HTTP(S) URL.
> None of them have type hydra:Resource.
> 
> In order to find out whether the 35 resources are dereferenceable,
> the crawler has to perform 35 GET requests.

It's like putting URLs in the content (text) of an HTML document vs. marking
them up as links. 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.


[...]
> 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.

 
> 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. In a sense, that's a closed world. So, the absence of
hydra:Resource should be seen as a very strong signal that it isn't worth
dereferencing a URI.


> 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?


Thanks,
Markus


--
Markus Lanthaler
@markuslanthaler

Received on Tuesday, 13 January 2015 21:26:26 UTC