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

January 14 2015 9:43 AM, "Ruben Verborgh" <ruben.verborgh@ugent.be> wrote: 
>> 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:
> 
>> 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.
> 

But again, as Kingsley said, it's the predicate that informs the client that a URL could be dereferenced. Even if it's just a hint. Think <link />, <a href="" /> and Link: header. What if the server returns a resource like 

{ 
  "@context": { 
    "author": "dcterms:author"
  },
  "author": { "@id": "http://example/person/Tom" }
}

There is no indication that http://example/person/Tom is or isn't dereferencable. Does that mean that client should not try? Or assume that it's not dereferencable? The only solid way is to declare the dcterms:author relation as a Link.

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

Agreed. And I think that the conclusion is logical indeed in light of open world assumption. The problem is that the semantics of hydra:Resource. You cannot infer that a resource is hydra:Resource by using a reasoner for example. This may sound weird that I bring it up but I think that the word semantics is used is a different meaning than it usually is when talking about the Semantic Web.

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

This implies that every single resource that I want clients to dereference should be marked as hydra:Resource. It seems like a lot of redundant triples. Aren't most resources (in an API especially) dereferencable. It will be at least more practical to have a facility to mark them otherwise if required, as Ruben has suggested below and earlier.

And again I don't think we should be considering predicate and class URIs.

> That interpretation is not possible under the RDF model.
> We have a lot of freedom, but we cannot bend the model.
> 
>> 
>> 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 09:18:56 UTC