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

On 1/12/15 6:35 PM, Markus Lanthaler wrote:
> 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.

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. Look closely are <link/>, "Link:", and various 
notations associated with RDF, in all cases you are looking at different 
the representation of different kinds of entity relationships 
facilitated by a predicate/property/relation.

<link rel="{some-relation} .../> is how this is achieved in HTML. 
Basically, @rel indicates Relation, and the &href indicates the HTTP URI 
that identifies the relation.


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

Yes, :WebResource or HttpResource (meaning its a resource on an HTTP 
network).

>   I wouldn't
> like to prematurely remove them as I think the concepts themselves are quite
> important.

Concepts are indeed important. Understanding them via discussion like 
this even better. That said, in endeavors such a this one, do factor in 
the background of contributors of these suggestions. We have an 
opportunity to make things clearer rather than murkier :)


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


-- 
Regards,

Kingsley Idehen	
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog 1: http://kidehen.blogspot.com
Personal Weblog 2: http://www.openlinksw.com/blog/~kidehen
Twitter Profile: https://twitter.com/kidehen
Google+ Profile: https://plus.google.com/+KingsleyIdehen/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen
Personal WebID: http://kingsley.idehen.net/dataspace/person/kidehen#this