Re: Process of "following your nose"

In your examples, cases 1-2 use http content negotiation, which I think is perfectly fine from the LD perspective (you may have different representations of the same resource).
Cases 3-5, however, define custom URLs and while the same resource may reside behind those URLs, these are different IRIs and hence different resources from the LD perspective. 

> If we know the IRI is dereferenceable, don't we still have to check the content type?
This is indeed a good question in general.
For example, if an IRI in a JSON-LD document is dereferenceable, does it mean that I can get a ld+json representation of the resource by following it? 

Alex.

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

> 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 21:15:35 UTC