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

On Jan 13, 2015, at 1:26 PM, Markus Lanthaler <markus.lanthaler@gmx.net> wrote:
>
> 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.

Yes, but isn't this the purpose of marking a predicate a hydra:Link.
That seems to tell me what I need to know, indeed, to know a resource
is a hydra:Resource, I need a partial representation of the resource
to know its type, which I don't for a link. I think hydra:Link
provides everything we need.

Gregg

>> 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:39:09 UTC