Re: Introduction and a question about JSON-LD

Hi Markus,


Ok, I think I understand it now. However, would this be OK to do?


{

  "@context": "http://schema.org",

  "homeLocation": {

    "@id": "http://dbpedia.org/page/Tilburg",

    "@type": "http://schema.org/City",

    "name": "Tilburg"

  }

}




Because even if homeLocation and birthplace are different properties, they both actually are cities. And if this is OK, can I also state that by just passing a context file through the header on a 'normal' JSON response can make it valid JSON-LD, but just for the properties?



Regards, Dimitri






Van: markus.lanthaler@gmx.net
Verzonden: ‎vrijdag‎ ‎25‎ ‎juli‎ ‎2014 ‎19‎:‎46
Aan: public-hydra@w3.org





Hi Dimitri,

On Thursday, July 24, 2014 12:36 PM, Dimitri van Hees wrote:
> I've been following this list for a few months now but have not yet
> been in the opportunity to introduce myself or contribute anything. As
> I have a question about JSON-LD, I think this might be the right time
> to do so ;-)

Great! Good to see you here :-)

 
> That said, it was time for me to actually start implementing this
> model in our own API's. For this purpose we created a demo API which
> represents our 26 employees, including birthdates, hometowns, hobbies,
> functions, education, etc. I want to add Hydra in the JSON-LD

Cool!


> representation, HATEOAS in the JSON representation (does that sound
> reasonable by the way?)

Sounds a bit weird to me as HATEOAS is a description of what drives the application. I would say "add hypermedia controls to JSON" instead.


> and also provide an application/nquads
> representation to fetch the triples and load them into a triplestore
> one by one.
> 
> After spending hours reading the documentation I still can't find what
> I'm doing wrong with the conversion to JSON-LD. I hope this list will
> help me out a little bit. Let's say I have this response (in real life
> this is valid JSON but my mail client sucks at the moment 😉):
> 
> id: dimitri,
> givenName: Dimitri,
> additionalName: van,
> familyName: Hees,
> gender: male,
> birthplace: Nijmegen,
> residence: Tilburg
> 
> As you might have noticed the properties are all schema.org except
> birthplace and residence. When converting this to JSON-LD I think I
> could say:
> 
> @context: {
>   schema: http://schema.org/,

>   givenName: {@id: schema:givenName},
>   addition…
>   birthplace: {@id: schema:City, @type: @id},
>   residence: {@id: schema:City, @type: @id},

These two mappings here are the problem. You map two properties, birthplace and residence to schema:City which isn't a property but a class. There's no property for birthplace in Schema.org yet (I think it would make sense to propose one on public-vocabs@w3.org). For residence, you could use either schema:homeLocation or schema:workLocation.


> },
> @id: http://data.freshheads.com/dimitri,

> givenName: Dimitri,
> additon…,
> birthplace: {
>   @id: http://www.nijmegen.nl

> },
> residence: {
>   @id: http://www.tilburg.nl

> }
> 
> The problem is that both birthplace and residence are being converted
> to City while they don't seem to be an actual 'City' anymore. When I
> add it to the valueobject itself:
> 
> birthplace: {
>   @id: http://www.nijmegen.nl

>   @type: http://schema.org/City

> }
> 
> then it works they way I'd expect. But I don't really understand why.
> Any thoughts?

Type coercion in the context only works for literals, i.e., simple strings. In other words, you can convert a simple string to an @id object by setting @type: @id or to a @value object with a @type by setting @type to the desired datatype in the context. Please not that you can NOT type nodes (@id objects) from within the context. You need to do so directly in the document itself. Node types and value types are treated differently. 


HTH,
Markus


--
Markus Lanthaler
@markuslanthaler