Schema Ideas for D6/CCK Implementation

Okay. I have created the three CCK Types above, but I am not convinced I am barking up the right tree. I attach a zip file with exports of the three types. I am aware that this is not much, but honestly, I do not really know what I am doing. For example, I do not like that I have to enter the different pieces (Authors, Books and Reviews) in that particular order, separately. I would like to be able to select an existing book (if it's there), but add a new book (and its authors) on the fly. I checked out Addnode to allow this, but it is not D6 compatible yet.

So, in the absence of input from the community, I will continue to muddle this along. If ANYONE has suggestions for me, by all means, give them to me!

David

Nice to see someone using the standard, yes.

Personally, though, I find the MARC formats to be a cumbersome dataset with enough detail to describe anything, if you can navigate the thousands of pages of documentation. Having built local databases using the MARC formats as a basis, I can vouch for their exhaustive nature. Having the level of detail that the MARC formats include will undoubtedly overwhelm the average Drupal book reviewer, nor do I see (looking at the MARC Drupal project) how the average user will obtain MARC records to populate their site. I will look at that project with more vigor shortly, though, because I *know* that it would be easier if I could just steal from them! I have contacted the project maintainer to see what's up.

Another approach altogether would be to figure out some way to extract appropriate metadata from remote sites, rather than store all that info in multiple places. Wouldn't it be cool just to have some way of pulling in the book/movie/web page info from some authoritative site on the fly and pump it into your own site without having to key it in? This would be like the stock portfolio widgets that retrieve price quotes based on the ticker symbol. Local sites would get out of the business of ensuring the accuracy of metadata that others are being paid to create and manage. This would simplify the module's data storage (although the complexity factor might be an issue). This was what I was thinking of WRT the dataset...

If we were to follow that, some big changes would be needed. But it would broaden the scope of the module!

I will take a look at the Review module as well.

Thanks for feedback.

David

Oh--

I meant to say that I took the approach in the Review content type that since the type is Review, the Body element of the node should contain the Review of the item. That flies in the face of one of the comments on the other thread. I'd like more info from that person about how the Body element and the Review element would be used differently, since I don't really understand the distinction being made. To me, if I am using a Review node type, the Body of the node will contain the review. I guess by extension, the Body element of the Author type should probably contain the name, making *that* type pretty darn basic!

As a point of information, I would also consider the Title element of a review to be different from the title of the item being reviewed. So if I am reviewing T is for Trespass, I could use that as the title if I wanted, or I could put a different title altogether, like "Grafton Does it Again". Tied into this is the thought that some sort of embedded Item Description segment that would be derived from the item node itself and put at the top (or bottom?) of the review. The item itself would thus be responsible for determining the content of this segment. This would further the goal of having a generic review module that could review anything.

David

Duplicate. Oops.

Update:

I have been examining the Z39.50 module as well as the MARC module to see what they have to offer or how they might be used here. I am not a big fan of keying in redundant data, and if there were some way to pull in data from an authoritative source (such as a library website), that would be ideal. It may, however, be unrealistic to expect that to work in the short term (especially when the Z39.50 module has no active supporters to migrate to D6).

Since I have clearly hit a block going down this route, I will back away from it and see whether I can move forward with a more basic approach (darn! there go my plans for world domination!).

In the basic way, I see having a Book Type, with the fields I listed above, and a Review Type that links to the Book Type. Because the reviewer will be inputting Book info at the same time as the review, the AddNode module (or one of the other modules that support this input mode) will be a required dependency.

There should only be the one input form. There will be the need for a full review view, a teaser view, and a one-line view.

Further suggestions are welcome.

Martijn--

If you look at the first post, you will see each of these data elements included there. We have also discussed the fact that a Review node would use the Body element to store the actual review itself.

But you raise a point about CCK that I do not understand. You speak of "CCK fields," and I have seen the many references and modules for CCK on the site here, but I admit that do not understand what is meant by the terminology. Can you explain to me what a "CCK field" is, and how it gets used or implemented? Maybe I would go down that route, if I understood why it would be better than simply having text fields to hold the data.

Thanks.
David

Okay. I think I understand a little better now when considered for a single field. But your Review CCK field seems to roll three data elements into one (one of these, the Item Reviewed element, would in all likelihood be a complex data element itself). That parallels modules like that Address CCK module, but from what I can see, this involves actual programming in the Drupal realm--an area that exceeds my expertise. If I find time to figure out how that might work, I could try, but my past experience in this has shown the Drupal programming fog to be too thick for my abilities.

To return to your list:

Synopsis: This would be a straightforward text field, and I don't see why a special CCK field type would be necessary.

ISBN might qualify for special treatment, but it is a complicated animal that can be 10 or 13 characters which can be split into substrings of variable length. The only validation I would feel comfortable providing would be to strip out characters other than digits and 'Xx' and verifying that the resulting length was either 10 or 13 characters. A quick perusal of the Phone Number module suggests this to be eminently hackable (taking right from that). Would/Could there be some feature for allowing an automatic Amazon or library lookup based on this? I don't know, but think it would be cool to be able to put in the ISBN and automatically have that display in the final review as a link to the site admin's chosen destination. That is something I have no idea about accomplishing, though.

Contents: personally, I think that including a contents field would be overkill. My primary focus is on a review, and not the contents of the book. I know that in some domains (technical, if I am not mistaken) it is more common to provide the table of contents in a review. But that would not be my primary focus here. I am certainly open to having something like this, but from my end, it's a complication that slows me down even more than I have been so far.

Review: Setting up a complex CCK field for Review, beyond a basic node type content type is (as I mentioned above) probably beyond my abilities. Again, from my perspective, I am defining a node Type Review, whose Body would therefore be the Review.

Price: Again, from my perspective, the price of an item is outside the requirements of a review, and can be obtained from other sources (like Amazon) better than from my fingers. That said, I note the existence of http://drupal.org/project/currency_cck and http://drupal.org/project/money which purport to provide the kind of features you want. Not being a CCK maven, I am not sure how one integrates these beasts with this one...

David

Splicer--

My point in starting this thread was to explore how to create a CCK book review implementation for Drupal 6, so we are in total agreement here. The big questions are: what information goes into this module, and what can be handled by others? There seems to be a consensus that a lot of what is in the current module is actually not necessary in a new generation BR module. I will probably opt for a less is more approach.

@AstaChattare: I wouldn't worry about being forced to use Amazon data, as anything like that would require some programming skills (on which I am remarkably deficient). I sincerely doubt that I will be able to get much beyond figuring out what information to capture, and where to put it in Drupal. All the auto-derive stuff for me is icing on a cake that I still haven't got a recipe for.

WRT indexing: that's way beyond me.

I have begun to take this up again, after having been diverted by installation profiles messes for quite some time. I hope to be able to get some kind of simple book review node type going on my machine, and when I do, I'll try to get that out here as well.

No promises though...

I will upload my first version to handle review information shortly for public consideration. I have taken the Addresses CCK module and unceremoniously hacked it into holding basic bibliographic information. Given my (lack of) higher programming skills, I fully expect this to be buggy and not very feature-rich, but my initial tests succeeded in creating a node type that used the bundled fields on input forms and subsequent display.

For this exercise, I set up the following fields in the bundle: Title, Edition, PubPlace, PubName, PubDate, Pagination, and ISBN. I purposely kept it simple at this point, and stuck to the most basic data elements used to describe books. These are all basic text fields, with no fancy lookups or other bells or whistles. I expect at another point to use the FullNames CCK module to handle authors. Since I *really* don't know what I am doing, I am rather happy that I got it this far.

Issues that I see still remaining:
* The form layout needs work
* What about theming?
* Philosophically, is this really a review, or is it a book description to which one can attach a review?
* How do old reviews get into this?
* Is this in fact a usable approach?

I look forward to feedback and further discussion!

David

Okay, here's a first pass. Give it a try!

David

I am uploading a different file; after some consideration, I came to the realization that what I had created here was more a bundled Bibliographic Description dataset rather than a Book Review, hence the renamed file and content.

Moving forward, I envision linking several CCK entities (this one, the FullName, and FiveStar for starters) together to create a review environment. Maybe then I could use a version of CCK Create Install to generate a loadable CCK-based book review...

Huh. I note that there seems to be an extra trailing underscore in the names, but the archive opens fine for me nonetheless. How are you going about trying to open them?

David

P.S. -- I'm glad someone's looking at this...

P.P.S. -- The basic contents of both files is essentially the same. You really only need the second one...

Well, I will try again. While I am at it, I will include my stab at an author cck field type. Also, here is my sense of where the original bookreview fields will go (for someone who understands how an upgrade would go):

Original bookreview table had: nid, booktitle, cover, publisher, copyright, isbn, price, pages, rating, synopsis, contents, review
Original bookreview_authors had: aid, nid, author, weight
Original bookreview_links had: lid, nid, booklink, description, weight

The bibinfo field type provides: Title, Edition, Place, Publisher, Date, Pagination, ISBN
The bibauth includes: LastName, FirstName, Dates, bio
CCK or some other submodule will provide linkage between authors and books
The Fivestar and Voting modules provide the rating
The Link module provides: URL, Description

FIELDS I HAVE NOT MAPPED:
cover, price, synopsis, contents

The Migration strategy will have to map fields as follows:
bookreview::nid --> content_type_bibinfo::nid
bookreview::booktitle --> content_type_bibinfo::bktitle
bookreview::publisher --> content_type_bibinfo::bkpub
bookreview::copyright --> content_type_bibinfo::bkdate
bookreview::isbn --> content_type_bibinfo::isbn
bookreview::pages --> content_type_bibinfo::bkpages
bookreview::review --> node_revisions::body

I'm fuzzy about the author info; the old review didn't separate names; perhaps the new additions are overkill...

Well, here is a basic zip file version with both modules in it.

Great!

Some notes: the two modules give you two CCK data types: bibauth and bibinfo, which roll together the various fields. You need to take these two types and create a parent node type (like, say NaomiReview), that aggregates the types into a review. That's where the FiveStar, Link, and NodeReferrer modules come in. Putting these together will give you most of the original BookReview fields (as I noted) as a single node type. That's been my first goal.

It will then be necessary to build views for the node type. Since I am not really all that versed in CCK & views, I haven't done much on that front.

So you see, my work is really just the start of this. I hope a jolt from someone else will get this moving along.

Thanks!
David

Naomi--

Thanks for trying it out. The layout that you see was as far as I got; fixing it is part of the to do list. I suspect that fiddling around with views is the way to remedy the layout, but I do not know for sure.

I don't see the author info on the screenshot you provided; had you not gone down that route yet?

FWIW, I have also been fiddling around with a PHP class that will use the ISBN to retrieve book information from library servers using Z39.50, in the hopes that someone else will be able to use the class with AJAX to autopopulate a book review form with data taken from the library server of your choice. I've gotten the class to successfully retrieve data from a Library of Congress server and parse it into a local array to match with the bibinfo and bibauth CCK fields. Since I know nearly nothing about AJAX, I hope that someone else will be able to take the data and use it.

Cheers,
David

@Naomi-- I looked at your site, but didn't have time to actually get to see the troubles with the author part of this.

Interesting idea to separate this into a new project, although it's never been my intention to start or maintain a Drupal project. Before this were done, however, I think it would be important to address the basic formatting troubles that have been observed with the code as it stands. As I've said numerous times, I am essentially a monkey beating at the keyboard when it comes to understanding the Drupal Way. If someone could tell me how I would make the input form nicer to look at (themes? css? in the module code? waving my sprinkle dust wand at the screen?), I would try to do that. Perhaps then this could be put out on its own.

I'm reticent, though, because I really would like to see a Book Review package to be easily available. Splitting it up into constituent elements is good for programming, but bad for end users, and if separating this part out takes energy away from getting a D6 Book Review package, I think that's bad. Even if we have all the pieces (with a Book entity, an Author entity, FiveStar, etc.), someone has to get them all playing together nicely.

David

P.S. FWIW, I wrote a php object that extracts bibliographic information from a remote library Z39.50 server and returns it as an associative array and have been trying to merge that into the CreateFromWeb module to populate the bibinfo CCK entity, but I've run into some technical glitches. When it finally does work, it will be possible to put in an ISBN, and auto-populate the rest of the information from that library source.

schildi--

The Z39.50 project is unmaintained, and will not be updated to Drupal 6 unless someone else takes it on. I put my code out under the CreateFromWeb issue lists (see http://drupal.org/node/404274).

My hope is that someone else (perhaps you?) can decipher the CreateFromWeb code and figure out how to make my code work with that; I could NOT get the returned data to go into the form.

Alas, it is increasingly looking like no one is willing to help me put this together into a viable module for D6. The big issues remain 1) the design of the layout, and 2) addressing migration issues for moving from earlier versions to this one. I unfortunately have neither the skill nor the time to push this further.