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

Wow.. I missed quite some fun during the last couple of days :-) Great
discussions. I'll try to summarize the points I found most
interesting/important by quoting various things and commenting a few of
them. Unfortunately, the mail got quite long due to that.

tl;dr
I'm skeptical about removing this concepts. For me, the distinction between
an identifier and a hyperlink is a quite important one. We could surely try
to tweak the design. I would, e.g., be fine with renaming hydra:Resource to
hydra:WebResource or something similar to make it more explicit and less
confusing (if it really is!?) for people with SemWeb background. I wouldn't
like to prematurely remove them as I think the concepts themselves are quite
important.


On 5 Jan 2015 at 16:17, Thomas Hoppe wrote:
> I thought about this in the past but settled with the simple fact that
> the difference is the fact that hydra:Resource hints for the ability to
> dereference.

On 5 Jan 2015 at 16:30, Ruben Verborgh wrote: 
> But that's not an ontological concern.
> An ontology relates concepts;
> whether or not those concepts dereference
> depends on the addressing scheme you use to identify them.

That's not really true. We need to distinguish between identifiers and
hyperlinks. RDF, unfortunately IMO, *only* deals with identifiers. I tried
to introduce to change that in the past. If you are interested, read this
thread:

  http://lists.w3.org/Archives/Public/public-rdf-wg/2012Nov/0009.html


On 11 Jan 2015 at 09:31, John Walker wrote:
> I think indicating/suggesting that it may be useful to dereference
> a resource (perhaps depending on context) might be useful.

On 11 Jan 2015 at 20:39, Ruben Verborgh wrote:
> True-but the concrete question here is:
> do we need to alienate ourselves from other vocabularies
> by using different notions of Resource and Class,
> simply to indicate dereferenceability?

I don't see how we "alienate ourselves from other vocabularies". But I think
its because you seem to assume they have been introduced purely to model
Hydra itself:

On 7 Jan 2015 at 11:53, Ruben Verborgh wrote:
> I would remove, because they are (needlessly) used in the modeling.
On 12 Jan 2015 at 13:17, Ruben Verborgh wrote:
> hydra:Resource and hydra:Class [...] are only used to build the ontology.
> People don't need them to describe an API.

Which is certainly not true. They have primarily being introduced to allow
it to express that an RDF identifier is also a hyperlink.

> Furthermore, our own ontology is the only one that uses it.

At the moment that's probably true. But hopefully that will change :-)


On Thursday, January 08, 2015 11:17 PM, John Walker wrote:
> I struggle to think of practical cases for use of hydra:Resource that
> could not be covered by hydra:Link.

On Friday, January 09, 2015 6:29 PM, Dietrich Schulten wrote:
> The use case is: mark a hyperlink as dereferenceable in-place.

On 10 Jan 2015 at 09:49, Ruben Verborgh wrote: 
> But then again, what tangible benefit does this give?
> 
> To dereference it, you must GET it.
> To check whether it is dereferenceable, you must GET it.

To know whether it's worth (or expected) to being checked.

> Nothing is gained by marking it dereferenceable upfront.

Efficiency and performance improvements on the client and reduced load on
the server. As Tomasz says


On 12 Jan 2015 at 21:26, Tomasz Pluskiewicz wrote:
> However the reason for hydra:Class as described in the specification
> is the without guidance the client would have to blindly try
> dereferencing everything.
 
On 12 Jan 2015 at 22:22, Ruben Verborgh wrote:
> That reason is incorrect.

I don't think so.

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

On 7 Jan 2015 at 11:53, Ruben Verborgh wrote:
> All things that were hydra:Resource will still be dereferenceable;
> like all things in commonly used ontologies are anyway.

Ever tried to dereference xsd:integer to get its definition?


On Monday, January 12, 2015 11:04 AM, McBennett, Pat wrote:
> Just my 2cents, but this issue has bugged me for a long time now (and
> not just in Hydra). The argument for keeping Hydra completely self-
> contained, and therefore the only vocab a new user needs to see or
> understand is laudable, but I think a better balance can be struck
> between that and gently introducing new users to the huge benefits of
> reusing existing well-known vocabularies. So couldn't we reuse really
> basic and simple existing vocabs, ones that won't scare off, overly
> burden or confuse new users?

Sure. The difficult question is what existing well-known vocabularies don't
scare users off? 


> I'd certainly agree that 'owl' is way too much
[...] 
> But for instance, RDFS only has 15 terms (so not daunting in terms of
> size), and it includes really useful terms like 'label', 'comment',
> 'seeAlso', 'domain', 'range' and 'member'. I don't think a new user
> needs to live in the RDF universe to grasp what those terms mean.

On Monday, January 12, 2015 11:03 PM, Holger Knublauch wrote:
> Unfortunately they do need to understand RDF for some of those - in
> particular rdfs:domain and rdfs:range have some surprising semantics
> that often confuse users. I would avoid those (and the RDF Shapes
> group may come up with cleaner alternatives). OTOH rdfs:label and
> comment are well-established.

I couldn't agree more with this. Just look at all the discussions we had on
this list regarding RDFS... and we certainly have people on this list which
are willing considerable time to understand it. It is confusing for almost
everyone that hasn't a Semantic Web background. Even the name itself is
misleading most people. RDF Schema is not a schema in a traditional sense.


On Monday, January 12, 2015 11:04 AM, McBennett, Pat wrote:
> I know we can map things like 'hydra:title' to 'dc:title' or
> 'rdfs:label' for the RDF-savvy audience, but I honestly think the cost

... and that's quite a big issue in practice. What should clients expect?
What should they look for? All of those terms?


> to new users of needing to be aware of a vocab as simple as RDFS is
> worth it in terms of reducing the footprint of Hydra itself, while
> also demonstrating the power of Linked Data by Hydra itself actually
> reusing existing vocabs (and it removes any need for inference or
> 'owl:sameAs' overhead for the RDF guys).

I think we can showcase that much better by using domain-specific
vocabularies (and Schema.org) in the examples. Hydra establishes the
framework that you fill with your domain-specific semantics (which are
defined in other vocabularies).


On 12 Jan 2015 at 12:50, Tomasz Pluskiewicz wrote:
> I certainly agree with Pat. I think that we should consider reusing
> common terms where possible. Unless there is some extra semantics we
> require, I don't see a reason to mint our own. I like the argument
> that this way Hydra will set itself as a good example for newcommers
> to the Semantic Web community. And frankly we should aspire to that
> role, because IMO JSON-LD and Hydra are likely to attract many
> developers to Linked Data and Semantic Web.

My counterargument would be to look at how successful that strategy was in
the past. It is extremely difficult for novice users to find the right
vocabularies and use them correctly. Most of the time the end result looks
like a patchwork that is quite difficult to understand. The Semantic Web
community needs to become a bit more pragmatic if it wants this stuff to get
used eventually.


On Monday, January 12, 2015 9:00 PM, John Walker wrote:
> The example was a little bit too simple, maybe better would be to
> think of a class like foaf:Person and property like foaf:knows.
> Another example is to be able to somehow describe that resources of
> type foaf:Person or in object position of foaf:knows can be DELETEd in
> my API without having to make a sub-class and sub-property of
> foaf:Person and foaf:knows respectively.

That's what ApiDocumentation is for. It allows you to assert things like
this which are only true in the context of the Web API it describes.



--
Markus Lanthaler
@markuslanthaler

Received on Monday, 12 January 2015 23:36:00 UTC