W3C home > Mailing lists > Public > public-linked-json@w3.org > May 2014

Re: Process of "following your nose"

From: Anders Riutta <anders.riutta@gladstone.ucsf.edu>
Date: Sat, 31 May 2014 08:47:42 -0700 (PDT)
To: Alexandr Krylovskiy <alexandr.krylovskiy@gmail.com>
Cc: Linked JSON <public-linked-json@w3.org>
Message-ID: <1306619729.3461772.1401551262887.JavaMail.zimbra@gladstone.ucsf.edu>
Hi Alex,

Thanks for the response.

If we know the IRI is dereferenceable, don't we still have to check the content type? For example,  if dereferencing <http://dbpedia.org/resource/Cynthia_Lennon> only returned HTML, we couldn't use it to directly transclude additional JSON-LD.

But if we could get different content types, including JSON-LD, from <http://dbpedia.org/resource/Cynthia_Lennon>, we could transclude the JSON-LD. Unfortunately, we wouldn't know without testing how to get the JSON-LD. It could be any of these:
1) <http://dbpedia.org/resource/Cynthia_Lennon> with an Accept request-header field value of "application/json"
2) <http://dbpedia.org/resource/Cynthia_Lennon> with an Accept request-header field value of "application/ld+json"
3) <http://dbpedia.org/resource/Cynthia_Lennon/.json> without an Accept request-header
4) <http://dbpedia.org/resource/Cynthia_Lennon/.jsonld> without an Accept request-header
5) <http://dbpedia.org/resource/Cynthia_Lennon?format=json> without an Accept request-header

The documentLoaders code <https://github.com/digitalbazaar/jsonld.js/blob/master/js/jsonld.js#L1522> would work for 1) and 2), but not for 3) - 5).

Thanks,
Anders

----- Original Message -----
> From: "Alexandr Krylovskiy" <alexandr.krylovskiy@gmail.com>
> To: "Anders Riutta" <anders.riutta@gladstone.ucsf.edu>
> Cc: "Linked JSON" <public-linked-json@w3.org>
> Sent: Saturday, May 31, 2014 2:13:08 AM
> Subject: 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
> >> 
> >> 
> >> 
> > 
> 
> 
Received on Saturday, 31 May 2014 15:48:08 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:18:41 UTC