Summary

• Page properties (1 modified, 0 added, 0 removed)

Details

Page properties

Content

...	...	@@ -20,7 +20,11 @@
20	20
21	21	==== **Query Builder** ====
22	22
23		-To search for datasets containing human subjects only, you can first declare the id (to get the involved instances) as well as a link to the "studied specimen" (you can add a type filter and restrict it to "Subject" and "Subject group" only since we are not interested in "Tissue samples" and "Tissue sample collections" in this moment). From "studied specimen", we're interested in the "Species" (here you can - again add a type filter to exclude "Strain" since this is irrelevant for human subjects). For the "Species", we want the "label" to contain "homo sapiens" which is why we add a filter "contains" with the value "homo sapiens".  We might want to simplify the deeply nested structure by "flattening" both, the "Studied specimen" as well as the "Species". Once we go to the "execute query" section (the play button on the left) and we run the query, we can see the total number of dataset versions.
	23	+To search for datasets containing human subjects only, we will therefore execute the query against the "dataset version" data structure. We want to know the persistent identifier and name of the dataset version, so we declare the "id" and "lookup label" first. Since our objective is to filter dataset based on the species of the subjects, we need to specify "sudied specimen" in our query too. We have four specimen categories, "subjects", "subject group", "tissue sample", and "tissue sample collection". We add a "type filter" to restrict our results to "Subject" and "Subject group" since we are not currently not interested in "Tissue samples" and "Tissue sample collections". To ensure that we only get datasets with human subjects, we can define the "Species" under "studied specimen" (again, you can add a type filter to exclude "Strain" since this is irrelevant for human subjects). For the "Species", we want the "label" to contain "homo sapiens" which is why we add a filter "CONTAINS" with the value "Homo sapiens".
	24	+
	25	+For graph databases, like the EBRAINS Knowledge Graph, it is very easy to create very long and complex queries. We can simplify deeply nested structures by "flattening" the query. This is only possible when a property only has 1 nested property ("child"). In our query, this is the case for the "Studied specimen" and the "Species".
	26	+
	27	+Once we have build your query, we can go to the "execute query" section (the play button on the left) and run the query, we can see the total number of dataset versions.
24	24	\\Please note that this number can differ from the one you figured out in the search UI. The reason for this is, that the search UI does only count the newest dataset version whilst the query also returns older dataset versions.
25	25
26	26	{{code language="json" layout="LINENUMBERS"}}
...	...	@@ -43,6 +43,10 @@
43	43	},
44	44	"structure": [
45	45	{
	50	+ "propertyName": "query:shortName",
	51	+ "path": "https://openminds.ebrains.eu/vocab/shortName"
	52	+ },
	53	+ {
46	46	"propertyName": "query:id",
47	47	"path": "@id"
48	48	},
...	...	@@ -88,8 +88,12 @@
88	88
89	89	==== **Query Builder** ====
90	90
91		-For dataset versions that use male adult subjects, we can filter datasets using these 2 properties. The easiest way is to add a required filter to biological sex that is "EQUAL" to "male" and the age category "EQUAL" to "adult". By selecting the filter "EQUAL" instead of "CONTAINS", we ensure that only datasets with adult animals are found. If we want to be more general and include all subjects from the onset of sexual maturity, we can use "CONTAINS" instead as this will include subjects with the age category "prime adult", "young adult" and "late adult" as well.
	99	+For dataset versions that use male adult subjects, we can filter datasets using these 2 properties. The easiest way is to add a required filter to biological sex that is "EQUAL" to "male" and the age category "EQUAL" to "adult". By selecting the filter "EQUAL" instead of "CONTAINS", we ensure that only datasets with adult animals are found. If we want to be more general and include all subjects from the onset of sexual maturity, we can use "CONTAINS" instead as this will include subjects with the age category "prime adult", "young adult" and "late adult" as well.
92	92
	101	+We are showing the unflattened query here. You can take advantage of the type filter (set it to subjects and subject groups), and flatten the query where possible. The query will look different; there will be multiple elements in the "path" for "biological sex" and for the "age category".
	102	+
	103	+Try it yourself and check out the differences between the results of the flattened and unflattened queries! Hint: look at the indexing of elements within your results!
	104	+
93	93	{{code language="json" layout="LINENUMBERS"}}
94	94	{
95	95	"@context": {
...	...	@@ -105,24 +105,38 @@
105	105	}
106	106	},
107	107	"meta": {
108		- "type": "https://openminds.ebrains.eu/core/DatasetVersion",
109		- "responseVocab": "https://schema.hbp.eu/myQuery/"
	120	+ "responseVocab": "https://schema.hbp.eu/myQuery/",
	121	+ "type": "https://openminds.ebrains.eu/core/DatasetVersion"
110	110	},
111	111	"structure": [
112	112	{
113		- "propertyName": "query:id",
114		- "path": "@id"
115		- },
116		- {
117	117	"propertyName": "query:shortName",
118	118	"path": "https://openminds.ebrains.eu/vocab/shortName"
119	119	},
120	120	{
	129	+ "propertyName": "query:id",
	130	+ "path": "@id"
	131	+ },
	132	+ {
121	121	"propertyName": "query:studiedSpecimen",
122		- "path": "https://openminds.ebrains.eu/vocab/studiedSpecimen",
	134	+ "path": {
	135	+ "@id": "https://openminds.ebrains.eu/vocab/studiedSpecimen",
	136	+ "typeFilter": [
	137	+ {
	138	+ "@id": "https://openminds.ebrains.eu/core/Subject"
	139	+ },
	140	+ {
	141	+ "@id": "https://openminds.ebrains.eu/core/SubjectGroup"
	142	+ }
	143	+ ]
	144	+ },
123	123	"required": true,
124	124	"structure": [
125	125	{
	148	+ "propertyName": "query:lookupLabel",
	149	+ "path": "https://openminds.ebrains.eu/vocab/lookupLabel"
	150	+ },
	151	+ {
126	126	"propertyName": "query:id",
127	127	"path": "@id"
128	128	},
...	...	@@ -133,7 +133,6 @@
133	133	"structure": {
134	134	"propertyName": "query:name",
135	135	"path": "https://openminds.ebrains.eu/vocab/name",
136		- "required": true,
137	137	"filter": {
138	138	"op": "EQUALS",
139	139	"value": "male"
...	...	@@ -179,9 +179,11 @@
179	179
180	180	To find datasets with a particular file format in it, we can either write a query for 1) the file extension or 2) based on the content type. The difference between the two approaches is that the first approach just looks at the file extension without considering the what type of file format it is and what software can be used to open it. For example, both nifti 1 and nifti 2 files have the same extension. The nifti 2 format is an update of nifti 1 and will not be recognised as a valid nifti 1 format. This is important when considering what program to use when opening the files. To be able to differentiate, we describe the files with content types that tell the user what type of file format it is and we have linked a number of software applications to that content type to facilitate reuse of the data.
181	181
	207	+For these examples, we are showing the unflattened version of the query. Try it yourself to create a flattened version!
	208	+
182	182	**Query datasets based on file extension**
183	183
184		-We can restrict the search results with a filter using a required field. In this particular case a filter that "ENDS_WITH" a value (e.g. .nii.gz) could be used. We can use .nii for normal nifti files or .nii.gz for compressed nifty files.
	211	+We can restrict the search results with a filter using a required field. In this particular case a filter that "ENDS_WITH" a value (e.g. .nii.gz) could be used. We can use .nii for normal nifti files or .nii.gz for compressed nifti files.
185	185
186	186	{{code language="json" layout="LINENUMBERS"}}
187	187	{
...	...	@@ -236,7 +236,7 @@
236	236	}
237	237	{{/code}}
238	238
239		- **Query datasets based on content type**
	266	+**Query datasets based on content type**
240	240
241	241	To find datasets using the content type structure, we can use a filter that "CONTAINS" a value (e.g. nifti). We are now not distinguishing between nifti 1 or nifti 2 files, but select all files that are classified as "nifti". If you want to narrow down the results further, you could replace "nifti" by "nifti.1" or "nifti.2".
242	242
...	...	@@ -310,6 +310,10 @@
310	310
311	311	For this question, we will execute the query against the "softwareVersion data structure. We ask for the name, version and input type of the software. We further refine our query by restricting the result to software that can open files with the file extension ".smr". We get the same 3 software types as in the search, and we immediately see that one of the software types has multiple versions that can open this kind of files.
312	312
	340	+(This query is not flattened).
	341	+
	342	+You may have noticed that even though you can get the same results in the Search UI and the Query Builder, the details you need to define to get to that result are not always the same. For example, in the query we can rely on the file extension (i.e. ".smr"), whereas in the Search UI we sometimes need to have specific details about the file you are trying to open, such as the software/data aquisition/analysis package (i.e. Spike2) that was used. You may keep this is mind when tackling a particular question. Queries can be made as detailed and broad as you want, whereas the Search UI is a snapshot of the most common and basic information that is available.
	343	+
313	313	{{code language="json" layout="LINENUMBERS"}}
314	314	{
315	315	"@context": {
...	...	@@ -366,4 +366,3 @@
366	366	{{/code}}
367	367
368	368
369		-