So, this is a type system for tomorrow. It's not about font faces, in the case that's what you thought, so feel free to leave now if you want to, I guess. Let's see, how do I get this to advance? False start. There it is. I don't know why that worked. Okay, so like I said, it's a type system for tomorrow. And what I'd like to do is kind of talk about entity types and how we can use them more efficiently, but include some ideas about how behavior and kind of break down how we tie behavior to our core data types and kind of the things that you would need to build ambitious applications with Drupal. I'm Gabe Sulis. I'm a back-end engineer at Atten Design Group. You can pretty much find me anywhere as Gabe Sulis, githubdrupal.org, Twitter. Like I said, at Atten Design Group, we like to work for agencies or for people who we like to say are cause-driven, cause-driven organizations, so universities, nonprofits, and GOs. We love working with those guys. We're a full-service digital design strategy and development shop based out of Denver, Colorado. I found this quote that kind of inspired this talk, and it was, bad programmers worry about the code, good programmers worry about data structures and their relationships. And Linus doesn't pull any punches, he calls bad people just bad programmers outright. But this other one, I think, puts it in a little bit better perspective, and it's smart data structures and dumb code work better than the other way around. And so in the context of Drupal, a data structure is an entity type, right? We use entity types to label data. We say this is a user, this is an article, this is a blog post, or this is some other random thing that we can identify as an abstraction. And everything interesting we do revolves around that idea of those data structures, those entity types. And working within an agency, you know, I'm not a big core maintainer, I'm not just focused in the code, I'm constantly just working on little projects having to solve a lot of the same problems over and over again. And I kind of got some deja vu. I'd see the same problems come up over and over and over again. And so I wanted to think about how can we use our data structures, how can we create and share behavior between them in order to solve these problems in a more generic way so that we're not writing custom code over and over again. How do we not recreate trees? How do we not recreate queues when we don't need to? And maybe not do access control in custom code over and over again for some complex use cases. So we read those concepts about data structures and our entity types in code, and we have to write that over and over again. But we can probably make it configuration, or a lot more configurable. So some examples of those problem types are kind of complex associativity. So what I mean by that is this user has a ticket for this flight, and those three entities might be related, a user, a ticket, and a flight. We also have hierarchical and ordered data. This classroom belongs to this school within this school district. Or nested data structures, that might be something like an office is located at this address, or this article has a pull quote. And so you've got an address embedded within an office entity or something like that, or complex access control. That's like this user should be able to see this entity if it has this field value, and then finally like triggered events that happen on entity cred. So when this node is saved, send an email or ping this person, right? So we solve these same problems over and over again, but we don't have generic solutions to them. And so we use contrib and custom code, and we have a little bit of out-of-the-box functionality to solve that. And we often see that when a need to a particular kind of pattern becomes blatantly apparent, right? We'll see something like paragraphs, ECK, or field collections come out. And they're all trying to solve the same problem of nested data structures. And sometimes they're better than others. And oftentimes I think that's because they're just in core these blunt points of extension, right? You only have hook entity insert, hook entity update, and those kinds of things to actually start to work around these types that we've just defined in the system. And so without a lot of discipline within an organization, solutions to those common problems can vary widely. You can't get the same thing over and over and over again. And it also becomes very hard to teach new people about that. It's not accessible to the novice programmer, and it's not accessible to the new hire. So why does that matter? About a year ago, my fiance started her own business, and she needed a small website. Her needs were simple, maybe a page or two, maybe a blog, and just prominent contact information. It needed to be low maintenance, and the editing experience needed to be intuitive. I didn't recommend Drupal to her, right? It would be overly complex, it would just, it would be a time suck. It would be hard for her to use without a lot of custom work. And there are a lot of other solutions out there. But then, not long after that, I was talking to my friend, and we were discussing how so many people in businesses and entrepreneurs are kind of left out of this information revolution that we're experiencing. And they're still stuck on paper, right? They're using Excel. They can't create applications that solve their problems, right? And so he had, during his time in college, he had spent a couple of years working for his dad's company. And he remembered how everything he did was on paper, and that they had all this information in filing cabinets, right? They could go back and they could see a historical record of how much things it cost, how long it had taken to complete them, but it was totally inaccessible to them. So in only a few hours, we were able to use Drupal to mock something up that would let them put their estimates in, and actually create some application where they could start to record their, the actual needs of their business into a Drupal site, into a technological piece of work, right? And so that's where Drupal is great, right? It's this great, fantastic tool for building something custom to solve your real needs, either individually or in a community. And so with some dedication to perseverance, you can get really far, really quickly. And with perseverance, you're gonna build something that actually gets something done, right? And so I think in Drupal, we've seen a lot of hand wringing about, are we going more enterprise or are we trying to help the little guy, you know? And how do we solve those things? And I think it's been presented in a way that's forcing us to choose. And I think that if we kind of look at Drupal a little bit differently and see what it's really good at, we can bring those two together. And they don't have to be mutually exclusive, right? And so just as that lone individual can create powerful tools to make their ideas actually happen, an organization, the enterprise, can benefit because they can reuse the same patterns across their many business needs with the same Drupal application, right? And do the same thing in repeatable ways. And so where Drupal really shines is its ability to build malleable solutions to unique sets of problems. User-fieldable entities and generic behaviors composed together to solve those problems, right? And so I think we kind of need to think about Drupal and the types that we're providing to people and the behavior that we make available, kind of like a language designer of like C or Go or Haskell, thinks about how to create a programming language. They expose concepts like recursion or Lambda functions or something like that to programmers in order to put those together in interesting ways to solve unique problems. And they can't envision what the problem is that somebody is going to solve with that, they can just say that I know these ideas, these concepts put together will be able to solve those things. And so we can't know what people will do, but we can expose behavior and ideas to people in a more accessible way so that they're not so closely tied or kind of tangled up inside Drupal core. Yeah, so what are those data structures, concepts and behaviors that I'm talking about? So just some basic ideas of what a data structure is when I'm talking about it, right? It's big clumps of relatively simpler data. So you could say a map, a list, a queue, a set. We'll go into each one of those and how they can solve particular problems, right? So the simple example of a map in Drupal is just a profile page, right? The map is the key in a map, a map is made up of keys and values. In our case, a field first name or field last name is the key and a string is its value. But then we can also say like we have some organization and its users are, we have field users and that's the key. And it's an entity reference to users and those are the values, right? So you can compose maps of many things using entity types. And they could be put together in many interesting and complex ways. But between, so that's the entity type, right? That's all we have right now. It's just a map to some extent. But other data types that we might see in programming are things like a list or an array, and it's just a meta structure, right? We can deal with these many items all as one unit and we can pass that around and use that. And so we might see something like that in Drupal as a multi-value field or using the contrived module as like entity queue. Queues are interesting in that they're a lot like a list except the order isn't defined by the entities within the list. It's defined by the time that they go into the queue itself, right? We have trees, we see that in taxonomy and we have sets. So you can take blue, and you can say aqua and navy are a member of some taxonomy tree, and then you can tag nodes. And you can say stuff like all these three nodes are members of the set aqua, but they're also members of the set blue. And you can do the union or the difference or the intersection of those things using taxonomy trees. And so just their mere presence in a set, right? A node doesn't know any of the other nodes in its set. But it knows that it belongs to the group blue. And so then the concepts, right? So no longer just structure, but concepts that we can put together in a way to solve problems. And that's first is just order. The idea that we can put things in an order, something can come before something else, right? And applications that need that might be like staff seniority lists or user preferences, right? You should be able to let people create applications that utilize the idea of order to solve their problems. You would let people arbitrarily group entities without saying anything about their category, which is kind of what you have to do if you use a field and referencing those. We should make order available outside of just a field list or something. You have hierarchy, right? So if we had hierarchy as this thing that we could use for any entity type, we could let people do family trees or say, make an organization entity type and then put that in a hierarchy. So you might have the international order of dog lovers and then like the Peruvian order of dog lovers and the American order of dog lovers. And these things form a hierarchy even though they're all the same entity and they're not necessarily terms or something, right? Identity is another concept that needs to be accessible. That's basically addressable, can we point to it? Can we reference it? Can we load it when we want it? And identity, you've got kind of two different things like uniqueness. Whether, I mean it has to be unique to be an identity, but also random versus deterministic, right? So we expose through config entities this idea of a deterministic ID, right? When you use a machine name, you're saying this is generated in some way that I can know exactly how to type it. I can program around this entity, this ID. It's kind of like a problem of syncing taxonomy terms between environments. You're using a UUID or a term ID and those aren't deterministic. Those are generated at the time that they're not determined by the nature of the entity itself. And composition. So this is the idea that you can take smaller things and build up to greater things, right? And composition is absolutely everywhere in Drupal. We see it in address module, paragraphs, ECK, media entities, the phone numbers. It's basically we take these smaller sets of like area code, phone number, country code, and we put those together into something we call a phone. And that gets composed together with a contact to give a little bit more information. And in Drupal, we see that the unit of composition is the entity reference. That's how we glue these things together into bigger forms. And then finally, there's association, right? Association is the idea that two things can be related to one another, but not necessarily part of the same thing. They're not embedded within one another. Like an address might be embedded within an office. And association is two distinct things. Like two users have a friendship between them. And just to say, just to break that difference down a little bit, composition might say that you put a paragraph inside of a node. But association actually keeps those things distinct. And we might use entity references to say the ticket, right, is composed of the flight and the passenger. But the passenger really has no need to directly have like a field flights or something. Or the flight doesn't need to have a field passengers because you couldn't describe complex things about that association between them. Are they an economy or are they in first class? If you're just using a field, you'd be hard pressed to differentiate the nature of their relationship. And then observability, that's just the idea of if this, then that, right? When this node is saved or updated, do some action. And we have access to that right now in code, but we haven't exposed it without maybe something like the rules module, very well to site builders. Okay, so where are we? With these ideas. Order, we can basically expose that through taxonomy weight, field weight, book weight, and views sorting. But of course taxonomy means that we're limited to taxonomy terms. And taxonomy itself kind of confounds hierarchy and order. You can't just have an ordered thing that doesn't also imply some parent-child relationship. Book is again limited to nodes, you can't use it with anything else. Entity reference, field weight is kind of most like what we'd want. But we've not built any special functionality about creating order between many entities without having to create some list or really utilize that in some easy to inaccessible way to everybody. But we also see the entity queue module in contrib, and I think that's telling us that there's a need for it. In some examples, it's like a drip campaign. You put 15 blogs in a queue and then we're just gonna publish one every day or something like that. That might be something you could build if you had access to order without wanting to, I guess, do some custom code. Hierarchy, we sort of have it, right? We have it through taxonomy terms, we have it through the book module. Ad hoc entity references, but again, a lot of the same stuff applies, right? It's limited to terms, limited to nodes, and there's not a lot of special functionality around it. Identity, I think that's pretty clear. We have UUIDs and machine names, and so we're actually really good on identity. Composition, actually, we're really good and well placed there, right? We have entity references and they're absolutely everywhere. The problem with the core entity types we have now, if we look at something like node, is that we have no behavioral opt in or opt out, right?  You can't just make an address node, you have to actually install the address module, and so that means it's less discoverable to users. You can't just use it as to compose data structures out of something very simple, the same idea of nodes for everything. And we see other things like dynamic entity reference and inline entity form, they're all kind of telling us that composition is really this thing that we should focus on. And as far as association goes, we have nothing, right? Nothing exposes that idea of complex relationships between entities in a way that's usable. We kind of, in core, right? Contrib, we see like the OG module, which has created its own membership entity. But unfortunately, that's kind of limited to like your grant, organic groups module, and you can't express things beyond membership, right? And kind of hacking it together. And so we can imagine like this is some code from OG, right? You'd say create this membership between an entity and a user, and then you could save that membership. But more generally, if we had some support for that in core, we could say like create an association called a ticket between a flight and a user and save that ticket. And we could create all kinds of different associations and have easy ways to access those. For example, we could get all tickets ever sold for a particular flight using some common code that unifies those different ways of expressing association between entities. So it's kind of aspirational, but I think we could do something like that. As far as observability goes, right? We have hooks, action plugins, and condition plugins. And as far as core goes, the action plugin allows us to create actions that fire when an event happens, right? Like an entity is inserted, send an email, right? But because we haven't exposed those in any meaningful ways, user aren't really able to use those actions without getting into custom code, right? Condition plugins allow us to say if this node is created and it's tagged with blue, then do something different. We have them for exposing blocks on a page. But conditions plugins are actually these really cool thing, but we don't use them in any meaningful way, but you're on just block placement. So you can imagine doing all kinds of interesting things with condition plugins. And so I wanna, this is really quite fast, but the takeaways I think are that we have a lot of stuff in core, right? We have the idea of hierarchy, we have the idea of order, but we have tied them very specifically to entity types, right? We've said that if you want to create hierarchy, you have to use taxonomy terms. You can't just make them out of any entity. If you wanna get a node page, right?  You can't use that to compose things like an address or a phone number or something like that. And so I think what we can do is look at those concepts and think, let's pull them out in an interesting way. Allow us to create a new entity type out of our own fields and then say this thing can belong to a hierarchy or this thing can be put into an ordered list. And let people put these together in more unique ways, right? We cannot tie them to our entity types. Our data types are locked to our behavior. The idea of fieldable associations is not in core. And then we don't have condition plugins exposed in meaningful ways. And then action plugins are just this kind of unused thing, because we basically expose it in no meaningful way. You can't use conditions to trigger them. You can't use anything but the rules module, which isn't using these action plugins to actually make behavior happen. And so if we can kind of look at this idea and say, how do we let people use Drupal Core to build useful applications and put these ideas together in better ways, then we're not democratizing the ability to create these applications. We're not saying Drupal is gonna be a platform to build a great blogging thing, right? We can't just let somebody create a distribution just using Drupal Core or their own custom blogging platform that people are gonna be more likely to use. That went much faster than I expected. Let me know what you think. Feel free to tweet at me. Keeps Elise. Leave me a review on Drupal.org or the event thing on Drupal.org. And don't forget to take the survey monkey for the conference, yeah. So we have a lot of the tools in core right now with the type data API. So my question is, what is your kind of vision for exposing all the data API in meaningful ways for site builders? And maybe you can explain a little bit about what your vision is. Absolutely, okay. So if you look at the book module, I think it's a really interesting idea of how we're exposing hierarchy to different entity types, right? And what you do is you can create a new book, and that happens to be a node. And that book, you can actually add new nodes to, and you can arrange them into a hierarchy. I think one of the things that you'd look to is look at the book module and say what can we rip out about this that's specific to hierarchy, right? And let people create those things, make a config entity called a hierarchy that nodes can be added to, or any custom entity could be added to. The same goes for queues, you could create config entities as queues and let people add those to queue. Does that answer your question? Yeah, and so just continuing on that conversation, you're thinking about interfaces or providing a user interface around exposing the item list data type or the map data type which already exists.  So we'd have to change something about that to allow that to expose and extend from the core data types as their own kind of non entity or entity thing. Yeah, are you saying that you want to kind of expose typed data itself to it through the UI? I mean, that's what's currently in core is typed data. And so most of these things are already possible if you use typed data. But as you said, it requires a developer, a programmer, and it's not easy and it's not something we can necessarily expose in the UI very easily. I'm not sure that's true, right? We expose a hierarchical thing for taxonomy terms and we know that we can move these terms around in that list just by creating a new, you had something to say? Okay, yeah, we have things exposed that expose these concepts, right? We don't necessarily need to go to typed data to expose a map, right? We can use entity types and that's an analogy, right, to what a map is. You've got custom fields, a bundle, for example, is a way to create new schema for different maps. I kind of disagree with that because I'm a big type data low level person. Yeah, I like creating data types that don't necessarily have storage implications. So you could use, we could extend from those that base type data and come up with different storage and whatever that's not entity based. But I think that definitely coming up with better newer data types is a good thing, like the set. Okay, absolutely. Yeah, I've looked at typed data, I think it's awesome. The reason I wanted to come here is because I know that there's a lot of talent in this room, right? There's a lot of people at this conference who understand the typed data system and I wanted to kind of get your juices flowing and say like let's look at typed data or let's look at the entity type system and actually make these things available. If you'd like to talk more, we can discuss those ideas, I'd love to. I mean, some of this sort of feels like what entity ECK tried to do. So it sort of generalized stuff, which I really like the module, but I was just looking at it as like 18,000 usage. But I think to some extent is there also, I feel like people are often looking for like a story about how to use these concepts rather than just like the random concepts, whereas like the book and the book module, like the group's module say, like they're sort of, they see it as, as you know, membership in a group. So I think if you're not a programmer, if you're not sort of in the developer mindset and you see something that has a story that this is groups, it means something more than just generic associations to get people's sort of mind around how I might use this. Whereas if we expose, if we build something that is just sort of generalized, exposes generalized concepts, will it be like what's the subset of the sort of, I feel like the intersection of people who would want to use it through the UI and the people who also could code it, would they choose to be, I would choose to code it instead. Like if somebody gave me a UI to do all this stuff, but also like just these generalized things, but I could also do it in code, I would probably choose to do it in code when we get to this sort of generalized level. But we're building, but to some extent, Drupal builds tools for people who aren't coders, who might not choose to code it or haven't learned to. But I think if you're doing that and they don't have sort of the backstory of these generalized ideas, it's really hard for, it's really hard to figure out these generalized ideas unless you have to say, oh, this is a taxonomy term and you can order your taxonomy terms rather than, hey, here's the general idea of ordering things. Is there, have you thought about like how do we, where's the line between sort of exposing these generic concepts to sort of guiding people into how they might use them? Yeah, I think maybe I didn't express the thought as clearly as I wanted to. And that these concepts are, the reason I identified these concepts like order and hierarchy here is to say that we should, they should be individually put together and composable into pieces. But it's not the end user that necessarily has to compose them together, right? If you wanted to create something like the book module, you could reach for ideas in core and put those together into a module that mostly be configuration for like, okay, we're gonna create a book entity type that comes as configuration, as default configuration with the book module, right? But it's just using under the hood this idea of maybe a hierarchy entity or a hierarchy type data structure and then exposing forms to use that. But it's just basically let's break them apart. Let's not say you have to use terms or nodes to create hierarchy, just that we have hierarchy and it works with entities. And so if you need to reach for something else, yeah. So one thing that I, cuz I'm friends with Gerard, the guy that made the ECK. And one thing that me and him had talked about is that it's really hard, it's hard for people to conceptualize how to use it, even though it's like super powerful. And I had a suggestion for him that he never took, but I think it's an interesting idea is to write a distribution that uses something like ECK and removes as much as possible from Drupal Core instead. Because as long as you have things like nodes and taxonomies and stuff, terms that have stories around them. And you're not saying, hey, you can build stuff with generic entities.  But if you could just say, okay, here are the building blocks and I'm not going to give you these things that I've already built these behaviors and assumptions around. Then I don't think people are going to sort of build those things. Unless that's the only option you give them. Yeah, I think the quickest when I've seen it is just like looking at the node module and the node entity type. And looking at the things that make people hesitant to use them in those interesting ways and the reason that they went to ECK, right? If you don't have a required title field, if you don't automatically generate node slash node ID for every bundle, right? Then these things become a look a lot more composable. And so it's very easy to ship with the article bundle for a node that has a title field, but not necessarily require that every bundle have a title, right? Or every bundle have a page. And so it's something that you can configure out of the box and provide that to somebody, but just still have a more generic entity underneath. I kind of imagine that almost everything would become a node if we started breaking these things out, and bundles would just kind of be. I wouldn't have gone down that road before. Yeah, I know, I know. Bundles for everything or ECK for everything, right? Another thing that's been discussed recently is using GraphQL to expose data definitions from the entity definitions and being able to do some of that association just in code rather than in storage. So that's something else to think about. Yeah, no, a lot of these I worked on the JSON API module and we had to make the decision to only expose bundles. We couldn't just say expose all nodes because the schema was different between bundles and thinking about things in terms of types really helps you think about that. And there are, of course, relationships between entities in the JSON API as well. Do you see anything wrong with the entity reference stuff within core? I mean, I sort of think of what you've shown with the airlines of being in sort of the classic database thing. If you've got a many to many relationship, you kind of have a join table. We could have some sort of joint entity that had any references to the two items. Yeah, I'm just curious about your thoughts on that. Yeah, so I think that just like you might add the behavior of being put into a hierarchy, you might add the behavior of being an association between two things to an existing node bundle or something like that, right? And that configuration would allow us to kind of optimize queries in some way, right? Like automatically add the joins to say, when we're doing, where did I go with that code? Code like this to say, give me all the tickets sold or give me all the passengers from a flight, by using that information that this thing is an association, we can start to optimize around that and create join tables for nodes that have been flagged as associations or something. Yeah, I think that's what I wanted to say. I'm hesitant to go with like a new entity type as an association, because I think it falls prey to like the same thing that we have with taxonomy terms now, which is like a taxonomy term is this custom entity type. And the only reason it's a custom entity type is to expose custom behavior, rather than just saying, let's have genericized entity types and allow behavior to work with any entity type. And I know that's a difficult problem to solve, but that would be an interesting way to put things together, right? Thanks, guys.


Ladies and gentlemen, the story you are about to hear is true. The names have been changed to protect the innocent. Dragnet is brought to you by Chesterfield, made by Liget and Myers. First, major tobacco company to bring you a complete line of quality cigarettes. [?].  You're assigned to robbery detail. 14 women in your city have been robbed and beaten. You've got a half dozen descriptions of their attacker. None of them match. The man's still free. Your job? Get him. Chesterfield's for me. You hear it everywhere. Tonight, we hear from America's number one band leader, Ray Anthony, who, with his attractive wife, D, plays college dates from coast to coast. In cigarettes, the young crowd really goes for Chesterfields. I've noticed that wherever we've played. And I guess it's one of the reasons Chesterfield is America's most popular two-way cigarette. Of course, D and I are Chesterfield smokers, too. We know they're best for us. Chesterfield's for me. You hear it everywhere.  They satisfy millions. Dragnet, the documented drama of an actual crime. For the next 30 minutes in cooperation with the Los Angeles Police Department, you will travel step by step on the side of the law through an actual case transcribed from official police files. From beginning to end, from crime to punishment, Dragnet is the story of your police force in action. It was Wednesday, November 26. It was cold in Los Angeles. We were working the day. Watch out a robbery detail. My partner's Frank Smith, the boss's chief of detectives, Thad Brown. My name's Friday. I was on my way back to the office. It was 2.34 p.m. when I got to room 27A, robbery. Come on, Joe. Everybody's in the skipper's office. All right. I take Bayard and I to pick up these packages. Anything on them? No, not much. We'll check them out. But they don't look like they're going any place. Go ahead. Joe, Frank, you want to come over here? Yes. Sorry we're late. Don't worry about it. Let's get this thing on the road. All right. Want to settle down? Let's get started. The word's probably gotten to you about why we're here. It's on this purse-snatching thing Friday and Smith have got. Things gotten way out of hand. Thief hit again the night before last. Victims at the county hospital in a critical condition. She was pistol whipped, and it looks like she's got a fractured skull. It's only a matter of time before somebody's killed. That's the reason we're here, to see that it doesn't happen. Now, you all got Mimeograph demo sheets. On it, you'll find what information we've got, some of it's pretty broad, but it's the best we've been able to come up with. Friday and Smith have handled the thing to here, so I'll let them give you the details. You want to tell them? Yeah, all right, Skipper. Well, first off, you'll notice on those M.O. sheets all of the crimes have been listed in the order that they happened. Also the place and the time. There's also a description of the clothing the suspect wore, and when we could get it, a description of the suspect. Now, you'll notice that in most cases, there's quite a difference there on the physical description of the suspect. However, we've been able to put them all together, and we've come up with a composite drawing that should look something like the suspect. The one thing that's fairly constant is the description of the clothing worn by the suspect. It's almost always dark. Where's a hat? And he's been known to wear a top coat. Now, the hat and the coat are also dark material. Clear? Yeah, buddy? All right, now, take a look over here at the wall map. Now, we've pinpointed all the jobs so you can get a little better picture of the operations. Can y'all see? There? All right. The first one took place at 73rd Street just off Broadway, right here. The rest of the pins along here show the jobs that he made from there, all the way up to Jefferson. He's also worked Avalon Boulevard, Central Avenue, Kenny Street, where there's a street car or a bus line he's hit. He works between the hours of 5.30 and 11.30 PM. The approach is almost always the same. Frank, you want to tell him about the victim? Yeah. The victim will get off the street car usually, or the bus, whatever it is, and starts to walk home. As soon as the woman gets in the area that's not lighted well or that hasn't got much traffic, the guy walks up behind her and grabs him. After that, he tries to take a purse. If the victim offers any resistance, well, he usually slugs him, cause the fact that two of the victims have seen a gun in his hand. We know he's armed. So the gun's been described as revolvert. How about a car, Joe? Excuse me, a suspect drive one? Car? Yeah. Well, we've got to assume that, yeah. He's been seen a couple of times by people in the neighborhoods as he ran through their yards. Pretty safe to figure that he's got a car parked on the side street somewhere. None of the victims have seen a car, however, but we know he leaves the area immediately. No descriptions of the vehicle, huh? No. No, we've had a couple of calls, but they didn't check out. Now, the plan here is to use police women as decoys and try to bait him out into the open. That's the reason the women officers are here. Do you figure to work the main arterials? What was that? You figure to work the main arterials. Yeah. Yeah, there'll be two officers assigned to follow each police woman. We've been able to obtain 10 in all. That'll mean that 20 officers will be assigned to them. The rest of you will be in the area somewhere. Now, one of the things to look for is any vehicle which closely follows a streetcar or a bus. Mm. That's right. What happened? How about any questions? Yes, how are we going to get our assignments? Well, a skipper here has a list, Lomi. All of the officers who are to work with a police woman are noted. Now, the others are given the areas that they're supposed to patrol. What about other calls coming in? What? I didn't hear you. The other calls coming in. Who's going to handle them? Well, those officers not assigned to a police woman. See, there'll be other units from the outlying areas on the operation, too. They'll lend us a hand. But remember this. Under no circumstances are those officers working with the decoy to leave her. Isn't that clear? Yeah. Don't leave the police woman. Well, then we stick with the detail unless there's an emergency call. Yeah, that's right. Well, if we run into any problems, who do we call, Joe? Well, we'll be in the area in 1-K-8-0. You can get in touch with us, Harry. How about it? Well, if we pick up a suspect, should we get in touch with you? Well, you can use your own judgment on that, George. If you think it's a routine pickup, take him to robbery, and you'll be processed there. Any more questions? Skipper, anything else? We all know about the day's off cancellation. Sorry it has to hit now, but that's where it's got to be. No one will draw any time till this thing is cleaned up.  That's it. The operation will start tonight and go until the suspect's in custody. Have a happy Thanksgiving. OK. So, wait a minute. Before you go, the worksheet's on the board outside. You can check it on the way out. You better do that. Right. Is there anything else you need to carry it off? No, it's all there, Skipper. I mean, we can use now as luck. No reason for you to be different, huh? Suspects, that is, Sheriff. Frank and I left the office and drove out to the area of the operation. The plan was that the police women would board the cars and buses and get off at the points where previous sluggings had not taken place. In the established demo of the suspect, it was noted that he never hit on any street more than once. At 4 PM that afternoon, all of the units were in place and the plan was started. During the night, several pickups were made, but no one was apprehended who resembled the suspect. Those people who were detained were processed and they were either booked or released. The following day, Thursday, November 27, Frank and I checked the reports filed by officers in the field. At 3 PM, we stopped at a small restaurant and we had to play the sliced turkey, cold gravy, and some lumpy mashed potatoes. We wished each other a happy Thanksgiving. We went back to Unit 1 K80 and cruised the streets marked for surveillance. Another night went by without the suspect hitting. Saturday, November 29, 1130 PM, Frank and I were driving down San Pedro Street at Vernon Avenue. Looks like another one, Shaw, huh? It has to be in the shape up that way, isn't it? You figure the suspect knows about the operation? I mean where we're working. You got as much as I have, doesn't seem likely. You got a cigarette? I'm out. Yeah. There you go. Thanks. Yeah, I'm going to give you a light. 660-827 North Lebray, a traffic accident. Fay was sure hacked about Thanksgiving. Well, I figured. Now, it didn't make me too mad. She had the in-laws over. Yeah. Her brother. One thing about that guy, he can eat more than any 10 people.  Yeah. Nephew was over, too. You know little Sam? You've heard me talk about little Sam? No, I don't think so. Yeah, little Sam. Kid's a monster. Only 10 years old, and he's a real monster. Fay's sister lets the kid do whatever comes into his mind. They say it isn't good to repress him. What? They say it isn't good to repress him. That's what they, you know, repress him. Yeah. I'd like to take him over. I'd repress him. Yeah, I guess you'd do that real good, wouldn't you? 1K80, 1K80, meet unit 1K87 at the 300 block east 51st Street, code 2. 1K80, Roger, KMA 367. Let's go. Yeah, that's one of the units assigned to a decoy. Think it's a good one? Well, there's one way to find out, isn't there? Yeah. Ask them. South Park is located at the corner of San Pedro and 51st Street. One of the police women had gotten off a streetcar at the corner of Main Street in 51st. She'd walked east, and as she passed the park, a man had approached, blocked her progress, and demanded money. The man was pretty drunk, and when the officers following the woman arrived at the scene, he was struggling with a police woman. He was taken into custody, and we were called. We took the man to room 27A, and from there to the interrogation room. Physically, he matched the description of the suspect as we'd gotten from the victims, 12.15 AM. That's the dirtiest thing I've heard of, pulling me in here like this. All right, what's your name? I don't think I'm going to tell you. Let me see your wallet. There's nothing in there. No juice. Empty your pockets on the table. If you have a copy of the LA phone, come on, Mr. Empty your pockets, will you? All right. Come on, everything. How about your wallet? Hey, young man, no juice? Take the money out. I told you there's no juice. No money in the wallet? No. All right, how about it? What's your new name, Victor Nathaniel Roberts? You think I use aliens? I don't be smart. Where do you live? Well, I have no path. Where have you been sleeping? Where have I been? You got a job? What? Do you work? No. You ever hold a job? No. Never had a job. Can't remember what. What were you doing on 51st Street tonight? Well, I was just looking around. At 1130 at night? The sun hurts my eyes. All right. I would just walk along the street for this young woman to stop me. She stopped you? She tried to pick me up. That girl was a police woman. You're telling me. Now, what were you doing out there? I'm never going there again. Ever been arrested? I am now. Before? I'll tell you the truth. Yeah, you do that. I have. Where? All around. What were you arrested for? Vag. Have you done time in California? Come on, have you done time in California? Have you? Yes. I'll check the record, John. Is he going to look me up? What's that? I say, is he going to look me up? He's going to check your record, yeah. Officer, you might have a little constructive criticism. Now, you listen, Mr. You're funny times running out here. You must feel a little sneaky about this whole thing, don't you? What's that? I mean, this whole business about the police woman. Don't you think that's going too far? How long you been in Los Angeles? Oh, sometime this year. What do you mean by that? Oh, checked in about a year. What? I said, I checked in about a year. A year ago, you mean? Yeah, yeah, about a year ago. Well, if you haven't got a job, how do you manage to live? I haven't got a little drink, have you? Joe. Yeah. See you in a minute. Fine. He sits still. What do you got? Checked R and I, got the word on Roberts. Yeah, what about him? He's been tagged 67 times for drunk. All in LA? Total's 92. Doesn't look like he's our man, though. Why? Well, he's been in Camarillo for the last three months. We put on a call to the superintendent at the state hospital up at Camarillo. He told us that Victor Roberts had only been released 10 days before. He'd spent three months undergoing treatment for alcoholism. The suspect we were looking for had been working for the past two months. Roberts was booked in at the main jail on the charge of violation of section 4127 ALAMC. During the time we'd been working on the case, all known purse snatchers had been picked up and interrogated. Runs by the stats office had been made and the names they gave us had been checked out. Locals and APBs were gotten out carrying the description in the MO of the suspect. The leads that came in were followed up without result. Informants were questioned and George Bratton up at CII and Sacramento furnished us a list of possibilities. All in all over 100 people had been questioned. In the course of the investigation several other cases were cleared but our prime suspect was still free. Meantime the operation continued. Each night at 4.30 p.m. 10 police women would board street cars and buses in the area. 10 police cars carrying 20 officers would follow them. In the immediate vicinity another 40 men were patrolling the streets and alleys looking for the thief. As a result of the newspaper stories on the string of crimes calls were coming into the complaint board at such a rate that they were jamming our normal facilities. Women refused to walk the streets alone after dark. Apparently the thief could come and go as he pleased. In the next two days he hit three times but in areas that were not covered. He began to hit in places he hadn't worked before. He seemed to know where we were and that we were using decoys. The search went on. Tuesday December 2nd we got a call from the manager of a cheap hotel in the Skid Row area. We drove out to see her. Right down this way he's not in. Well just what is it you want us to see? When you get a good look you'll know. Yes ma'am. Here we are. I'll get the door. You just come on in. Thank you. Yes ma'am. Over here. I was cleaning up this morning my girl's sick had to do it myself. And just cleaning up and I found them over here in the closet. Yep. Up on the shelf. Can you see them up there? Way back. Right I'm going to have to get a chair. Well I was just straightened up and I saw them and I thought to myself, I ought to call the police get them right out here. That's what I thought to myself. Yes ma'am. I always feel it's the duty of every citizen to cooperate with the police. Yes ma'am. Can we get your flashlight please? Huh? Flashlight. Oh yeah. Here you go. Well do you see them up there on the shelf? Yes ma'am. Frank. Yeah. There's something down there I can pick them up with. Well you'll find out anyway. You don't have to worry about fingerprints. I guess I shouldn't have done it. I found them. I picked them up but I put them right back right where I found them. Here you are. Okay. What you got? Two women's purses. Mm-hmm. Two. Look inside of them. All kinds of cards and things. No money but all kinds of other stuff. You just look. Who has this room? You mean registered? Yeah. Well he gave his name as Jerry Kilgallen. You asked me though. I think it's phony. You take the room alone did he? Oh absolutely. This is a hotel for men. Don't allow no women in. Is it possible that somebody else left these purses up there? Hardly. These rooms are cleaned every day. Clean thoroughly. I don't miss anything. Yes, sir. How about the identification in them, Joe? I don't recognize the names. We'll have to check them. Take a look at this though. No here. On the lining of the purse. This one. Oh yeah. I better get it to the lab, huh? Well what is it? Did you find something? We're not sure. Well what is it I called you? I got a right to know. What is it? It looks like blood stains. You are listening to Dragnet, the authentic story of your police force in action. Tobacco has been one of man's basic pleasures for over 400 years. And the Chesterfields you smoke today are the best cigarettes ever made. When I say that, I mean Chesterfield regular, I mean Chesterfield king size. Remember Chesterfield is the cigarette that is tested and approved by 30 years of scientific tobacco research. The cigarette that gives you proof of highest quality. Yes friends, the Chesterfields you smoke today are the best cigarettes ever made.  They satisfy millions. We got a complete description of Jerry Kilgallan and Frank called it into R&I. We found no record on him under that name. The purse was sent to Lieutenant Lee Jones at the crime lab and after running a precipitve test, he told us that the stains were human blood. The stakeout was placed on the hotel and that night Kilgallan was taken into custody. Under interrogation he admitted taking the purses from two women in a department store in downtown Los Angeles. He went on to explain that he'd just gotten into town and that he was broken hungry. He gave us the date and the times of the thefts and when we called the victims they were able to give us positive identifications. He told us that when he'd taken the second purse he'd cut his hand on the clasp and that the blood stains we found were his own. He was booked in at the main jail on the charge of suspicion of robbery. That night Frank and I took up our place in the dragnet operation. Nothing happened. The next night went by without activity. On Thursday night at approximately 845 a woman was slugged and robbed after she left the bus on 71st Street just off Vermont. All cars in the operation converged on the area and a block by block search was made. Additional officers were called in to aid in the hunt. Every alley, every street and every backyard was gone over thoroughly. 11.15 p.m. while the search continued Frank and I drove down to Georgia Street receiving hospital to talk to the latest victim. I was on my way home. I didn't think anything like this had happened. I was just walking home. Can you give us a description of the man? I don't know. It was dark. I was just walking home and it happened. Did you see the man at all? Yes. It was dark. Was he a tall man? I guess so. I guess he was tall. I talked to the other men. Isn't that enough? I talked to them. Well, we're trying to get all the information we can. I don't remember good. My head hurts. Isn't there something I can do to make my head stop hurting? Did you see the man's face? Did you get a look at it? Yes, I did. I saw his face. Can you describe it for us? Can you tell us what he looked like? I don't know. I don't feel good. This is pretty important, ma'am. He had a real white face. Real white. What about his eyes? Can you tell us what color they were? Blue. Why are you blue? How about his hair? It looked brown. I'm not sure. I think it was brown. Yeah, I had on. I couldn't tell good. Just a few more questions now. Can you tell what color his hat was? I don't know. My head hurts. Can't you do something? We'll send for the doctor again. He might be able to give you another set of it. Hurts? Something else, ma'am. Was the man clean-shaven? Huh? I said, did he have a mustache? No. No mustache. Do you wear glasses? No. Is there anything else you can tell us about his appearance? No. Nothing. He had a gun. I know that. He had a gun. That's what he hit me with. Gun. He hit me when I wasn't giving him the purse. First, he asked me for the money.  Then he hit me on the head. Hit me as hard as he could. All right, ma'am. Is there anything else you can tell us that might make it easier to identify him? No. Nothing. I told you everything. I know. Nothing else. All right. We're sorry to have bothered you. Thank you. We'll be talking with you again when you're feeling better. Yeah. You come back then. I'll tell you remember then. Thank you very much for your help. It's all right. You ask the doctor to come back, won't you? Yes, ma'am. Officer. Yes, ma'am? Something else might help a little bit. What's that, ma'am? Before he hit me, I remembered there was a fight. I didn't want him to take my purse. There was a fight. Yeah. I tried to stop him, and I scratched him. I scratched him hard. See, I broke a finger, no, when I did it. That'll help, won't it? Yes, ma'am. It should. Last thing I remember before he hit me, he was bleeding a lot. I started to scratch him, ma'am. Do you remember? On the hand? No. No, I... I crossed the face. Left side. We got to a phone and we had a broadcast put out, carrying the additional information on the man and the fact that he had been badly scratched. Officers in the immediate area of the attack started to check of all the drug stores that were open in the hope that the thief had stopped for medication. After getting the call out, Frank and I left the hospital and started back to search the area. 1146 p.m. You talked to the doctor about the victim? Yeah, she's in pretty bad shape. They're going to move her to general. Sebastian says he might have to operate. She's glad to get this guy. Yeah. Attention, all units. Attention, all units. You want to turn it up, Joe? All units on frequency 7, please stand by. All units in the vicinity of the 100 block on West 29th Street. Officer needs help. Special attention, 1K80 code 3. Lean on it. Right. 1K80 to control 1. Getting a call to the 100 block on West 29th Street. KMA-367. Took us two and a half minutes to get to the location. At the curb on the side of the street, we saw Park Police Unit standing next to it was a woman officer. We pulled up next to the unit and talked to her. She told us that our suspect had tried to attack her and on the arrival of the two officers had fled the scene. At that moment, officers Sluder and Murphy were in pursuit. While Frank got additional information from the police woman, I went back to the car and got on the radio. 1K80 to control 1. 1K80 to control 1. 1K80 to control 1. Go ahead. Suspect is now on foot being pursued by two plain clothes officers through backyards in the area of West 100 block between 29th Street and 30th Street. Dispatch units to block intersections of Broadway and 29th Street. Broadway and 30th. Broadway and 28th Street. Broadway and 27th. Intersections of Main and 28th. Main and 29th. Main and 30th Street. Main and 27th Street. Control 1 to 1K80. Roger. KMA 367. I got the story, you see that? Yeah, let's go. Police woman says they're headed west. We'll do the back of the house down there, all right? Let's go. Attention all units. Attention all units. 1K80. Police woman says the suspect got into a driveway. Now we'll light up there. All right, take it easy. All right. West 29th Street now being pursued by two plain clothes officers. Looks like we got a live one this time, huh? Well, let's hope we can keep them. In the backyard between 100 block, 29th Street and 100 block West 30th Street. 1K82. Block the intersection. Flashlights over there, Joe. Let's take a look. You see who it is? No. Ducked back behind the garage. Sluder, what do you got? He's back there. Murphy's with him. You guys all right? Yeah. All right, let's take a look. You want to call an ambulance, Frank? All right. How is he? You better stop, Frank. Yeah. Tell him to cancel that ambulance. He opened up first, Joe. Murphy and I gave him every chance. Well, that's more than he gave those women. The story you've just heard is true. The names were changed to protect the innocent. On December 8th, an inquest was held in the offices of the coroner in and for the county of Los Angeles. In a moment, the results of that inquest. Now, here is our star, Jack Webb. Thank you. Earlier, George Fenneman told you exactly why the Chesterfield you smoke today is the best cigarette ever made. And best for you. Now, the rest is up to you. Get a carton or two for yourself. Smoke them and you'll say as we do, it's Chesterfield's for me. At the inquest, the coroner's jury returned to verdict that the suspect, Kenneth Neil Stewart, died as a result of gunshot wounds inflicted by police officers in the line of duty. The death was listed as justifiable homicide. You have just heard Dragnet, a series of authentic cases from official files. Technical advice comes from the office of Chief of Police, W.H. Parker, Los Angeles Police Department. Technical Advisors, Captain Jack Donahoe, Sergeant Martin, and Chief of Police, Technical Advisors, Captain Jack Donahoe, Sergeant Marty Wynne, Sergeant Phan Spracer. Heard tonight were Ben Alexander, Vic Perrin, Bibi Janice, Herb Ellis. Script by John Robinson. Music by Walter Schumann. Hell, give me speaking. Watch an entirely different Dragnet case history each week on your local NBC television station. Please check your newspapers for the day and time. Chesterfield has brought you Dragnet transcribed from Los Angeles. Filter cigarette smokers. Here is headline news. Nationwide demand for L and M filters drops price. Now you save up to 4 cents a pack, 40 cents a carton. Now everyone can afford America's highest quality and best filter tip cigarette. Remember only L and M's have the miracle filter tip containing alpha cellulose. You get much more flavor, much less nicotine. By L and M filters, the distinctive monograms cigarette at the new low price. L and M filters. Here, crime and Peter Chambers following John Cameron Swayze on the NBC radio network.