RE: Process of "following your nose"

Hi

> 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/E
> NSG00000105486/UnificationXref>, in the body of the document. I

Right. The JSON-LD processor just processes JSON-LD generically, i.e., it can expand documents, compact them etc. (you tell the playground what you want it to do). There's no feature to start crawling and merging documents. That's beyond the scope of the playground but you could certainly implement that in your application if it is a feature you need.


> 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>?

Using simplified examples that aren't 2000 lines long would make it much easier to understand what the question actually is... but I guess the answer is yes :-P


> 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

It's visualized in the diagram and also stated explicitly here: http://www.hydra-cg.com/spec/latest/core/#hydra:Resource


> 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.

Exactly. That's the purpose. It's a hint to a client that it can reasonably expect that the IRI is dereferenceable, i.e., it is actually a URL.


> > 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.

Why would you need to know that beforehand? Sure, you could avoid a few failing requests but does that really improves things? What if you link to someone else's data? What if the set of media types changes? IMO it's enough to find it out at runtime (yeah, you could use the same argument against hydra:Resource/Link)


Summarized, your application can do whatever it wants. Since the Web is a distributed system that isn't controlled by a single entity it is very often not practical to define strict contracts that define all details beforehand. A lot has to be found out at runtime. You obviously need to program your application accordingly.


--
Markus Lanthaler
@markuslanthaler