You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: 00-Getting_started/00-Getting started.ipynb
+6-6Lines changed: 6 additions & 6 deletions
Original file line number
Diff line number
Diff line change
@@ -11,7 +11,7 @@
11
11
"cell_type": "markdown",
12
12
"metadata": {},
13
13
"source": [
14
-
"Congratulations! If you are reading this, then you have successfully connected to the workshop JupyterHub and opened up your very first workshop notebook!\n",
14
+
"Congratulations! If you are reading this, then you have successfully connected to the workshop JupyterHub and opened up your very first workshop notebook! These notebooks are oranized with numbers to highlight what should come next. First, we'll walk through the startup process. Next, you'll see an introduction to DataJoint, and how to structure a data pipeline. The Calcium Imaging and Electrophysiology folders show example data structures and analysis techniques from common experimental techniques. We've included some fill-in-the-blank sections for you to code yourself. If you want to see completed notebooks, see the folder of completed exercises.\n",
15
15
"\n",
16
16
"Before we start, remember that all of the edits you make in these tutorial notebooks are ***not persistent*** - they will be reset to the original content everytime you restart the server. However, you can easily download the notebooks that you're interested in keeping the changes."
17
17
]
@@ -316,18 +316,18 @@
316
316
"The next step in the tutorial is to:\n",
317
317
"1. learn the basic of the DataJoint framework with [01-DataJoint Basics](./01-DataJoint%20Basics%20-%20Interactive.ipynb)\n",
318
318
"2. data ingestion in a pipeline, with practical examples in 2 domains:\n",
"As you will find out that these tutorial notebooks are meant to be interactive. There will be empty cells meant for you to write the code yourself, as mini exercises. To access the notebooks with complete solutions, visit this [folder](./completed)."
330
+
"As you will find out that these tutorial notebooks are meant to be interactive. There will be empty cells meant for you to write the code yourself, as mini exercises. To access the notebooks with complete solutions, visit this [folder](../03-Completed_Exercises)."
Copy file name to clipboardExpand all lines: 00-Getting_started/01-DataJoint Basics - Interactive.ipynb
+5-5Lines changed: 5 additions & 5 deletions
Original file line number
Diff line number
Diff line change
@@ -555,7 +555,7 @@
555
555
"source": [
556
556
"Note that, to uniquely identify an experimental session (or simply a **session**), we need to know the mouse that the session was about. In other words, a session cannot existing without a corresponding mouse! \n",
557
557
"\n",
558
-
"With **mouse** already represented as a table in our pipeline, we say that the session **depends on** the mouse! We would graphically represent this in an **entity relationship diagram (ERD)** by drawing the line between two tables, with the one below (**session**) dependeing on the one above (**mouse**)."
558
+
"With **mouse** already represented as a table in our pipeline, we say that the session **depends on** the mouse! We could graphically represent this in an **entity relationship diagram (ERD)** by drawing the line between two tables, with the one below (**session**) dependeing on the one above (**mouse**)."
559
559
]
560
560
},
561
561
{
@@ -590,7 +590,7 @@
590
590
"cell_type": "markdown",
591
591
"metadata": {},
592
592
"source": [
593
-
"You can actually generate the entity relationship diagram (ERD) on the fly by calling `dj.ERD` with the schema object"
593
+
"You can actually generate something similar to an entity relationship diagram (ERD) on the fly by calling `dj.Diagram` with the schema object. Many of the symbols and features are the same as the ERD standard."
594
594
]
595
595
},
596
596
{
@@ -599,7 +599,7 @@
599
599
"metadata": {},
600
600
"outputs": [],
601
601
"source": [
602
-
"dj.ERD(schema)"
602
+
"dj.Diagram(schema)"
603
603
]
604
604
},
605
605
{
@@ -1535,8 +1535,8 @@
1535
1535
"In the next session, we are going to extend our data pipeline with tables to represent **imported data** and define new tables to **compute and hold analysis results**.\n",
1536
1536
"\n",
1537
1537
"We will use both ephys and calcium imaging as example pipelines:\n",
Copy file name to clipboardExpand all lines: 00-Getting_started/01-DataJoint Basics - Interactive.py
+16-16Lines changed: 16 additions & 16 deletions
Original file line number
Diff line number
Diff line change
@@ -42,13 +42,13 @@
42
42
#
43
43
# Let's go ahead and build together a pipeline from scratch to better understand what a data pipeline is all about.
44
44
45
-
# # Building our first pipeline:
45
+
# # Building our first pipeline:
46
46
47
47
# Let's build a pipeline to collect, store and process data and analysis for our hypothetical single electrode recording or calcium imaging recording in mice. To help us understand the project better, here is a brief description:
48
48
49
49
# > * Your lab houses many mice, and each mouse is identified by a unique ID. You also want to keep track of information about each mouse such as their date of birth, and gender.
50
50
# > * As a hard working neuroscientist, you perform experiments every day, sometimes working with more than one mouse in a day! However, on any given day, a mouse undergoes at most one recording session.
51
-
# > * For each experimental session, you would like to record what mouse you worked with and when you performed the experiment. You would also like to keep track of other helpful information such as the experimental setup you worked on.
51
+
# > * For each experimental session, you would like to record what mouse you worked with and when you performed the experiment. You would also like to keep track of other helpful information such as the experimental setup you worked on.
52
52
#
53
53
# > * In a session of electrophysiology
54
54
# >> * you record electrical activity from a single neuron. You use recording equipment that produces separate data files for each neuron you recorded.
@@ -64,7 +64,7 @@
64
64
65
65
# > * Your lab houses many **mice**, and each mouse is identified by a unique ID. You also want to keep track of information about each mouse such as their date of birth, and gender.
66
66
# > * As a hard working neuroscientist, you perform experiments every day, sometimes working with more than one mouse in a day! However, on an any given day, a mouse undergoes at most one recording session.
67
-
# > * For each **experimental session**, you would like to record what mouse you worked with and when you performed the experiment. You would also like to keep track of other helpful information such as the experimental setup you worked on.
67
+
# > * For each **experimental session**, you would like to record what mouse you worked with and when you performed the experiment. You would also like to keep track of other helpful information such as the experimental setup you worked on.
68
68
#
69
69
# > * In a session of electrophysiology
70
70
# >> * you record electrical activity from a **single neuron**. You use recording equipment that produces separate data files for each neuron you recorded.
@@ -92,7 +92,7 @@
92
92
93
93
# In the current notebook, we will design the tables for mouse and experimental sessions, the rest of the pipeline will be designed in the subdirectory `electrophysiology` and `calcium_imaging`
94
94
95
-
# In DataJoint data pipeline, we represent these **entities** as **tables**. Different *kinds* of entities become distinct tables, and each row of the table is a single example (instance) of the category of entity.
95
+
# In DataJoint data pipeline, we represent these **entities** as **tables**. Different *kinds* of entities become distinct tables, and each row of the table is a single example (instance) of the category of entity.
96
96
#
97
97
# For example, if we have a `Mouse` table, then each row in the mouse table represents a single mouse!
98
98
@@ -229,7 +229,7 @@ class Mouse(dj.Manual):
229
229
230
230
# ## Create tables with dependencies
231
231
232
-
# Congratulations! We have successfully created your first table! We are now ready to tackle and include other **entities** in the project into our data pipeline.
232
+
# Congratulations! We have successfully created your first table! We are now ready to tackle and include other **entities** in the project into our data pipeline.
233
233
#
234
234
# Let's now take a look at representing an **experimental session**.
235
235
@@ -245,11 +245,11 @@ class Mouse(dj.Manual):
245
245
#
246
246
# to uniquely identify a single experimental session.
247
247
248
-
# Note that, to uniquely identify an experimental session (or simply a **session**), we need to know the mouse that the session was about. In other words, a session cannot existing without a corresponding mouse!
248
+
# Note that, to uniquely identify an experimental session (or simply a **session**), we need to know the mouse that the session was about. In other words, a session cannot existing without a corresponding mouse!
249
249
#
250
-
# With **mouse** already represented as a table in our pipeline, we say that the session **depends on** the mouse! We would graphically represent this in an **entity relationship diagram (ERD)** by drawing the line between two tables, with the one below (**session**) dependeing on the one above (**mouse**).
250
+
# With **mouse** already represented as a table in our pipeline, we say that the session **depends on** the mouse! We could graphically represent this in an **entity relationship diagram (ERD)** by drawing the line between two tables, with the one below (**session**) dependeing on the one above (**mouse**).
251
251
252
-
# Thus we will need both **mouse** and a new attribute **session_date** to uniquely identify a single session.
252
+
# Thus we will need both **mouse** and a new attribute **session_date** to uniquely identify a single session.
253
253
#
254
254
# Remember that a **mouse** is already uniquely identified by its primary key - **mouse_id**. In DataJoint, you can declare that **session** depends on the mouse, and DataJoint will automatically include the mouse's primary key (`mouse_id`) as part of the session's primary key, along side any additional attribute(s) you specificy.
255
255
@@ -266,9 +266,9 @@ class Session(dj.Manual):
266
266
"""
267
267
268
268
269
-
# You can actually generate the entity relationship diagram (ERD) on the fly by calling `dj.ERD` with the schema object
269
+
# You can actually generate something similar to an entity relationship diagram (ERD) on the fly by calling `dj.Diagram` with the schema object. Many of the symbols and features are the same as the ERD standard.
270
270
271
-
dj.ERD(schema)
271
+
dj.Diagram(schema)
272
272
273
273
# Let's try inserting a few sessions manually.
274
274
@@ -397,17 +397,17 @@ class Session(dj.Manual):
397
397
# ENTER YOUR CODE
398
398
399
399
400
-
# In computer science/math lingo, DataJoint operations are said to **satisfy closure property**. Practically speaking, this means that the result of a query can immediately be used in another query, allowing you to build more complex queries from simpler ones.
400
+
# In computer science/math lingo, DataJoint operations are said to **satisfy closure property**. Practically speaking, this means that the result of a query can immediately be used in another query, allowing you to build more complex queries from simpler ones.
401
401
402
402
# ### Restriction one table with another
403
403
404
404
# All mice that have a session
405
405
406
-
Mouse&Session
406
+
Mouse&Session
407
407
408
408
# ### Combining restrictions
409
409
410
-
# All the above queries could be combined
410
+
# All the above queries could be combined
411
411
412
412
# Male mice that had a session
413
413
@@ -452,7 +452,7 @@ class Session(dj.Manual):
452
452
Mouse*Session&'session_date > "2017-05-19"'
453
453
454
454
# ## Projection .proj(): focus on attributes of interest
455
-
# Beside restriction (`&`) and join (`*`) operations, DataJoint offers another type of operation: projection (`.proj()`). Projection is used to select attributes (columns) from a table, to rename them, or to create new calculated attributes.
455
+
# Beside restriction (`&`) and join (`*`) operations, DataJoint offers another type of operation: projection (`.proj()`). Projection is used to select attributes (columns) from a table, to rename them, or to create new calculated attributes.
456
456
457
457
# From the ***Mouse*** table, suppose we want to focus only on the `sex` attribute and ignore the others, this can be done as:
458
458
@@ -556,7 +556,7 @@ class Session(dj.Manual):
556
556
# In the next session, we are going to extend our data pipeline with tables to represent **imported data** and define new tables to **compute and hold analysis results**.
557
557
#
558
558
# We will use both ephys and calcium imaging as example pipelines:
"This table is dependent on the table `Session`, inheriting its primary key attributes, with an additional primary key attribute `scan_idx`. One session could contain multiple scans, which is another example of **one-to-many** relationship. We could take a look at the ERD again."
145
+
"This table is dependent on the table `Session`, inheriting its primary key attributes, with an additional primary key attribute `scan_idx`. One session could contain multiple scans, which is another example of **one-to-many** relationship. We could take a look at the Diagram again."
146
146
]
147
147
},
148
148
{
@@ -151,7 +151,7 @@
151
151
"metadata": {},
152
152
"outputs": [],
153
153
"source": [
154
-
"dj.ERD(schema)"
154
+
"dj.Diagram(schema)"
155
155
]
156
156
},
157
157
{
@@ -296,7 +296,7 @@
296
296
"metadata": {},
297
297
"outputs": [],
298
298
"source": [
299
-
"dj.ERD(schema)"
299
+
"dj.Diagram(schema)"
300
300
]
301
301
},
302
302
{
@@ -333,9 +333,9 @@
333
333
"source": [
334
334
"In DataJoint, the tier of the table indicates **the nature of the data and the data source for the table**. So far we have encountered two table tiers: `Manual` and `Imported`, and we will encounter the two other major tiers in this session. \n",
335
335
"\n",
336
-
"DataJoint tables in `Manual` tier, or simply **Manual tables** indicate that its contents are **manually** entered by either experimenters or a recording system, and its content **do not depend on external data files or other tables**. This is the most basic table type you will encounter, especially as the tables at the beggining of the pipeline. In the ERD, `Manual` tables are depicted by green rectangles.\n",
336
+
"DataJoint tables in `Manual` tier, or simply **Manual tables** indicate that its contents are **manually** entered by either experimenters or a recording system, and its content **do not depend on external data files or other tables**. This is the most basic table type you will encounter, especially as the tables at the beggining of the pipeline. In the Diagram, `Manual` tables are depicted by green rectangles.\n",
337
337
"\n",
338
-
"On the other hand, **Imported tables** are understood to pull data (or *import* data) from external data files, and come equipped with functionalities to perform this importing process automatically, as we will see shortly! In the ERD, `Imported` tables are depicted by blue ellipses."
338
+
"On the other hand, **Imported tables** are understood to pull data (or *import* data) from external data files, and come equipped with functionalities to perform this importing process automatically, as we will see shortly! In the Diagram, `Imported` tables are depicted by blue ellipses."
"Let's define `Param` table to hold different parameter configuration for our spike detection algorithm. We are going to define this table as a `Lookup` table, rather than a `Manual` table. By now, you know that `Lookup` must be yet another **table tier** in DataJoint. `Lookup` tables are depicted by gray boxes in the ERD.\n",
409
+
"Let's define `Param` table to hold different parameter configuration for our spike detection algorithm. We are going to define this table as a `Lookup` table, rather than a `Manual` table. By now, you know that `Lookup` must be yet another **table tier** in DataJoint. `Lookup` tables are depicted by gray boxes in the Diagram.\n",
410
410
"\n",
411
411
"This tier indicates that the table will contain information:\n",
412
412
"* that will be referenced by other tables\n",
@@ -435,7 +435,7 @@
435
435
"metadata": {},
436
436
"outputs": [],
437
437
"source": [
438
-
"dj.ERD(schema)"
438
+
"dj.Diagram(schema)"
439
439
]
440
440
},
441
441
{
@@ -501,7 +501,7 @@
501
501
"metadata": {},
502
502
"outputs": [],
503
503
"source": [
504
-
"dj.ERD(schema)"
504
+
"dj.Diagram(schema)"
505
505
]
506
506
},
507
507
{
@@ -1006,14 +1006,14 @@
1006
1006
"metadata": {},
1007
1007
"outputs": [],
1008
1008
"source": [
1009
-
"dj.ERD(schema)"
1009
+
"dj.Diagram(schema)"
1010
1010
]
1011
1011
},
1012
1012
{
1013
1013
"cell_type": "markdown",
1014
1014
"metadata": {},
1015
1015
"source": [
1016
-
"We have covered most of the building elements of data pipeline design. Using these elements, we could design more sophiscated pipelines that facillitates your experimental recordings and data analyses."
1016
+
"We have covered most of the building elements of data pipeline design. Using these elements, we could design more sophiscated pipelines that facillitates your experimental recordings and data analyses. To see these concepts in the context of another methodology, see the next folder on [Electrophysiology](../02-Electrophysiology)"
0 commit comments