Logic of Papers and Users

[jamief]

Hi. I have been looking carefully into the database structure for papers.

One of the things I have noticed, and I don't understand the logic for, has to do with the way information about users, paper presenters is organised.
In a nutshell, the table paperpresenters has no direct relation to the USER table, although yes, it does to the paper table (which has a userID relating the two tables.

However, the paperpresenters table contains uniquely identified user name, last name, email, etc.
Why?
a) is this done? if the information in the user table is more complete, why isnt it drawing from that table system wide.

b) in The paper presentations view, the user link is lost. For example. I have papers that are connected to a user_ID 6, but the name on the paper doesn't take the name of that person from the user table, but rather, from the paperpresentation table. (This is not a bug, it was done populating the database with ficticious information.) It is possible, in other words, to have a different user name there.

c) If a user logs in, I assume he changes his profile material, it changes the user table. How does he change the paper presentation information if it isn't linked through the userID field? I.e. Who gets to edit/modify the paper information? And if you have Personal Data on the one hand, in the user table, and again personal data in the paperpresentation table, how does a user access this second level?

d) What is the logic in repeating data entry about a paper presenter if a user has created an account already and given some of these details that reside in users table?

I understand that not all users are paperpresenters, but aren't all paperpresenters users? or at least shouldn't they be?

[RickMath]

See my post on reports & stats. Maybe this is the same problem that I am experiencing as the papers do not line up with the right user/submitting author.

I think Matt is looking into this. Don't know if it the same problem but it may be. I'll have to check the MySQL tables in our database.

I think it may be a bug worth submitting. Keep in mind that the PKP team is hard at work on version 2.3 so feedback is useful.

Rick

[jamief]

See my post on reports & stats. Maybe this is the same problem that I am experiencing as the papers do not line up with the right user/submitting author.
I think it may be a bug worth submitting. Keep in mind that the PKP team is hard at work on version 2.3 so feedback is useful.

I have had a look at your post and the thread and it's not really the same issue. What I am talking about isn't a bug, it's more a question of the structure of the database at the planning level, something related to, but not necessarily the case here, called "normalisation" of the database. A "normalised" database tries NOT to reproduce (make redundant) information because a modification of one item (email for example) requires all instances to be modified. In the paperpresenters table we have and entry for the email of a paper presenter, but the person who initiated this paper also had to register to go through the process and this information was taken already through user table. Hence it's possible to have 2 different emails, and I don't see why it's necessary to duplicate Name, Surname, email, etc. in a single database.

I understand that its possible to have paper presenters who don't actually register into the system. For example, second authors, keynotes, etc. So my question is more about the user table, how it relates to the paperpresenter table. It seems to me it has a very fuzzy relationship because in the end, regardless of who did or didn't register, paperpresenters is linked through paperID to the papers table, and in there, we find the userID, suggesting all paper presenters ought to have a userID, ie., be registered.

This is what I am seeking clarification on at the moment. The LOGIC behind this a) separation of IDs and b) Duplication of personal data in the case of presenters.

(note: references to tables are in bold, references to fields are in italics

[mcrider]

Hi Jamie,

Basically, you answered your own question: The actual user who submitted the paper doesn't necessarily have to be a presenter, they may very well be an 'agent' that is submitting the paper on behalf of several authors. Further, a presenter might not want to be represented in the same way with every paper they submit (i.e. might want to change their affiliation with a different paper), which wouldn't be possible if it was grouped together in one user profile. Though I do see your point on normalizing this data, we have to take into consideration these requirements.

Cheers,
Matt