search

monarch-initiative / monarch-legacy

Monarch web application and API
BSD 3-Clause "New" or "Revised" License
42 stars 37 forks source link

linked data browsing on monarch #1201

Open satra opened 8 years ago

satra commented 8 years ago

it would be great if monarch can be crawled through linked data browsing. this would mean that IRIs in monarch (e.g., http://monarchinitiative.org/disease/OMIM:127750) would return a graph of information hopefully in some serialization of RDF (trig, turtle, json-ld), preferably settable in an accept-header.

this would also help figure out how many of the external links are machine accessible.

jmcmurry commented 8 years ago

Hi Satra, we do serve Turtle, but on the dataset level, not the individual record. Eg. http://data.monarchinitiative.org/ttl/clinvar.ttl or http://data.monarchinitiative.org/ttl/omim.ttl

Just use the prefix registered in curie-map.yaml to pull each down.

Hope this helps in the meantime

jmcmurry commented 8 years ago

Could you tell us a little more of what you'd be hoping to get from these visualizations? A specific use case would be tremendous. Thanks

harryhoch commented 8 years ago

@jmcmurry, I have some thoughts on this. we can try to suggest at some point...

mellybelly commented 7 years ago

@satra let us know if you are getting what you want at this point? We will try to address or close this ticket, thank you!

satra commented 7 years ago

@mellybelly - i think what i meant was that i would like to be able to do something like this:

curl --header "Accept: text/turtle" https://monarchinitiative.org/disease/OMIM:127750

which doesn't look like it's possible right now. Accept: could be different serializations: json-ld, json-schema, trig, n3, etc.,.

satra commented 7 years ago

@mellybelly - and once that kind of thing is in place, then we can consider other generic ways of information visualization.

mellybelly commented 7 years ago

Thanks for the requirements Satra, I'm tagging few folks here as they have some related things cooking @balhoff @dougli1sqrd @kltm

jmcmurry commented 7 years ago

Satra, are you trying to figure out what classes (and sources) of entities we serve as pages and where? If so, our prefix map may provide helpful clues. I've sketched out where to find the incoming links. If this format is helpful to you, I could make it more comprehensive. Broadly speaking, we need to do document these anyway to facilitate links from other sources. It is also related to knowledge beacon effort, though, I suspect will rely much more on programmatic access to the graph than constrained by what we formalize as pages in the UI.

satra commented 7 years ago

@jmcmurry - my initial goals were a little about how i could generate a related info for objects in our graphs, hence the need for access to graph itself rather than the ui view of subgraph. and from a technology standpoint whether the html view is returned or an rdf graph is returned is a function of the accept header.

cmungall commented 7 years ago

You're specific needs are best served by https://api.monarchinitiative.org/api/, although this is in beta

Exposing Monarch as LD is a great idea, we should be able to do this when we have our triplestore mirror up (our currently main graph store in neo4j which doesn't get exposed as LD natively).

Another way to do this would be via the Translator Knowledge-Beacons. I made a ticket for this https://github.com/NCATS-Tangerine/translator-knowledge-beacon/issues/19