creating hierarchy for magazine archiving

Posted by lionel-drupal on January 19, 2013 at 10:30pm

I'm charged with digitizing some older periodicals and providing user content to them. Since a Drupal site is already in place for the archival institution, I need to work within its parameters. I'm trying to come up with a logical relationship structure to catalog and provide access to the content. Here's a scenario:

A periodical, let's called it History Monthly, is published with a volume and issue number (e.g., Vol. 6, No. 8). It has a publication date and certain other issue-level metadata that I need to account for. Contained within each issue is a dozen articles, with their own bits of information (e.g., author, contents, images, subject), etc.

Is there a way to create some sort of node or entity hierarchy so that articles are organized under an issue, and issues under a series. So...

At the top most level is the periodical name (History Monthly). Volume numbers would be children of the periodical level, issue numbers would be children of each volume, and articles would be children of each issue number, etc. An author list would exist independently of this hierarchy, though it would need to be entered at the article level.

I'm hoping to keep redundant data entry to a minimum, e.g., having to enter volume and issue numbers to each article rather than, say, being able to drag and drop issues under their parent volumes and articles under their parent issues. If drag-and-drop isn't a possibility, what sort of arrangement alternative is there to allow for inheritance and neat classification?

Is any of this even possible--or desirable? I'm not sure how to create this sort of hierarchical relationship with Drupal, nor necessarily what sort of content type, say, an issue becomes (can't just be a number since each issue would have associated metadata). I looked into the book module but it doesn't seem sufficient.

Thanks.

Comments

2 options come to

Posted by bander2 on January 20, 2013 at 12:08am

2 options come to mind:

Entity Reference allows your entities to reference each other. So, your article would reference the issue and the issue would reference the volume and the volume would reference the periodical. All of them would be content types.
Taxonomy is core functionality. You can set your terms to be in a hierarchy. Your article content type could be tagged to a specific issue which is the lowest branch in the hierarchy. Since taxonomy terms are fieldable in Drupal 7 you can add fields to them for all the publication date and other info you need to keep with the volumes and such.

I don't think you'll be able to get a nice drag and drop manager for the hierarchy though. Managing hierarchies in a graphical and intuitive way is one of the weaknesses I have found with Drupal. I am always envious when I see this kind of functionality in other CMSs. Hopefully someone will post something that proves me wrong.

follow up

Posted by lionel-drupal on January 20, 2013 at 1:12am

Thanks.

A few follow up questions: How does Entity Reference differ from the Relation and References modules? Would I be better suited to use one over the other, or in conjunction with one another? One of the problems that I'll eventually have to address is how to relate certain articles to others, like letters and follow-up responses, which are often found in separate issues. There seems like there's a web of interconnectivity between all the content. For now I'm hoping to build a solid, logical framework upon which these other relationships can eventually be handled.

I'm curious to know if there's a preferred way of organizing periodical content on Drupal. Perhaps my hierarchical plan is illogical or short-sighted. Right now I'm thinking in terms of modularity.

Entity Reference is the one

Posted by bander2 on January 20, 2013 at 3:50am

Entity Reference is the one I'm most familiar with. The reference is a field on an entity that references another. So any entity can can reference any other and the relationship is made on node edit form.

I have installed and tested the Relations module and I think it is really cool, but not right for any projects I have worked on. What is does is create a separate entity that creates the relation between other entities (as opposed to being a field on the entity). The plus side is that the relationship is an entity itself, so it can have it's own fields that contain information about the relationship. The downside is that the content managers have to go through a separate step of creating the relationship instead of being able to do it while creating or editing the entity like on Entity Reference. The project page has videos on how to use the module and they demonstrate the process of entity creation and it's not something I think would be easy for me to explain to a content manager.

I have never uses the References module. The top of the project page says it may be depricated in favor of the Entity Reference module. And it seems to do the same thing but is limited to nodes and users and not all entities like the Entity Reference module.