W3C home > Mailing lists > Public > public-hydra@w3.org > January 2015

Re: remove hydra:Resource and hydra:Class

From: Tomasz Pluskiewicz <tomasz@t-code.pl>
Date: Mon, 12 Jan 2015 11:50:58 +0000
Message-ID: <9c81bb25a80586c28284953580a1308c@rainloop.t-code.pl>
To: public-hydra@w3.org
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.

Thanks,
Tom

January 12 2015 11:04 AM, "McBennett, Pat" <mcbennettp@dnb.com> 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?
> 
> I’d certainly agree that ‘owl’ is way too much, but I think reusing existing terms from Schema.org,
> RDFS and possibly Dublin Core would strike a perfectly reasonable balance here (NOTE: I don’t think
> the RDF vocab should be used, as it’s terms only refer to the mechanics of RDF, i.e. confusing
> things like ‘subject’, ‘predicate’, and ‘Statement’).
> 
> 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. The same applies for
> Dublin Core I think, and certainly for Schema.org (although their particular use of ‘title’ seems
> tied to job postings [1]!).
> 
> 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 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 don’t think that represents radical pureness, does it…?
> 
> Cheers,
> 
> Pat.
> 
> [1] – http://schema.org/title
> 
> From: Dietrich Schulten [mailto:ds@escalon.de]
> Sent: 12 January 2015 08:58
> To: public-hydra@w3.org
> Subject: Re: remove hydra:Resource and hydra:Class
> 
> and hydra:description. But you see where this is heading. People will have to learn about owl and
> rdfs before they can use hydra for their restful services. This is assuming that hydra is not only
> for people who live in the rdf universe.
> 
> For practical reasons and to ease adoption it is a good thing if it is sufficient to learn about
> one vocabulary that covers the semantics of a ReST Service, and domain-specific vocabularies on the
> other hand.
> Having one vocab also makes it quite easy to define a set of semantics a hydra-conformant client
> must, should and may support. Sure, I can say anything about any resource, but I cannot expect that
> the hydra client will understand everything I say.
> 
> At this point I do not think we should try to express as much as possible in pure rdfs and owl in
> the :ApiDocumentation and the resources themselves. Rather we need a "complete" set of semantics a
> hydra client can be expected to understand. The lithmus test for completeness: if a property or
> class may be useful for a restful service, it should be in hydra.
> 
> We must certainly strike a balance here. But the radical pureness seems not right to me.
> 
> Best regards,
> Dietrich
Received on Monday, 12 January 2015 11:51:31 UTC

This archive was generated by hypermail 2.3.1 : Monday, 12 January 2015 11:51:31 UTC