W3C home > Mailing lists > Public > public-hydra@w3.org > July 2014

RE: Questions

From: Markus Lanthaler <markus.lanthaler@gmx.net>
Date: Mon, 7 Jul 2014 19:36:06 +0200
To: <public-hydra@w3.org>
Cc: "'Bieg Mauro'" <mauro.bieg@inf.ethz.ch>
Message-ID: <049b01cf9a09$efa00aa0$cee01fe0$@gmx.net>
Hi Mauro,

On 4 Jul 2014 at 13:59, Bieg  Mauro wrote:
> Thanks to Markus for answering my first question on GitHub even though
> that seems not to be the place to ask questions.

Yeah, we try to keep all discussions here on the list so that everyone can
participate and that everything is properly archived.


> So here I am: on the mailing list (without markdown-support...)
> with three more:

Welcome :-) It would be great if you could also "officially" join the Hydra
W3C Community Group at

  http://www.w3.org/community/hydra/participants


> 1. Is the intended usage of Hydra that I might have a `vocab:User` be
> both a `hydra:Class` and a `schema:Person` ? Or would you recommend
> setting up a mapping from the user herself to her representation as a
> `hydra:Class`? (example from http://www.markus-lanthaler.com/hydra
> /api-demo/contexts/vocab#User)

I'm not sure I understand your question. I interpret it as follows: Is it
better that
  a) vocab:User is a subclass of both hydra:Class and schema:Person or
  b) if a specific user (e.g., /users/1) is declared as being an instance of
both vocab:User (which is a hydra:Class) and schema:Person

If that's your question, then the answer is that in most cases it doesn't
really matter which approach you choose. Clients that only understand
schema:Person and just consume the data without further interacting with the
API (i.e., clients not interest in Hydra), however, might prefer approach b)
since they won't dereference vocab:User to check whether it is a subclass of
schema:Person (which is the only type they understand). Approach a) on the
other hand has the advantage that user representations look somewhat cleaner
and that the API might appear to be simpler as there's only one type that's
used everywhere.

Please note that you can also mix a) and b), i.e., declare vocab:User to be
a subclass of hydra:Class and schema:Person and nevertheless declare
/users/1 to be of type vocab:User *and* schema:Person. This is not wrong but
redundant for clients that interpret the class relationships.


> 2. `http://www.markus-lanthaler.com/hydra/api-
> demo/contexts/Collection.jsonld` defines `members` as
> `http://www.w3.org/ns/hydra/core#members` but it should be
> `http://www.w3.org/ns/hydra/core#members`, i.e. "member" and not
> "members", or am I missing something?

No, you are completely right. Apparently I forgot to update the demo. I just
fixed it.

 
> 3. I wrote up this small [JSON-LD
> tutorial](http://mb21.github.io/blog/tech/2014/07/03/JSON-LD-
> intro.html) to spell some things out for me, might help other people
> as well... Corrections?

Nice. I found no errors, the only thing you might wanna change is
"homepage": "../home" as the base IRI is already at the top level
(http://manu.sporny.org/me)... or you simply append a / to the base IRI.


> For example, there is really no way to specify
> the `rdf:type` of a property (like "issues") in one single context,

No, you can't specify the rdf:type of a property. You have to specify that
inline or fall back to use the property's rdfs:range.


> right? If I want to have it all in one file, I'll have to do something
> like:
> 
  > [ {
    > "@context": {
      > "hydra": "http://www.w3.org/ns/hydra/core#",
      > "vocab": "http://www.markus-lanthaler.com/hydra/api-demo/vocab#",
      > "issues": "vocab:EntryPoint/issues"
    > },
    > "@id": "http://www.markus-lanthaler.com/hydra/api-demo/",
    > "@type": "vocab:EntryPoint",
    > "issues": {
      > "@id": "http://www.markus-lanthaler.com/hydra/api-demo/issues/",
      > "@type": "hydra:Collection"
    > }
  > },
  > {
    > "@context": {
      > "hydra": "http://www.w3.org/ns/hydra/core#",
      > "vocab": "http://www.markus-lanthaler.com/hydra/api-demo/vocab#"
    > },
    > "@id": "vocab:EntryPoint/issues",
    > "@type": "hydra:Link",
    > "description": "The collection of all issues"
  > } ]


You could combine the two contexts by using the @graph keyword to make the
default graph explicit:

   {
    "@context": {
      "hydra": "http://www.w3.org/ns/hydra/core#",
      "vocab": "http://www.markus-lanthaler.com/hydra/api-demo/vocab#",
      "issues": "vocab:EntryPoint/issues"
    },
    "@graph": [
      {
        "@id": "http://www.markus-lanthaler.com/hydra/api-demo/",
        "@type": "vocab:EntryPoint",
        "issues": {
          "@id": "http://www.markus-lanthaler.com/hydra/api-demo/issues/",
          "@type": "hydra:Collection"
      },
      {
        "@id": "vocab:EntryPoint/issues",
        "@type": "hydra:Link",
        "description": "The collection of all issues"
      }
    ]
  }

Don't add any other statements to the top-level object as otherwise it will
turn into a named graph. See http://www.w3.org/TR/json-ld/#named-graphs for
the complete explanation of this feature.


HTH,
Markus



--
Markus Lanthaler
@markuslanthaler
Received on Monday, 7 July 2014 17:36:37 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:29:42 UTC