Re: Process of "following your nose"

Hi Anders,

I am fairly new to JSON-LD and Hydra, and still in the process of grasping their concepts.
 
It seems to me that the w3c draft [1] doesn’t state it explicitly, but hydra:Resource is a subclass of the rdfs:Resource, where IRI is dereferenceable (according to [2]). The hydra:Link, as you mentioned, is also derefereceable (it is in fact a subclass of hydra:Resource) and its purpose is to describe dereferenceable properties.
Therefore, describing your resources and their properties using hydra:Resource and hydra:Link correspondingly you assure your clients that the URIs are dereferenceable.

Hope this helps.

Alex

[1] http://www.hydra-cg.com/spec/latest/core/ 
[2] http://www.markus-lanthaler.com/research/hydra-a-vocabulary-for-hypermedia-driven-web-apis.pdf

On 31 May 2014, at 00:26, Anders Riutta <anders.riutta@gladstone.ucsf.edu> wrote:

> To answer my own question, it appears that JSON-LD and the Hydra API project <http://www.markus-lanthaler.com/hydra/> make it easier for developers to link together online resources, but it is still necessary for a developer to manually follow IRIs in JSON-LD responses to discover when a link is both dereferenceable and points to more JSON-LD.
> 
> As an example, let's say a developer wanted to find all people on dbpedia who were born in the same year as their spouse. If dbpedia used JSON-LD and Hydra for their API, the developer could make a request to <http://dbpedia.org/> with "Accept: application/ld+json" to see that the entry point is just <http://dbpedia.org/>, and it has a collection at <http://dbpedia.org/resource>, which responds to get requests. This collection would have a context including this:
> 
> {
>  "@context": "http://www.w3.org/ns/hydra/context.jsonld",
>  "@id": "http://schema.org/spouse",
>  "@type": "Link"
> }
> 
> The developer then knows the datasource is using schema.org. The next step is filtering the resources to include only those with a <http://schema.org/spouse>, returning a large number of results like this:
> 
> {
>  "@context": "http://json-ld.org/contexts/person.jsonld",
>  "@id": "http://dbpedia.org/resource/John_Lennon",
>  "name": "John Lennon",
>  "born": "1940-10-09",
>  "spouse": "http://dbpedia.org/resource/Cynthia_Lennon"
> }
> 
> The developer still doesn't know whether the spouse IRI can be dereferenced as JSON-LD, so a manual step is still required to test: make a request to <http://dbpedia.org/resource/Cynthia_Lennon> with an Accept request-header field value of "application/ld+json" to see whether it returns a response like this, including a birth date:
> 
> {
>  "@context": "http://json-ld.org/contexts/person.jsonld",
>  "@id": "http://dbpedia.org/resource/Cynthia_Lennon",
>  "name": "Cynthia Lennon",
>  "born": "1939-09-10",
>  "spouse": "http://dbpedia.org/resource/John_Lennon"
> }
> 
> If the test returns JSON-LD, the final step is to dereference the spouse IRI for each person to get the spouse's birth date and compare that birth date with the birth date of the person, only returning those where the birth dates are within one year of each other. This process ignores Yoko Ono and could be made more efficient, but it demonstrates the general idea.
> 
> Anders
> 
> ----- Original Message -----
>> From: "Anders Riutta" <anders.riutta@gladstone.ucsf.edu>
>> To: "Linked JSON" <public-linked-json@w3.org>
>> Sent: Wednesday, May 28, 2014 9:32:23 PM
>> Subject: Process of "following your nose"
>> 
>> Hello,
>> 
>> I am working on a bioinformatics data integration project with the objective
>> of linking biological pathway data from our non-profit research group with
>> gene annotation data from another research group. This gene annotation data
>> is currently represented as a list named "unificationXrefs" in our
>> documents. You can see a proof of concept for pathway WP531
>> <http://wikipathways.org/index.php/Pathway:WP531> published at the JSON-LD
>> playground:
>> <http://json-ld.org/playground/index.html#startTab=tab-expanded&json-ld=http%3A%2F%2Ftest2.wikipathways.org%2Fv2%2Fpathways%2FWP531%2F.json>.
>> 
>> The JSON-LD processor automatically deferences the IRI
>> <http://test2.wikipathways.org/v2/contexts/pathway.jsonld> in the context,
>> but it does not automatically dereference the unificationXrefs IRIs, such as
>> <http://pointer.ucsf.edu:8080/ensembl/ENSG00000105486/UnificationXref>, in
>> the body of the document. I understand this further dereferencing does not
>> happen automatically, because it must be requested by a developer or
>> machine. "Follow your nose" is an important part of JSON-LD, but how exactly
>> are developers and machines supposed to do this? For example, let's say a
>> user wants to find all instances of
>> <http://www.identifiers.org/ncbigene/3978> in pathway WP531. Manually going
>> to <http://pointer.ucsf.edu:8080/ensembl/ENSG00000105486/UnificationXref>
>> will show one instance, but to do this automatically, would a developer who
>> had never before seen our data need to first figure out that the
>> unificationXrefs IRIs are JSON-LD documents and then write code to
>> dereference every unificationXrefs IRI to check for the presence of
>> <http://www.identifiers.org/ncbigene/3978>?
>> 
>> Thanks.
>> Anders Riutta
>> Gladstone Institutes
>> 
>> 
>> 
>