 Hi there everyone. I think it's about time we can start. So yeah, please come in and take a seat if you'd like to see this session Welcome everybody to information architecture for site builders. My name is Murray Woodman and I've been working with Drupal for about four years now I've spent a lot of my time as a site builder, but I also do my fair share of module development as well In a former lifetime I have been involved with the semantic web and and with technology such as RDF and topic maps and I've got a an interest in sort of data modeling and basically that the patterns around data. So what I want to do today is you know introduce you guys to a few concepts a few sort of diagrams and graphs and basically ways of thinking about the objects you have in your system and how you can then best represent that in the site building experience. So we're not really going to be going sort of deep into any particular module or code, but what we'll be doing is largely having a look at data structures and how we can sort of use those ideas to to build out our sites. If we have a look at the three circles of information architecture just to just to start off proceedings every site you build is deployed with a certain context in mind and that includes things such as the business goals and what you want to achieve with the site. You also have users in the mix and the things you want your users to be able to achieve the paths you want them to take throughout the site and the goals the actions you want them to take. And underpinning all of this we have content and that is how much content is there what is the nature of this content how much does it change and basically how you're going to manage and structure that and that's what I'm going to be talking about today. Basically how we can build out the structure of this content in the site building content context. So when you sit down to build out a Drupal site you know it is a creative process working out how you're going to be modeling your entities and fields and what not and in that sort of design process where you're working out how to structure your content you bring to the four these various patterns that I'm going to talk about today and then during the site building process of course that's when sort of the data model actually becomes apparent in the underlying structures of Drupal. So the four patterns I want to talk about today is firstly aspects and that is dividing out the horizontal and vertical components within your website. Secondly I'd like to talk about types and how you can have sort of multi-typed objects and how you can best represent that within your website and relationships is another big one. There's a couple of modules such as entity reference and the relation module. They've both got their pros and cons and we'll be looking at how you can build out data structures using those. And finally we have faceted classification and for me that's where the rubber hits the road where you have these sort of structures being reflected in search interfaces and things like that. So moving on to the first part of the talk aspects. Here we can see a lovely picture of some cake some vertical slices through with some horizontal structures in there. When you're solving problems one of the the concepts that is in computer science is basically decomposing a problem according to separation of concerns by focusing one's attention on a single aspect. So instead of having a massive problem and trying to solve that problem in one go you break it down into different parts come up with simple solutions and then have those solutions apply across other areas of the site. If we have a look at Drupal and the way it's structured we can see that there's you know a whole massive these horizontal cross-cutting aspects if you like to the system. So Drupal is sort of made up of a number of these layers that are independent but operate together. So this really isn't so much of a concern for site builders but it's a good thing to keep in mind and we can apply these principles when we're building out our site. So what's the secret of Drupal's success? Well I think we've probably all got our own ideas with this but for me I think a large secret part of the secret is that the core and contrived modules are largely concerned with these horizontal aspects. That is the solutions that contrived modules throw up often are there to apply across all the different content types that you have. So all of our favorite sort of parts of Drupal and these sort of contrived modules are all concerned with these horizontal aspects. However when we're acting as site builders we are solving specific problems for our clients. So we tend to just sit down and crack out the create some new content types and we solve those problems by building out our content types. However what I really want to emphasize is that we probably should be thinking about some of these horizontal aspects as well. So we should be trying to get reuse out of fields, out of taxonomy terms and vocabularies as well about thinking about presentation and metadata because all of these things are horizontal concerns. So if we have a look at the kind of process we go through when we're building out content types I've got a few examples here of page, article, place and event. We can immediately see that a lot of these horizontal concerns are actually sort of the dominating thing. For example thumbnails and descriptions, the image styles that we get reused with, the view modes that can operate across the site and vocabularies of course. All these things are horizontal. So I'm just suggesting sit down and think about these concerns before you crack out and getting stuck into your vertical aspects. The vertical aspects we can see here are things such as the author and the event location and date and things like that but these things really are the minority when it comes to building out your content types. So just coming down to a few little quick tips thinking about these horizontal concerns. Basically if you have fields that are semantically the same across your various content types just call them the same thing. Don't namespace them with the content type. That way you've got a common index and that's going to be very helpful for when you're using views, filtering on that, sorting on that as well as when you're sort of using search interfaces as well. So if we have a look at these fields I think Geoff Eaton calls this the concept of chunking information across your content types and this is basically a similar idea where you're getting reused. Another really interesting horizontal sort of pattern I've run into is with various view modes and how you can use those across the site. So if you say every single one of my content types must implement these say three or four view modes you are guaranteed of being able to render those things out consistently across your whole site. So when you're using views you don't have to break down and sort of start using fields. You can reliably use rendered entities and view modes to get that consistency. So once you do this it really frees you up to build interfaces that are going to be very consistent and it's going to be quite easy to add new content types in and not really have to worry so much about the presentation. If you're interested in this I thoroughly recommend checking out the SplaySuite module which allows you to customize your view modes. Metadata is a pretty obvious cross cutting one but I'd just like to draw attention to the open graph standard and schema.org. Schema.org is a consortium of Yahoo Bing and Google and they've sort of come up with a bunch of schemas on the web and both of these standards are sort of just focusing on name, description, image and URL to describe resources. So I'd recommend thoroughly making sure all of your content types have a description and an image so that it's working consistently across your content types. Now all these horizontal aspects that we've been talking about are reflected in the way you build out your features. Originally when I suppose the concept of features was mooted at least this is the way I thought of them they would be sort of little silos of functionality and configuration that you could drop into your website. But you know reality is a lot more complex than that and they've got to features when you use them have to sort of contend with all these horizontal concerns. So I think when you're trying to plan your website and these various structures you've got to sort of think about how they're going to be reflected in your features. So you know one of the basic patterns I use is to have a feature for each content type and then maybe your vocabularies which are cross cutting are then used as dependencies and then you're getting reuse across your image styles and view modes as well. Another interesting one is roles. Roles is a pretty sort of curly thing that's going to be different for every website you do but that is a cross cutting thing that works across your permissions and your text formats. So one of the patterns I've used there is to you know just have a little feature for your roles and then that becomes a dependency for these other components. What I've got here is not necessarily going to work for you but I'm just trying to get you guys thinking along the lines of how you can design these things out without sort of running into sort of dependency problems. So yeah take away for this section is you know let's plan for the horizontal. It's good for two reasons. It's great for you as site builders because you're going to be able to be building more simple systems that are going to be more flexible and ultimately they're going to be more expandable in the future because it's much easier to drop in vertical components once you've got all the horizontal stuff sorted. In terms of information architecture for users it's great for them as well. They're getting consistent interfaces and having to think about sort of the structure of your site in a consistent way and that's going to make things more predictable and understandable for them. Alright next stage it's a young Bob Dylan. Bob's a very talented man with many different facets and we'll be using him as an example for this next section. What is a type? It's a fairly simple definition. A type is just a category of things with common characteristics and in Drupal of course that means entities with fields. If we sort of have a look at how PHP sort of does things we can see that any one class which represents a type can only ever extend a single class. There are ways to get around that through things such as interfaces. The example I've got here is you can see a theme and a developer can implement or a class person can implement a theme or a developer. So it is possible to get more types in on that person class but you still have that basic idea of single inheritance. And Drupal is very similar. We can see that we can have multiple entity types and the one I've got here is a node. You can see that there are several bundles that any content type can support. Article page and event for example but an event can only ever support a single type so an event cannot be an article and a page. And this is a little bit limiting because we've only got these single faceted nodes. Out on the web things are a lot more complicated and in real life things are a lot more complicated. People perform many different roles in their lives, they have many different facets and so for example Bob Dylan, he's a singer, a songwriter and an author. Freebase is a site on the web that is a massive semantic database of pretty much everything in the world and the way that they get around this is by giving each of their content types a different facet or a different set of properties. So we can see say Bob Dylan in the freebase view of the world is not only a person, he's a songwriter, a composer, an artist and a book author. Over at schema.org and with the schemers they've built out, they've got a type hierarchy but each one of their classes in their system also support this multiple inheritance approach. So we have a hospital, it's not just a hospital, it is actually a civic structure, a local business, an organization, a place as well as being a thing. And it's this compositional approach to objects that we can move across and use this in Drupal. And there are three main ways I see of being able to do this. That's called reusing fields, using a field collection or perhaps linking in another object with an entity reference. Each of these three approaches I'm going to describe have a fairly similar UI which you can see there basically the edit form of the node or the content is adorned with these extra fields. So in the case of just reusing fields it's very simple, quite obvious. It's just a case of plugging those extra fields into the content type and just by adding these extra fields in you can sort of be just extending your objects out with these different types. So that is the most lightweight way and it's probably a thing that we all do naturally without thinking about it. A second approach would be to use a field collection and this is where you have an entity that is just a collection of fields and then you can plug that into the subject by embedding that field collection in. So if you haven't checked out the field collection it's a really handy way of building out objects with just a collection of fields. The other really cool thing about this is that because it's an entity you're also getting your view modes associated with that and it's possible to plug in different displays for this field collection so you're going to be getting reused across that if you're reusing that field collection. I don't really recommend this approach I think it's a little bit sort of heavy to be using another sort of throwing another entity into the mix. If we have a look at the third approach and that is with entity reference I think this is more of an interesting model because not only are we plugging in the extra fields through an entity but we're also getting the goodness of business logic and the view modes that can be associated with that entity. So like the classic example of this in Drupal is say with the commerce module where you have a product and then you have the display product node and that product is linked in with an entity reference field. So you're getting the fields and you're also getting all the business logic. So if you want to sort of have this multi-typed approach with logic the entity reference module is certainly a cool way to do it. The inline entity form is also a nice way to plug this stuff in into the UI when editing. So yeah, the takeaways here is that Drupal is a flexible system. It is possible to get over this single inheritance sort of limitation by mixing in these different types. Using shed fields is perhaps the easiest way and entity reference is the most powerful if you want to be building in some logic as well. Okay, third section. Kevin Bacon, can anyone guess why I've got him up here on the screen? Yes. Yeah, it's a six degrees. This is Kevin Bacon. I've got to get a bit of audience participation here. I don't want to see too many people going on to sleep. But yeah, this is a cool part of the talk. Kevin Bacon relationships. That game is about trying to link up different actors in Hollywood according to the movies that they've been in. And for information architects it's a really important thing to do is to relate content in interesting ways because it's basically the thing that's going to be providing the navigation paths your users take throughout your system and the better those paths the more chance they've got of discovering interesting information. The basic foundational concept I'm going to be talking about here is a triple and this kind of idea is found in RDF but it's analog in Drupal with fields hanging off entities. I want to talk about something a little bit more complex than that is the concept of entry relations and that's where you have a number of different entities sort of orchestrated together to come up with another entity that stands for something as a whole. The example I'm going to use is the one used by the relation module. If you go to the home page of the relation module you'll see I've got an example of a donation where company A donates to party B via Bank C a certain amount. So what we want to do is we want to somehow represent these relationships in the most succinct way. I mentioned at the start of the talk that sort of in the early 2000s I was involved with the topic maps community and that was a specification that sort of modeled a lot of these relationships and one of the first class objects in that system was a concept of an association and an association allowed you to sort of relate several different objects together and in this case we have the company, party and the bank and you can see each one of these relationships is an edge on the graph that's labelled. The cool thing about topic maps was that you could plug in any number of these sort of objects that were joined. If it wasn't just a binary relationship you could have entry relationships where you were relating a lot of things. In the RDF world we have a very similar sort of structure as well although this has been done by sort of building things up. So we come up with a concept of a resource which is the center point and then each one of these triples is then built out to represent this entry relation. So you can see that if you just go back to topic map and then go forward they're both pretty much the same kind of structure and if we come across the Drupal you can see we can model this in exactly the same way using entity reference. So we can come up with an entity such as a donation that could be a node or a bean or a field collection or any other entity you want to create and just by using entity references you're able to build up a structure that is very similar to the two we've seen. Looking at the way the relation module does it, the relation module is meant to sort of model this kind of thing as well and you can see the relation module introduces two sort of relation entities here so you can see this structure is a little bit more complicated and that's because it's basically joining only sort of two things at once. If we dig a little bit deeper into the database we can see that the relation module is using endpoints as the name of the field rather than sort of semantically named fields. So you can see this structure is just a little bit more complicated than the entity reference approach. And I suppose my main idea here is that I think entity reference is a better way to model these entry relationships. It's a simpler model, it's much more flexible and it reflects the resource centric approach that we have on the web. So for instance if you want to implement a link data strategy or you wanted to have a RESTful web service you're actually just talking about a single resource that can be used in those approaches. I really like the way entity reference tackles this stuff. Moving on to some other relationships that you can have. I'm just going to look at sort of reverse links here. So you've seen subject, object and predicate. Let's throw in the reverse link and talk about the link going back the other way. For example with Hillary and Chelsea we can see that Hillary has a child called Chelsea and Chelsea has a parent called Hillary. So the reverse link there is an inverse of link. And another sort of more specialized example of that is the friend of relationship where the reverse link is named the same thing as the forward relationship. And that's called a symmetric property. In Drupal it's actually quite a difficult thing to map that reverse link back. There's no sort of natural ways of doing a reverse link in Drupal. But there are ways to work around it. I'll just go back there. The relation model module handles this explicitly by having the forward and back links. But if you decide to go with the entity reference approach you can use another module called the corresponding entity references module which allows you to manage that back link. And you can just see there on the configuration screen you can see I've just basically mapped the forward link to a back link. And then once you do that this module will keep both of those links in sync. So to have a look at Bill and Monica if Bill is no longer friends with Monica then the corresponding entity references module will make sure that Monica is no longer friends with Bill. So you can see you kind of got a bit of replication of data there but this module will keep those two things in sync. And I actually quite like this approach because it once again reflects kind of the RDF sort of view of the world where you've just kind of got these small little pieces and you're coordinating them. Collections. This one's pretty trivial. I don't really have to talk about this but because it's probably a pattern that you're using very frequently you can use the entity reference module just with say unlimited numbers of nodes or whatever you want to link to build out various collections. So here both Earl and Lynette are both authors. So that's a pretty simple relationship to model. This is a really interesting one. I find this interesting. When I was looking at the relation module when it came out there's a lot of excitement about it and I really wanted to work out what was going on with it especially with this symmetric relation that it modeled. If you go to the homepage there you'll see there's the siblings relationship that you can model and in this example we've got Courtney, Kim, Chloe and Rob who are all siblings. And the thing with the relation module what it says is that this particular relationship joins things in all directions. So each one of these siblings is related to the other one. And this is quite an interesting thing because the way this structure is represented inside Drupal kind of looks a little bit like a collection to me. You've got these endpoints with various deltas but the arcs are really not related to the relation entity. All the relationships are going on with the things with the actual siblings. And this is quite a bit of a mind bending thing for me to get around because what the relation module is really modeling this it's not looking something like that as it appears in the database and that's because the relation module is basically managing its own layer of metadata to map these various endpoints. So, yeah, the relation module it does have a good use case here because this is just a shorthand notation for relating a whole collection of things together but I would say it's quite maybe an unusual thing to want to model but it's certainly an efficient way to do it. Okay, conclusions about relationships. You can see I'm a big fan of entity reference. I think it's simple, it's flexible and it follows the basic understood field semantics within side Drupal. It also follows a resource centric approach and that makes it very sort of web ready for restful web services and just basically when you want to deal with a single entity. The relation module has made some good steps in trying to be explicit about the nature of the relationships it wants to model but overall I think the simplicity of the entity reference module is probably a winner although with the shorthand for those symmetric relationships that could be a use case for you. Phew, okay. So that's the relationships dealt with and we're moving on to the final section now and that's to do with faceted classification and I've got this last because I think it's really where the rubber hits the road. A lot of the hard work you've done in building your data, I think it's reflected in how you can build out facets to search across your website. As information architects we're all no doubt familiar with hierarchy. It's quite a simple sort of concept to grasp that of a tree structure with broader and narrower categories and it works particularly well when you have type and subtype relationships whole and part containment relationships as well as class and instance where you may have a list of things that are instances of a particular class but hierarchy is not great for everything say for example with the jewellery decimal system we can see how difficult it is to slot a book into a single slot into that system it's also very difficult to come up with a classification system that's going to apply and make sense to everyone sort of using that system. On the web we've had Demos the open directory project in Yahoo they've both flourished and fallen away as sort of alternative navigation and searching methods of Arism. So we've seen the rise of tagging and focusonomy the rise of search and using labels instead of nested folders as well as faceted search and self-organizing interfaces. So what is faceted classification? Well it's basically where you divide up a set of content into various dimensions and that is using multiple characteristics that can be applied to every single member of that set of whatever you're looking at. So instead of using a single predetermined hierarchy we're actually using sort of properties that are intrinsic to those objects that you're looking at and this brings a lot of advantages. So I know this is a funny example but it's the way it worked out in the end. I'm searching for a blonde woman but I don't know her name. Now stop smiling John. If I didn't know the name of that person it would be a very difficult thing to search for because I don't know the magic string to enter into the search engine but using facets it's possible to narrow down the field to find the object you're looking for. So using this guess who name we can apply the facets to find out who the person is I'm looking for. So this is everyone. This is me filtering by the gender facets and so we're just selecting all the women here and this is me searching by the hair color facets for blonde women and lo and behold we've got Anita and this is the basic principle that can be used with facets so it can be used in conjunction with search or it can just be used on its own and it's very good for slicing and dicing up large data sets that are difficult to search. Using facets is cool because we can be a little bit more rigorous about the way we want to define our facets. Each of the terms should be mutually exclusive that is they shouldn't intersect at all and when you add up all of the terms they should be collectively exhaustive and cover the whole field and so once you've done that you're kind of doing a bit of a mathematical sort of intersection when you are dividing these sets up and you're going to have more efficient use of your facets if you organize things like this. A little design tip I've got would be not to be aware of big aggregates of things which sort of mix and match stuff that's not the same. So for example in this case do away with this hierarchy and break it out into these two different facets and you're going to be getting much better reuse from your faceted search. What kind of stuff makes good candidates for facets in Drupal? It's all of the horizontal things that we've been talking about so this is where your sort of information design at the start of the talk comes from fruition here. We've got types, categories and tags authors, languages and even sort of locations can be used to use for facets. You might have domain specific things such as t-shirt size or t-shirt color and they make very good things for this kind of thing as well. This is not a particularly new idea in Drupal. I mean you guys are probably all familiar with Solar but most of these recipes around faceted search revolve around the Solar search engine because it's very good at returning rows and large data sets where you're searching on different columns. Typical MySQL search is not so good on that because it can't sort of index across have multiple indexes on tables so that's why the Apache Solar search engine is great. The faceted API module in conjunction with the search API module or Apache Solar will basically combine to provide you the interfaces you're after. So just wrapping up here users turn to search more frequently and the faceted search that you can provide them is a way to bring all these horizontal concerns to the fore and to provide them with an interesting and effective search interface. So yeah, time to wrap up here. I've had a look at a few patterns here today. Aspects, types, relationships and facets and one of the main things I really wanted to get across was just this concept of the horizontal. Don't just focus on the vertical things. Building out this kind of stuff will lead to better interfaces for users. One of the main reasons behind the talk today was just to try to bring some sort of data modeling concepts into Drupal so that us as site builders can be able to build out these structures more effectively. If any of you guys have got any sort of other ideas or thoughts of how you would like to integrate other data structures and how we build out Drupal I'd love to hear about them in the questions section at the end because I think the more ideas we can get coming into Drupal for this kind of stuff the better. Just coming back to the start of the talk I've focused a lot today on the content but please don't just focus on that. It must be done within the context of what you want to achieve with the site and the things you want your users to do. If you bring all of those together hopefully your information architecture should be improved. That's it. Thank you very much everyone. I think I've actually got quite a bit of time. I seem to have cruised through that pretty quickly. If anyone's got any questions or suggestions or ideas I'd be really, I'd love to hear from you. Has anyone got a question? Oh yes, up the back there. So the question was what would I use to group content from a certain issue? Well I mean these kind of things come down to subtlety. We're talking about sort of like a grouping kind of concept. I mean natural grouping things in Drupal would be taxonomy terms or if you wanted to model an issue out in more detail you could have a content type or another entity that represented that issue and then you could then apply that and select that and so you could do the containment that way. So it'd be either taxonomy or an entity reference I'd say. Yes, yes, yeah, yeah. On the relation home page they address the strengths of the relation module versus the entity reference thing. That's one of them linking to other entity types as well as apparently entity references can't be versioned as well and that's one thing that they don't want to sort of add in. So there are some shortcomings there but that shortcoming you talk about is also something that is very similar with search as well and solar you can only sort of chuck in, you can only have an index into a certain entity type. Yeah, generally I'm quite a fan of nodes and I'm quite happy to build out stuff as content types for those reasons because you don't run into those problems or especially with the search but that's noted that is certainly a shortcoming there behind you. Yes, yes. Okay, so the question was why did I choose entity reference over field collections? I really like field collections mainly because they're very good to use when you have sort of lots of them and you want to represent a collection of things and you just want to quickly model them out so you could just have, you could come up with the person field collection and they just have a collection of people and you just, so that's very good when you have multiple things because it's like a little container where you can just sort of slot all those field collections in. However, when the use case I was talking about here was just for typing really so we were just going to be importing those fields in once so if you have a field collection and then you're just pulling those fields in it's just like, it's just a little bit heavier, you know you've got another entity in there and say when you're doing a views query you're going to have to go from your node to the field collection and then sort on the fields, right so you just got another join in the thing so I mean, it's just a small thing but if you don't want to do that then I'm probably just going the lighter weight way that would be a way to do it. Yes, that's, yeah, if you use anti-reference yes, yeah, that's very true that node is going to be, that will be heavier so I mean, the most lightweight way is just to do fields and then you don't have to have anything in so yeah, I mean, you just pick whichever one best suits what you want to do that's right, yeah. Okay, down the front here, Vladimir. You mentioned the future. Yes. What's your advice would be in terms of taking the greatest way possible? Yeah, yeah, so basically how do you model features? Do you use sort of big units or small units? I mean, we could probably talk for hours about this. You guys might know of Justin Randall he's been working on the configuration management initiative and his idea is that all of this stuff the whole site gets chucked into one massive big tree and stored as configuration and that's just done in one chunk. I'm probably much more of a smaller chunk person where each feature does have a little bit more reusability where it's sort of split out so that's why I've sort of designed these along sort of content type kind of lines and then sort of dealt with the cross cutting concerns when required. However, if you're building a site out for a client and you don't really need to have any reuse there's no reason why you can't chuck all of this stuff into the content type so that would include your permissions as well and maybe some other things you can just basically throw everything in because it is a unit of encapsulation but other systems I've seen you may have sort of layout features where you may be using context and other things to map these things in so you can have a whole section of layout features for example where they're cross cutting sort of concerns as well so it really depends on the kind of site you're building and if you want to get the reuse out of the features that you're building. Yep, sub there. How do you get buy-in from the client on how you're structuring this stuff? I personally think at the end of the day as an architect or whatever this is the expertise you're bringing to the field and you've got to make the best decisions of course they're going to have trade-offs along the way and sometimes there might be lineball cases where you don't know if something should be an entity or a content type or something else and I suppose then you might go back to the client and discuss can you see any future requirements around these things sometimes it's good to know what's coming down the road to see if you can make those design decisions up front you can make better decisions then but generally speaking I'd say it's the balls in your court when you're modelling the data Yes, I think that is helpful for clients too especially when you're speccing out depending on how you work with waterfall or agile but I think it is very handy for clients to be able to see those basic moving parts and they can be alerted to any sort of shortfalls in the fields or whatever you're discussing so I think that can be a helpful thing to walk through the client when you're mapping out what their requirements are Any other? Yes, well I mean if you're just chucking fields on hey we do it all the time let's say we've got a thumbnail field you put the thumbnail field on and you use it across the thing across all your content types that's pretty much what I'm talking about so you get the reuse that way but when you're implementing the presentational layer you're still going to have to say if you're using display suite you're still going to have to go in and configure that one up manually so you're getting reuse with the field but you've still got to re-implement that example but that's the most simple sort of lightweight common way and probably the most natural way of doing it in Drupal Believe it or not I was thinking about this on the bus on the way here this morning if you're just going to do it just having objects and entity references between them it would be a very hard thing to do because you would have to have each of those siblings going like that and then the next one would have to be related to everyone so there's a very laborious way of doing things but you could have you could come up with another entity type maybe called siblings and then you could basically have a collection so you could just have sibling field that's unlimited and then you could just chuck them all in there and you could even give it a title and call it the Kardashian clan or something like that so then that's an entity in itself but each of the to get things semantically correct each of those fields is a relationship between each member and the actual entity itself that's the correct way it's not an in-between thing I know we're splitting hairs here but each one of these guys is going to be a member of this the Kardashian clan entity so that's a bit more of a complicated way of doing it it's not so natural you've got to go away and build that structure and then maintain it it makes sense but if you're just having a lightweight trying to relate these things then maybe the relation module is the way to go but yeah go ahead I haven't done any performance things but there are less moving parts in the entity reference one certainly for that donation example I gave you you've got one less entity type there okay so in the relation module you would have in the relation module you'd have to have two relation entities if you wanted to add another thing another link to another thing maybe I don't know just say there was you know a lawyer consulted and you want to plug that lawyer into that relationship you're going to have to map another entity as far as I understand another relation entity in so it's not really a scalable solution because you're just making more and more as far as I understand more and more relation entities to get this more complex structure whereas the relate entity reference module it's just going to be you know just have one entity in the middle and these things hanging off so that's a simpler structure I think and it would be more efficient to navigate that graph with views and things like that but in terms of querying and displaying this stuff on the page I'm not really sure how that works but I think the entity reference module could get a few more smarts there could be some more contrary modules to handle this kind of stuff with a presentation of this stuff maybe a field formatted can work out oh look I know Kim in this list of things you just show the other siblings maybe there are certain ways of working around that but the entity reference module it doesn't have any smarts about what it's you have to augment that with other modules just up the back there it could well be you could decide to call your content type something slightly more generic and that's an optional field and if that works for you that's cool with content types which kind of have optional fields where you're split between making up two different content types is an objective criteria that I mean they're just decisions they're just decisions you make I'll just do a little throwback to say relational databases and how you represent these sort of different types there's three ways if I remember correctly the one way of having a super wide table with all of the properties from all the different types the second way is to have a separate table for every type and the third way is to have a basic super class table and then sub tables for all the sub types even in relational databases there's three ways to model this exact thing and in Drupal you're facing the same problems where you're basically deciding at the end of the day I think it's a practical thing and often times it comes down to what do the content editors expect do they want to go in and say I want to create a new event or a new whatever sometimes you can divide a site up like that to make it sort of logical for them a natural thing for them to do so yeah I mean it just depends I know that's not a very good answer but it just depends really we need to have inheritance between our entity types and can you sort of flesh that out a bit more yes that would be awesome and when I first heard of bundles I thought oh well this is cool we're going to get like these interface kind of things on entities and then I realized no it's not it's that single inheritance thing so yeah that's what I'm kind of driving at is how can we do that and you're saying you would like to have a bit more of a formalized structure for what these inheritance things could be but that's basically what this inline entity editing module does you know you can just plug it in here and so you know you're kind of building it out in the content type still but it's yeah it's just not an explicit concept in Drupal core yeah over there do I know any modules for graphing out these relationships for visualizing you can probably tell from my body language that I don't does anyone else know ways to visualize these things yeah I know what you're saying I'm not actually aware of it I've got to say in the relation module sorry the relation database model you're talking about or the relation module alright yeah I'm not entirely sure yeah no I don't know when I was doing this talk actually I had to work out a way to map out to map out these various relationships I came across this GraphFizz open source project where you can sort of just do a text file and then it will render out these render out these things so I don't know maybe you could write a little module just to go through the various sort of entity definitions and pump out a text file but yeah I don't know apart from that oh yes yeah yeah yeah sorry about that yeah I haven't checked that aspect of it out but yeah there must be little connectors to visualizing things and I don't think that would be hard to build something like that yeah it's just a matter of putting that together but yeah I don't know is the answer anyone else yes alright okay so in Drupal 6 there was node relationships module anyone else does anyone got any patterns or anything any sort of other ideas that we can throw into the mix I basically the web ontology language specification and how to look at the various properties in there and worked out how they could map into Drupal was anyone got any other cool things yes yep yes it is so our terms and taxonomy reference the same yes it pretty much is it's just that exact relationship and just in terms of the trade-offs between say content and taxonomy terms I think that for the main advantages the terms have this concept of a hierarchy built in so when you're building out your vocabulary you can add that nesting in and for me that's the main advantage of terms over sort of nodes I mean they're probably a bit more lightweight as well but that is the main feature that you get out of them so if you want to support that hierarchy yeah go with go with terms sorry you both get the both so well yeah we've got the two technocrat boys down here fighting it out come on yes I did yeah yeah that's that got a bit of a I don't know what's going on there sorry guys but yeah the commerce guys have a bit of a snafu the commerce guys I really have been thought leaders in this area with the entity reference and entities and the inline editing form that's down to them I think that's a great step forward and I think a lot of in the future we're going to get a lot of that and reappearing where you want logic and data sort of being able to plug into other objects well it's more of a hardcore thing I mean if you want to go away and write your own entity feel free and then you know it takes a bit of effort and know how the field collection module is you know much easier to get up and running with obviously because you're just building out the field so you know if field collection is going to do it for you but other people I've spoken to just hate the field collection module because I like the concept of you know fields and I'd much prefer to build out an entity with properties and have the database tables the way they want them you know so it just depends what how comfortable you are with on that spectrum yeah that's good so James mentioned trades and PHP I'm not up with those but yeah I'll have to research those James it's a good idea yeah nice nice yeah that could be an interesting model right so you're not just getting fields you're getting functionality going across your content types you know I suppose that's what the commerce guys solution with the entity reference in the entity because you are getting that functionality I suppose alright I mean the talk today guys I know it was maybe a little bit high level is but I hope you've sort of you know got a few little ideas out there so when you're sitting down in front of your computer and building out your content types you can just have a few of these ideas bubbling around in the back of your head and maybe apply them and hopefully you know as site builders you're just going to have an easier experience here putting your sites together is that I don't know how we are for time Alistair four minutes oh cool okay well three minutes more for questions anyone else I'm getting quite enjoying these questions anyone alright one more yep yes some people in the video yeah it's a quick question on how do you model things you put a lot of properties into to one content type and just run with that and the response was well it's probably best to split that out certainly for things like metadata and typing that up for use on the web is entity reference in Core and Drupalate I told you not to ask hard questions I don't know the answer to that does anyone else know about Drupalate anyone else okie dokie I think that wraps it up thank you very much I'm so happy you all came along