{"action":"created","issue":{"url":"https://api.github.com/repos/ga4gh/schemas/issues/253","labels_url":"https://api.github.com/repos/ga4gh/schemas/issues/253/labels{/name}","comments_url":"https://api.github.com/repos/ga4gh/schemas/issues/253/comments","events_url":"https://api.github.com/repos/ga4gh/schemas/issues/253/events","html_url":"https://github.com/ga4gh/schemas/pull/253","id":60510534,"number":253,"title":"Rationalises the SearchObjectRequest semantics.","user":{"login":"jeromekelleher","id":2664569,"avatar_url":"https://avatars.githubusercontent.com/u/2664569?v=3","gravatar_id":"","url":"https://api.github.com/users/jeromekelleher","html_url":"https://github.com/jeromekelleher","followers_url":"https://api.github.com/users/jeromekelleher/followers","following_url":"https://api.github.com/users/jeromekelleher/following{/other_user}","gists_url":"https://api.github.com/users/jeromekelleher/gists{/gist_id}","starred_url":"https://api.github.com/users/jeromekelleher/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jeromekelleher/subscriptions","organizations_url":"https://api.github.com/users/jeromekelleher/orgs","repos_url":"https://api.github.com/users/jeromekelleher/repos","events_url":"https://api.github.com/users/jeromekelleher/events{/privacy}","received_events_url":"https://api.github.com/users/jeromekelleher/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":12,"created_at":"2015-03-10T14:45:50Z","updated_at":"2015-03-29T02:13:38Z","closed_at":null,"pull_request":{"url":"https://api.github.com/repos/ga4gh/schemas/pulls/253","html_url":"https://github.com/ga4gh/schemas/pull/253","diff_url":"https://github.com/ga4gh/schemas/pull/253.diff","patch_url":"https://github.com/ga4gh/schemas/pull/253.patch"},"body":"This PR changes the semantics of all `SearchObjectRequest`s so they require the ID of a single container object, if applicable. Currently, a number of different conventions exist, making implementation and authorisation difficult. This solves issue #247 and is related to the issues in #248.\r\n\r\nMost of the changes are straightforward, and just require the change of a field like (for example) `array<string> dataSetIds = [];` to `string dataSetId;`. There are some problematic cases:\r\n\r\n1. `SearchCallsRequest` and `SearchAlleleCallsRequest` both had a large list of options for the containers that they could search over. As an initial strawman I've reduced this to just the parent `CallSet` to be consistent with all the other objects. Reasoning for these:\r\n   1. Since a `CallSet` is part of a `VariantSet`, the variant set is implied by specifying `callSetId`.\r\n   2. Finding  `Calls` for a particular `variantId` is redundant, since `Call`s are embedded in `Variant` objects. If we wish to find the calls for a given variant, we can either find them directly using `SearchVariantsRequest` or make a call to GET `/variants/<id>/`\r\n   3. We are then left with iterating over all calls in a CallSet, which seems like a peculiar thing to do without reference to the containing `Variant` object. However, this might be updated with more meaningful semantics later.\r\n2. `SeachAlleles` is problematic; what is the interplay between the `variantSetId` and the `sequenceId`? If `sequenceId` is required, then why do we need the `variantSetId`? Conceptually, it seems natural that an Allele belongs to a single `VariantSet`.\r\n\r\nIn terms of backwards compatibility, obviously there are some breaking changes here. These are minor, however, and easily worked around. Server-side, this is a considerable simplification, and so implementation can simply be a special case of the existing semantics. Client-side, users that are using the multi-container search semantics will need to now explicitly iterate over the container IDs that they are interested in."},"comment":{"url":"https://api.github.com/repos/ga4gh/schemas/issues/comments/87341916","html_url":"https://github.com/ga4gh/schemas/pull/253#issuecomment-87341916","issue_url":"https://api.github.com/repos/ga4gh/schemas/issues/253","id":87341916,"user":{"login":"pgrosu","id":6555937,"avatar_url":"https://avatars.githubusercontent.com/u/6555937?v=3","gravatar_id":"","url":"https://api.github.com/users/pgrosu","html_url":"https://github.com/pgrosu","followers_url":"https://api.github.com/users/pgrosu/followers","following_url":"https://api.github.com/users/pgrosu/following{/other_user}","gists_url":"https://api.github.com/users/pgrosu/gists{/gist_id}","starred_url":"https://api.github.com/users/pgrosu/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/pgrosu/subscriptions","organizations_url":"https://api.github.com/users/pgrosu/orgs","repos_url":"https://api.github.com/users/pgrosu/repos","events_url":"https://api.github.com/users/pgrosu/events{/privacy}","received_events_url":"https://api.github.com/users/pgrosu/received_events","type":"User","site_admin":false},"created_at":"2015-03-29T02:13:38Z","updated_at":"2015-03-29T02:13:38Z","body":"Hi Richard (@richarddurbin),\r\n\r\nRegarding a reference server - which would be a big win - we should just start simple just the way search engines are built via an inverted index.  Below are the general steps:\r\n\r\n1. The genome is split into equally sized regions.\r\n\r\n2. Each region is contains a pointer to a list of sample ids.  A hash function (i.e. md5sum, sha256sum, etc) is generated between the tuple *(region, sample_id)* for optimized lookup of the reads for that sample in the specified region.\r\n\r\n3. The hash is then accessed in O(1) for the collection of reads it contains for that region.\r\n\r\nThis would also enable efficiently parallelized across multiple machines.  The storage can also be optimized via the Log-Structured-Merge (LSM) Tree data structure with Differentiated Indexing (Diff-Index), which I put a reference for below.\r\n\r\n##### References\r\n\r\nA nice graphical description of an inverted index is shown at the following link: \r\n\r\nhttps://developer.apple.com/library/mac/documentation/UserExperience/Conceptual/SearchKitConcepts/searchKit_basics/searchKit_basics.html\r\n\r\nRegarding a deeper description on inverted indices, below is a nice paper from Google, that contains a description of it:\r\n\r\nhttp://static.googleusercontent.com/media/research.google.com/en/us/pubs/archive/37367.pdf\r\n\r\nBelow is another nice paper from Google/IBM/GeorgiaTech regarding the Log-Structured-Merge (LSM) Tree data structure and with Differentiated Indexing (Diff-Index):\r\n\r\nhttp://researcher.watson.ibm.com/researcher/files/us-wtan/DiffIndex-EDBT14-CR.pdf\r\n\r\nLet me know what you think.\r\n\r\nThank you,\r\nPaul"}}