MetaCell / MetaCell/sds-viewer

Filter Graph by Factors

Open
#26 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

P1
Dominant language
JavaScript
Stars
4
Forks
5
PR merge metrics
No merged PRs in 30d

Description

As Any User : I want to Filter graph viewer by a range of factors such as protocol, award number, contributor, etc.
So I Can: Control what I visualize in the graph viewer

The range of factors for this are the properties under SPAR:Dataset:
sparc:Dataset Properties
label
title
isAbout
contentsWereUpdatedAtTime
curationIndex
errorIndex
hasAdditionalFundingInformation
hasAwardNumber
hasContactPerson
hasDatasetTemplateSchemaVersion
hasExperimentalModality
hasNumberOfContributors
hasNumberOfDirectories
hasNumberOfFiles
hasResponsiblePrincipalInvestigator
hasSizeInBytes
hasUriApi
hasUriHuman
protocolEmploysTechnique
statusOnPlatform
submissionIndex
wasCreatedAtTime
wasUpdatedAtTime
unclassifiedIndex

Follow up with Tom about this :

Question : For the "Filter Graph by Factors" use case, where a graph viewer can be filtered by protocol, award number, contributor etc. What will be the the whole list of factors that the user can filter the graph viewer by? Is it the whole list of properties found on the sparch:Dataset (screenshot )?
And also, once the filtered is apply to the Graph Viewer, we will be displaying and focusing the nodes that apply to that filter but what happens to the rest of the nodes?
For example, if the graph is filtered by Contributor do we remove the nodes that don't have the contributor from the graph? We can completely remove the nodes, hide
them or made them fade in the background with less opacity than the nodes that did match the Contributor filter.

Answer : In the simple case yes, it is on that list of properties. However
since this is in the multi-dataset case I think this is indended
more as a tool for pulling in datasets to be visualized and not to
filter down what is already present. It is about going beyond the
loaded datasets, not filtering the existing ones, if that makes
sense.
I am pretty sure that this user story devolves into the filter
graph by datasets user story. The fully abstract version of it is
to take any sparql query that returns a list of datasets and show
only those datasets.
The issue is how to map the selection of any individual thing like
a protocol, a group, or a sample, and specify the equivalent sparql
query. For example, this is needed for groups because they do not
have a direct relation to the dataset beyond appearing in the
export file for a particular dataset.
Having through about this, I think that it will probably be more
robust in the long run to specify the filtering behavior for
individual graph elements by writing the sparql query that we want
to run to connect them to datasets.
I have a list of queries that we could start from.
https://github.com/SciCrunch/sparc-curation/blob/master/docs/queries.org#datasets
In the contributor use case the behavior we want is to look up
all dataset contributor records that we have loaded and return
all the datasets where they are a contributor. This may need to
search outside the set of loaded datasets so that we can discover
more datasets. This could hit a sparql endpoint to discover the
datasets beyond those already loaded, or to keep things simple
we could provide a stripped down ttl file with only the relations
we need to do the filtering and discovery so that we don't need
to worry about a sparql endpoint.

Question : For the "Filter Graph by Datasets" use case, the user needs to be able to filter the Graph Viewer by datasets. This means that in the case of having multiple loaded
datasets, a single Graph Viewer can display the contents of more than one or all loaded datasets ? Or do we assume that for each loaded dataset, there needs to be a
unique Graph viewer dedicated to displaying one dataset each only?

Answer : For the multi-dataset use case we will want to be able to view
multiple datasets in a single Graph viewer, as well as being able
to switch to a unique view per dataset, so both. This may not
always be easy to accomplish if there is more than one dataset per
file, so we will need to work through that case.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with docs/queries.org#datasets, the query list referenced in the issue, and review the multi-dataset graph viewer entry points. Clarify whether this should become dataset discovery via SPARQL queries or a stripped-down TTL file, then define how multiple datasets and per-dataset views are selected before implementation; done means the agreed filtering behavior is documented and tested.

Written by the indexing model from the issue text.

Assessment

Tech stack
javascript
Domain
frontend
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
18/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.