Re: Process of "following your nose"

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