0:00:00.027,0:00:02.035 This video introduces JSON. 0:00:02.035,0:00:04.096 Let's start by talking about its pronunciation. 0:00:04.096,0:00:07.097 Some people call it Jason, and some call it J-sahn. 0:00:07.097,0:00:09.021 I'll do a little bit of 0:00:09.021,0:00:10.079 investigation and discovered that the 0:00:10.079,0:00:12.062 original developer of JSON calls 0:00:12.062,0:00:15.014 it JSON so, I'll do that too. 0:00:15.014,0:00:18.089 Like XML, JSON can be thought of as a data model. 0:00:18.089,0:00:20.051 An alternative to the relational data 0:00:20.051,0:00:21.098 model that is more 0:00:21.098,0:00:24.084 appropriate for semi-structured data. 0:00:24.084,0:00:26.041 In this video I'll introduce the 0:00:26.041,0:00:27.096 basics of JSON and I'll 0:00:27.096,0:00:29.022 actually compare JSON to the 0:00:29.022,0:00:32.059 relational data model and I'll compare it to XML. 0:00:32.059,0:00:34.007 But it's not crucial to have 0:00:34.007,0:00:37.015 watched those videos to get something out of this one. 0:00:37.015,0:00:38.006 Now among the three models 0:00:38.006,0:00:40.000 - the relational model, XML, and 0:00:40.000,0:00:41.008 JSON - JSON is by 0:00:41.008,0:00:43.046 a large margin the newest, 0:00:43.046,0:00:44.072 and it does show there aren't 0:00:44.072,0:00:46.057 as many tools for JSON 0:00:46.057,0:00:48.071 as we have for XML and 0:00:48.071,0:00:51.006 certainly not as we have for relational. 0:00:51.006,0:00:54.069 JSON stands for Javascript object notation. 0:00:54.069,0:00:56.002 Although it's evolved to become pretty 0:00:56.002,0:00:59.062 much independent of Javascript at this point. 0:00:59.062,0:01:03.006 The little snippet of Jason in the corner right now mostly for decoration. 0:01:03.006,0:01:05.077 We'll talk about the details in just a minute. 0:01:05.077,0:01:07.058 Now JSON was designed 0:01:07.058,0:01:09.068 originally for what's called 0:01:09.068,0:01:11.033 serializing data objects. 0:01:11.033,0:01:13.021 That is taking the objects that 0:01:13.021,0:01:14.055 are in a program and sort 0:01:14.055,0:01:15.067 of writing them down in a 0:01:15.067,0:01:18.077 serial fashion, typically in files. 0:01:18.077,0:01:19.097 one thing about json 0:01:19.097,0:01:21.086 is that it is human readable, 0:01:21.086,0:01:23.023 similar to the way xml 0:01:23.023,0:01:25.025 is human readable and is 0:01:25.025,0:01:27.004 often use for data interchange. 0:01:27.004,0:01:28.093 So, for writing out, say 0:01:28.093,0:01:30.031 the objects program so that 0:01:30.031,0:01:32.009 they can be exchanged with another 0:01:32.009,0:01:34.029 program and read into that one. 0:01:34.029,0:01:36.005 Also, just more generally, because 0:01:36.005,0:01:38.012 json is not as rigid 0:01:38.012,0:01:40.003 as the relational model, it's generally 0:01:40.003,0:01:42.015 useful for representing and for 0:01:42.015,0:01:43.049 storing data that doesn't 0:01:43.049,0:01:47.053 have rigid structure that we've been calling semi-structured data. 0:01:47.053,0:01:49.009 As I mentioned json is 0:01:49.009,0:01:51.044 no longer closely tied to 0:01:51.044,0:01:54.002 Many different programming languages do 0:01:54.002,0:01:56.000 have parsers for reading json 0:01:56.000,0:01:57.056 data into the program and 0:01:57.056,0:02:00.011 for writing out json data as well. 0:02:00.011,0:02:01.064 Now, let's talk about the basic 0:02:01.064,0:02:03.035 constructs in JSON, and as 0:02:03.035,0:02:06.052 we will see this constructs are recursively defined. 0:02:06.052,0:02:08.024 We'll use the example JSON 0:02:08.024,0:02:09.067 data shown on the screen 0:02:09.067,0:02:11.052 and that data is also available 0:02:11.052,0:02:14.035 in a file for download from the website. 0:02:14.035,0:02:18.029 The basic atomic values in JSON are fairly typical. 0:02:18.029,0:02:21.063 We have numbers, we have strings. 0:02:21.063,0:02:23.067 We also have Boolean Values 0:02:23.067,0:02:24.057 although there are none of those 0:02:24.057,0:02:29.019 in this example, that's true and false, and no values. 0:02:29.019,0:02:30.061 There are two types of composite 0:02:30.061,0:02:34.049 values in JSON: objects and arrays. 0:02:34.049,0:02:36.015 Objects are enclosed in curly 0:02:36.015,0:02:37.066 braces and they consist 0:02:37.066,0:02:40.029 of sets of label-value pairs. 0:02:40.029,0:02:41.069 For example, we have an 0:02:41.069,0:02:44.087 object here that has a first name and a last name. 0:02:44.087,0:02:46.076 We have a more - 0:02:46.076,0:02:48.063 bigger, let's say, object here 0:02:48.063,0:02:51.076 that has ISBN, price, edition, and so on. 0:02:51.076,0:02:53.028 When we do our JSON demo, 0:02:53.028,0:02:55.043 we'll go into these constructs in more detail. 0:02:55.043,0:02:57.067 At this point, we're just introducing them. 0:02:57.067,0:02:59.046 the second type of composite 0:02:59.046,0:03:01.016 value in JSON is arrays, 0:03:01.016,0:03:03.004 and arrays are enclosed in square 0:03:03.004,0:03:06.000 brackets with commas between the array elements. 0:03:06.000,0:03:07.039 Actually we have commas in the objects 0:03:07.039,0:03:10.053 as and arrays are list of values. 0:03:10.053,0:03:11.089 For example, we can see 0:03:11.089,0:03:13.062 here that authors is a 0:03:13.062,0:03:16.031 list of author objects. 0:03:16.031,0:03:18.002 Now I mentioned that the constructs 0:03:18.002,0:03:20.049 are recursive, specifically the values 0:03:20.049,0:03:22.018 inside arrays can be anything, 0:03:22.018,0:03:23.091 they can be other arrays or objects, 0:03:23.091,0:03:26.018 space values and the values 0:03:26.018,0:03:27.066 are making up the label value 0:03:27.066,0:03:29.004 pairs and objects can also 0:03:29.004,0:03:32.032 be any composite value or a base value. 0:03:32.032,0:03:33.066 And I did want to 0:03:33.066,0:03:34.092 mention, by the way, that sometime 0:03:34.092,0:03:36.012 this word label here for 0:03:36.012,0:03:39.077 label value pairs is called a "property". 0:03:39.077,0:03:41.052 So, just like XML, JSON 0:03:41.052,0:03:44.001 has some basic structural requirements in 0:03:44.001,0:03:45.035 its format but it doesn't 0:03:45.035,0:03:47.081 have a lot of requirements in terms of uniformity. 0:03:47.081,0:03:49.072 We have a couple of examples 0:03:49.072,0:03:51.053 of heterogeneity in here, for 0:03:51.053,0:03:52.069 example, this book has an 0:03:52.069,0:03:53.084 edition and the other one 0:03:53.084,0:03:57.071 doesn't this book has a remark and the other one doesn't. 0:03:57.071,0:03:59.036 But we'll see many more examples 0:03:59.036,0:04:00.079 of heterogeneity when we do 0:04:00.079,0:04:03.088 the demo and look into JSON data in more detail. 0:04:03.088,0:04:06.043 Now let's compare JSON and the relational model. 0:04:06.043,0:04:07.047 We will see that many of 0:04:07.047,0:04:09.029 the comparisons are fairly similar 0:04:09.029,0:04:12.067 to when we compared XML to the relational model. 0:04:12.067,0:04:15.094 Let's start with the basic structures underling the data model. 0:04:15.094,0:04:18.081 So, the relational model is based on tables. 0:04:18.081,0:04:20.007 We set up structure of 0:04:20.007,0:04:22.007 table, a set of columns, and 0:04:22.007,0:04:25.003 then the data becomes rows in those tables. 0:04:25.003,0:04:27.044 JSON is based instead on 0:04:27.044,0:04:29.046 sets, the sets of label 0:04:29.046,0:04:34.009 pairs and arrays and as we saw, they can be nested. 0:04:34.009,0:04:35.064 One of the big differences between 0:04:35.064,0:04:38.004 the two models, of course, is the scheme. 0:04:38.004,0:04:39.083 So the Relational model has a 0:04:39.083,0:04:41.074 Schema fixed in advance, 0:04:41.074,0:04:43.001 you set it up before you 0:04:43.001,0:04:44.008 have any data loaded and then 0:04:44.008,0:04:47.052 all data needs to confirm to that Schema. 0:04:47.052,0:04:48.005 Jason on the other other 0:04:48.005,0:04:52.011 hand typically does not require a schema in advance. 0:04:52.011,0:04:53.062 In fact, the schema and the 0:04:53.062,0:04:55.033 data are kinda mix together 0:04:55.033,0:04:56.065 just like an xml, and 0:04:56.065,0:04:58.054 this is often referred to as 0:04:58.054,0:05:00.068 self-describing data, where the 0:05:00.068,0:05:04.037 schema elements are within the data itself. 0:05:04.037,0:05:05.092 And this is of course typically 0:05:05.092,0:05:08.021 more flexible than the to a model. 0:05:08.021,0:05:10.006 But there are advantages to having schema [sp?] 0:05:10.006,0:05:12.031 as well, definitely. 0:05:12.031,0:05:13.076 As far as queries go, one 0:05:13.076,0:05:15.016 of the nice features of the 0:05:15.016,0:05:16.063 relational model is that there 0:05:16.063,0:05:21.096 are simple, expressive languages for clearing the database. 0:05:21.096,0:05:23.092 In terms of json, although a 0:05:23.092,0:05:25.096 few New things have been proposed; 0:05:25.096,0:05:27.095 at this point there's nothing widely 0:05:27.095,0:05:29.058 used for querying Jason data. 0:05:29.058,0:05:31.001 Typically Jason data is 0:05:31.001,0:05:34.055 read into a program and it's manipulated programatically. 0:05:34.055,0:05:35.086 Now let me interject that this 0:05:35.086,0:05:38.069 video is being made in February 2012. 0:05:38.069,0:05:40.064 So it is possible 0:05:40.064,0:05:42.037 that some json query languages 0:05:42.037,0:05:44.005 will emerge and become 0:05:44.005,0:05:45.008 widely used there is just 0:05:45.008,0:05:46.081 nothing used at this point. 0:05:46.081,0:05:47.093 There are some proposals. 0:05:47.093,0:05:49.094 There's a JSON path language, 0:05:49.094,0:05:52.037 JSON Query, a language called jaql. 0:05:52.037,0:05:53.056 It may be that just like 0:05:53.056,0:05:55.001 XML, the query language are 0:05:55.001,0:05:57.014 gonna follow the prevalent use 0:05:57.014,0:05:59.013 of the data format or the data model. 0:05:59.013,0:06:01.057 But that does not happened yet, as of February 2012. 0:06:01.057,0:06:04.002 How about ordering? 0:06:04.002,0:06:07.003 One aspect of the relational model is that it's an unordered model. 0:06:07.003,0:06:08.069 It's based on sets and 0:06:08.069,0:06:10.023 if we want to see relational 0:06:10.023,0:06:14.015 data in sorted order then we put that inside a query. 0:06:14.015,0:06:16.003 In JSON, we have arrays as 0:06:16.003,0:06:19.028 one of the basic data structures, and arrays are ordered. 0:06:19.028,0:06:20.088 Of course, there's also the fact like 0:06:20.088,0:06:22.025 XML that JSON data is 0:06:22.025,0:06:24.044 often is usually written files 0:06:24.044,0:06:26.071 and files themselves are naturally ordered, 0:06:26.071,0:06:27.068 but the ordering of the data 0:06:27.068,0:06:30.043 in files usually isn't relevant, 0:06:30.043,0:06:31.082 sometimes it is, but 0:06:31.082,0:06:33.062 typically not finally in 0:06:33.062,0:06:35.003 terms of implementation, for the 0:06:35.003,0:06:37.016 relational model, there are 0:06:37.016,0:06:39.091 systems that implement the relational model natively. 0:06:39.091,0:06:42.074 They're very generally quite 0:06:42.074,0:06:44.058 efficient and powerful systems. 0:06:44.058,0:06:46.027 For json, we haven't yet 0:06:46.027,0:06:48.009 seen stand alone database systems 0:06:48.009,0:06:49.078 that use json their data 0:06:49.078,0:06:51.036 model instead JSON is 0:06:51.036,0:06:54.058 more typically coupled with programming languages. 0:06:54.058,0:06:56.069 One thing I should add however 0:06:56.069,0:07:00.076 JSON is used in NoSQL systems. 0:07:00.076,0:07:02.061 We do have videos about NoSQL 0:07:02.061,0:07:05.029 systems you may or may not have, have watched those yet. 0:07:05.029,0:07:08.065 There's a couple of different ways that JSON is used used in those systems. 0:07:08.065,0:07:10.024 One of them is just as 0:07:10.024,0:07:11.087 a format for reading data 0:07:11.087,0:07:14.082 into the systems and writing data out from the systems. 0:07:14.082,0:07:15.063 The other way that it is 0:07:15.063,0:07:17.002 used is that some of the 0:07:17.002,0:07:18.007 note systems are what are 0:07:18.007,0:07:20.022 called "Document Management Systems" where 0:07:20.022,0:07:22.041 the documents themselves may contain 0:07:22.041,0:07:24.017 JSON data and then the systems 0:07:24.017,0:07:26.023 will have special features for manipulating 0:07:26.023,0:07:29.056 the JSON in the document is better stored by the system. 0:07:29.056,0:07:32.007 Now let's compared json and XML. 0:07:32.007,0:07:35.031 This is actually a hotly debated comparison right now. 0:07:35.031,0:07:37.083 There are signification overlap in 0:07:37.083,0:07:40.023 the usage of JSON and XML. 0:07:40.023,0:07:41.006 Both of them are very 0:07:41.006,0:07:43.099 good for putting semi-structured data 0:07:43.099,0:07:46.019 into a file format 0:07:46.019,0:07:48.027 and using it for data interchange. 0:07:48.027,0:07:49.051 And so because there's so 0:07:49.051,0:07:50.097 much overlap in what they're used 0:07:50.097,0:07:54.002 for, it's not surprising that there's significant debate. 0:07:54.002,0:07:55.004 I'm not gonna take sides. 0:07:55.004,0:07:57.069 I'm just going to try to give you a comparison. 0:07:57.069,0:07:58.008 Let's start by looking at the 0:07:58.008,0:08:02.065 verbosity of expressing data in the two languages. 0:08:02.065,0:08:03.098 So it is the case 0:08:03.098,0:08:05.075 that XML is in general, 0:08:05.075,0:08:08.033 a little more verbose than Jason. 0:08:08.033,0:08:09.099 So the same data expressed in 0:08:09.099,0:08:11.018 the 2 formats will tend to 0:08:11.018,0:08:12.063 have more characters [xx] than Json 0:08:12.063,0:08:14.026 and you can see that 0:08:14.026,0:08:16.053 in our examples because our big 0:08:16.053,0:08:18.007 Json example was actually pretty 0:08:18.007,0:08:20.054 much the same data that we used when we showed XML. 0:08:20.054,0:08:22.028 And the reason for 0:08:22.028,0:08:23.026 XML being a bit more 0:08:23.026,0:08:24.095 verbose largely has to 0:08:24.095,0:08:26.094 do actually with closing tags, 0:08:26.094,0:08:29.022 and some other features. 0:08:29.022,0:08:30.057 But I'll let you judge 0:08:30.057,0:08:32.058 for yourself whether the somewhat 0:08:32.058,0:08:35.064 longer expression of XML is a problem. 0:08:35.064,0:08:37.061 Second is complexity, and here, 0:08:37.061,0:08:39.029 too, most people would say 0:08:39.029,0:08:42.036 that XML is a bit more complex than JSON. 0:08:42.036,0:08:45.098 I'm not sure I entirely agree with that comparison. 0:08:45.098,0:08:47.069 If you look at the subset 0:08:47.069,0:08:49.021 of XML that people really 0:08:49.021,0:08:51.019 use, you've got attributes, 0:08:51.019,0:08:52.052 sub elements and text, and 0:08:52.052,0:08:54.008 that's more or less it. 0:08:54.008,0:08:55.029 If you look at Json, you got 0:08:55.029,0:08:58.038 your basic values and you've got your objects and your arrays. 0:08:58.038,0:08:59.043 I think the issue is that 0:08:59.043,0:09:01.036 XML has a lot of 0:09:01.036,0:09:03.038 extra stuff that goes along with it. 0:09:03.038,0:09:06.001 So if you read the entire XML specification. 0:09:06.001,0:09:08.012 It will take you a long time. 0:09:08.012,0:09:10.003 JSON, you can grasp the 0:09:10.003,0:09:12.068 entire specification a little bit more quickly. 0:09:12.068,0:09:14.034 Now let's turn to validity. 0:09:14.034,0:09:16.018 And by validity, I mean the 0:09:16.018,0:09:18.063 ability to specify constraints or 0:09:18.063,0:09:20.067 restriction or schema on 0:09:20.067,0:09:22.068 the structure of data 0:09:22.068,0:09:24.002 in one of these models, and 0:09:24.002,0:09:27.007 have it enforced by tools or by a system. 0:09:27.007,0:09:28.063 Specifically in XML we 0:09:28.063,0:09:30.029 have the notion of document type 0:09:30.029,0:09:32.045 descriptors, or DTDs, we also 0:09:32.045,0:09:34.062 have XML Schema which 0:09:34.062,0:09:38.025 gives us XSD's, XML Schema Descriptors. 0:09:38.025,0:09:39.082 And these are schema like 0:09:39.082,0:09:41.065 things that we can specify, and 0:09:41.065,0:09:42.089 we can have our data checked to 0:09:42.089,0:09:43.009 make sure it conforms to the 0:09:43.009,0:09:45.099 schema, and these are, I would say, 0:09:45.099,0:09:49.018 fairly widely used at this point for XML. 0:09:49.018,0:09:51.039 For JSON, there's something called JSON Schema. 0:09:51.039,0:09:53.097 And, you know, similar to 0:09:53.097,0:09:55.045 XML Schema, it's a way 0:09:55.045,0:09:57.008 to specify the structure and then 0:09:57.008,0:09:58.092 we can check that JSON conforms 0:09:58.092,0:10:02.057 that and we will see some of that in our demo. 0:10:02.057,0:10:04.088 The current status, February 0:10:04.088,0:10:07.014 2012 is that this is 0:10:07.014,0:10:09.015 not widely used this point. 0:10:09.015,0:10:11.054 But again, it could really just be evolution. 0:10:11.054,0:10:14.018 If we look back 0:10:14.018,0:10:15.074 at XML, as it was originally 0:10:15.074,0:10:17.076 proposed, probably we didn't 0:10:17.076,0:10:18.077 see a whole of lot of use 0:10:18.077,0:10:20.007 of DTDs, and in fact not 0:10:20.007,0:10:22.076 as XSDs for sure until later on. 0:10:22.076,0:10:26.008 So we'll just have to see whether JSON evolves in a similar way. 0:10:26.008,0:10:31.011 Now the programming interface is where JSON really shines. 0:10:31.011,0:10:34.096 The programming interface for XML can be fairly clunky. 0:10:34.096,0:10:37.054 The XML model, the attributes 0:10:37.054,0:10:39.007 and sub-elements and so on, 0:10:39.007,0:10:41.024 don't typically match the model 0:10:41.024,0:10:43.083 of data inside a programming language. 0:10:43.083,0:10:47.002 In fact, that's something called the impedance mismatch. 0:10:47.002,0:10:48.072 The impedance miss match 0:10:48.072,0:10:50.005 has been discussed in database 0:10:50.005,0:10:52.084 systems actually, for decades 0:10:52.084,0:10:54.058 because one of the original 0:10:54.058,0:10:56.045 criticisms of relational database 0:10:56.045,0:10:57.076 systems is that the data 0:10:57.076,0:10:59.072 structures used in the database, 0:10:59.072,0:11:01.071 specifically tables, didn't match 0:11:01.071,0:11:04.042 directly with the data structures and programming languages. 0:11:04.042,0:11:05.031 So there had to be some manipulation 0:11:05.031,0:11:09.014 at the interface between programming languages and the database system and that's the mismatch. 0:11:09.014,0:11:13.005 So that same impedance mismatch 0:11:13.005,0:11:15.015 is pretty much present 0:11:15.015,0:11:17.079 in XML wherein JSON is 0:11:17.079,0:11:19.083 really a more direct mapping 0:11:19.083,0:11:23.099 between many programming languages and the structures of JSON. 0:11:23.099,0:11:25.088 Finally, let's talk about querying. 0:11:25.088,0:11:27.012 I've already touched on this 0:11:27.012,0:11:28.008 a bit, but JSON does not 0:11:28.008,0:11:31.023 have any mature, widely 0:11:31.023,0:11:33.042 used query languages at this point. 0:11:33.042,0:11:34.058 for XML we do have 0:11:34.058,0:11:36.009 XPath, we have XQuery, 0:11:36.009,0:11:39.041 we have XSLT. 0:11:39.041,0:11:41.008 Maybe not all of 0:11:41.008,0:11:42.091 them are widely used but there's 0:11:42.091,0:11:44.004 no question that XPath at least and 0:11:44.004,0:11:46.093 XSL are used quiet a bit. 0:11:46.093,0:11:48.045 As far as Json goes there 0:11:48.045,0:11:50.066 is a proposal called Json path. 0:11:50.066,0:11:52.018 It looks actually quiet a lot 0:11:52.018,0:11:55.003 like XPath maybe he'll catch on. 0:11:55.003,0:11:56.076 There's something called JSON Query. 0:11:56.076,0:11:58.057 Doesn't look so much like 0:11:58.057,0:12:01.068 XML Query, I mean, XQuery. 0:12:01.068,0:12:02.095 and finally, there has been a 0:12:02.095,0:12:07.007 proposal called [xx] language, but 0:12:07.007,0:12:08.073 again as of February 2012 0:12:08.073,0:12:10.011 all of these are still very 0:12:10.011,0:12:13.016 early, so we just don't know what's going to catch on. 0:12:13.016,0:12:16.029 So now let's talk about the validity of JSON data. 0:12:16.029,0:12:17.073 So do JSON data that's 0:12:17.073,0:12:19.071 syntacti[xx] valid, simply needs 0:12:19.071,0:12:22.055 to adhere to the basic structural requirements. 0:12:22.055,0:12:24.011 As a reminder, that would be 0:12:24.011,0:12:25.061 that we have sets of label 0:12:25.061,0:12:27.035 value pairs, we have arrays 0:12:27.035,0:12:29.033 of values and our values 0:12:29.033,0:12:31.018 are from predefined types. 0:12:31.018,0:12:34.006 And again, these values here are defined recursively. 0:12:34.006,0:12:35.081 So we start with a JSON 0:12:35.081,0:12:37.019 file and we send 0:12:37.019,0:12:39.001 it to a the parser 0:12:39.001,0:12:40.051 may determine that the file 0:12:40.051,0:12:42.038 has syntactic errors or if 0:12:42.038,0:12:44.045 the file is syntactically correct then 0:12:44.045,0:12:47.074 it can parsed into objects in a programming language. 0:12:47.074,0:12:49.076 Now if we're interested in semantically 0:12:49.076,0:12:51.005 valid JSON; that is 0:12:51.005,0:12:52.064 JSON that conforms to 0:12:52.064,0:12:54.045 some constraints or a schema, 0:12:54.045,0:12:55.067 then in addition to checking the 0:12:55.067,0:12:57.088 basics structural requirements, we check 0:12:57.088,0:13:00.084 whether JSON conforms to the specified schema. 0:13:00.084,0:13:02.034 If we use a language like JSON 0:13:02.034,0:13:03.084 schema for example, we put 0:13:03.084,0:13:05.079 a specification in as a 0:13:05.079,0:13:07.096 separate file, and in 0:13:07.096,0:13:09.058 fact JSON schema is expressed in 0:13:09.058,0:13:11.002 JSON itself, as we'll see 0:13:11.002,0:13:12.063 in our demo, we send it 0:13:12.063,0:13:13.087 to a validator and that 0:13:13.087,0:13:15.099 validator might find that there 0:13:15.099,0:13:16.009 are some syntactic errors or 0:13:16.009,0:13:17.075 it may find that there are 0:13:17.075,0:13:19.031 some symantic errors so the 0:13:19.031,0:13:21.049 data could to be correct syntactically 0:13:21.049,0:13:23.055 but not conform to the schema. 0:13:23.055,0:13:25.074 If it's both syntactically and semantically 0:13:25.074,0:13:26.008 correct then it can move 0:13:26.008,0:13:28.017 on to the parser where 0:13:28.017,0:13:30.009 will be parsed again into 0:13:30.009,0:13:32.035 objects in a programming language. 0:13:32.035,0:13:36.022 So to summarize, JSON stands for Java Script Object Notation. 0:13:36.022,0:13:38.006 It's a standard for taking data 0:13:38.006,0:13:41.058 objects and serializing them into a format that's human readable. 0:13:41.058,0:13:43.029 It's also very useful for 0:13:43.029,0:13:46.001 exchanging data between programs, 0:13:46.001,0:13:48.012 and for representing and storing 0:13:48.012,0:13:51.022 semi-structured data in a flexible fashion. 0:13:51.022,0:13:52.077 In the next video we'll go 0:13:52.077,0:13:55.002 live with a demonstration of JSON. 0:13:55.002,0:13:56.026 We'll use a couple of JSON 0:13:56.026,0:13:57.006 editors, we'll take a 0:13:57.006,0:13:59.045 look at the structure of JSON 0:13:59.045,0:14:01.008 data, when it's syntactically correct. 0:14:01.008,0:14:03.054 We'll demonstrate how it's very 0:14:03.054,0:14:05.005 flexible when our data might 0:14:05.005,0:14:06.085 irregular, and we'll also 0:14:06.085,0:14:09.047 demonstrate schema checking using 0:14:09.047,9:59:59.000 an example of JSON's schema.