graphs have been added now.
see also: http://www.anidb.net/forum/viewtopic.php?p=6436#6436
BYe!
EXP
Anime titles connections other than prequels,sequels[DONE]
Moderator: AniDB
-
analogued
One important connection that needs to be added, in my opinion, is REMAKE (same characters, same setting, same or nearly same story). Currently there is no connection of this kind.
An example is the Area 88 TV series and the Areaa 88 OVA, the former being a remake of the latter. Currently, Area 88 TV is marked as an alternative version of the Area 88 OVA.
"alternative version: Same setting, same characters, story is told differently" --> This is from the relations page and the expression is ambiguous. I now realize that by alternative version you mean remake, however the story is told differently part can be misleading and should be changed to something more clear.
Okay.. so let's assume that alternative version means remake. There is however another problem related to this: what happens if the two versions of the anime have the same name and they are both of the same type (OVA, TV, etc.)?
A solution is to add the year after the name like Animenfo. However you would have to add the year to the synonyms and short titles too as AniDB doesn't allow for two animes to have the same synonyms or short titles
Example:
Astro Boy (2003)
http://anidb.ath.cx/perl-bin/animedb.pl ... me&aid=807
Astro Boy (1963-1966)
http://anidb.ath.cx/perl-bin/animedb.pl ... e&aid=1440
I had to add the latter as Astro_Boy because AniDB would not let me otherwise. I couldn't even use AstroBoy as it was a synonym for Astro Boy (2003). Then, when I tried to add AD as a short title for Astro_Boy I couldn't as it was a short title for Astro Boy (2003). Well ... you get the picture. These are some important issues in my opinion that will have to be addressed sooner or later.
I don't know what the best solution is from a programming point of view but, at the very least, you should be able to enter the same synonym or short title for two different animes. Also, sorry about the long post.
An example is the Area 88 TV series and the Areaa 88 OVA, the former being a remake of the latter. Currently, Area 88 TV is marked as an alternative version of the Area 88 OVA.
"alternative version: Same setting, same characters, story is told differently" --> This is from the relations page and the expression is ambiguous. I now realize that by alternative version you mean remake, however the story is told differently part can be misleading and should be changed to something more clear.
Okay.. so let's assume that alternative version means remake. There is however another problem related to this: what happens if the two versions of the anime have the same name and they are both of the same type (OVA, TV, etc.)?
A solution is to add the year after the name like Animenfo. However you would have to add the year to the synonyms and short titles too as AniDB doesn't allow for two animes to have the same synonyms or short titles
Example:
Astro Boy (2003)
http://anidb.ath.cx/perl-bin/animedb.pl ... me&aid=807
Astro Boy (1963-1966)
http://anidb.ath.cx/perl-bin/animedb.pl ... e&aid=1440
I had to add the latter as Astro_Boy because AniDB would not let me otherwise. I couldn't even use AstroBoy as it was a synonym for Astro Boy (2003). Then, when I tried to add AD as a short title for Astro_Boy I couldn't as it was a short title for Astro Boy (2003). Well ... you get the picture. These are some important issues in my opinion that will have to be addressed sooner or later.
I don't know what the best solution is from a programming point of view but, at the very least, you should be able to enter the same synonym or short title for two different animes. Also, sorry about the long post.
Current 'adding relation'
( like this http://anidb.ath.cx/perl-bin/animedb.pl ... eq&aid=580 )
entry is little misleading.
Now is it in order: Anime, Title (of another anime), Relation type
Is the relation first title to second or second title to first?
I already make mistake trying this new tool and relation in result were reversed then i wanted to set. (I wanted to set 'Rahxephon Tagen Hensoukyoku' (aid =580) as summary to Rahxephon (aid=14)).
I think it should be little reorganized:
Anime
Relation type (with added before description of relation word 'is' before and 'of' or 'as' and the end - to avoid misleading which title is connected to which)
Title of related anime
And change names of relations to show proper direction:
sequel -> has sequel
prequel -> has prequel
side story -> has side story
parent stroy -> has parent story
summary -> has summary
full story -> summarizes story of
other -> other relation with
same setting, alternative setting, character - no change
( like this http://anidb.ath.cx/perl-bin/animedb.pl ... eq&aid=580 )
entry is little misleading.
Now is it in order: Anime, Title (of another anime), Relation type
Is the relation first title to second or second title to first?
I already make mistake trying this new tool and relation in result were reversed then i wanted to set. (I wanted to set 'Rahxephon Tagen Hensoukyoku' (aid =580) as summary to Rahxephon (aid=14)).
I think it should be little reorganized:
Anime
Relation type (with added before description of relation word 'is' before and 'of' or 'as' and the end - to avoid misleading which title is connected to which)
Title of related anime
And change names of relations to show proper direction:
sequel -> has sequel
prequel -> has prequel
side story -> has side story
parent stroy -> has parent story
summary -> has summary
full story -> summarizes story of
other -> other relation with
same setting, alternative setting, character - no change
Requests for Relations and Graphs
First of all, I would like to compliment EXP on his rapid implementation of relations and graphs, I think they are great features and really useful.
I think that there is some room for improvement though, and I am trying to put all of my comments in one place.
1) All relations should be directional. Same as Elias request, different wording.
Currently there are some relations (same setting, alternative setting, alternative version, character and other) that are the same in both directions. Let’s take character for an example, let’s say Anime A and Anime B have a character relation, you don’t know if B is made with characters from A or the opposite. Generally one Anime would be first, so this really should be a directional relation. That means that we would need different wording for the opposite directions. Here are my recommendations:
sequel: B is a sequel based on A. (B is based on A)
prequel: B is a prequel for A. (A is based on B)
Direct continuation of a story, may have different characters and/or setting, but the timeline continues. NOTE: only put in the immediate sequel/prequel, sequels of sequels are handled by AniDB automatically.
same setting: B is a same setting based on A. (B is based on A)
same setting source: B is a same setting source for A. (A is based on B)
Same universe/world/reality/timeline, completely different characters.
alternative setting: B is an alternative setting based on A. (B is based on A)
alternative setting Source: B is an alternative setting source for A. (A is based on B)
Same characters, different universe/world/reality/timeline.
alternative version: B is an alternative version based on A. (B is based on A)
alternative version source: B is an alternative version source for A. (A is based on B)
Same setting, same characters, story is told differently.
character: B has a character(s) based on A. (B is based on A)
character source: B has a character(s) source for A. (A is based on B)
Shares one or more characters, story is unrelated.
side story: B is a side story based on A. (B is based on A)
parent story: B is a parent story for A. (A is based on B)
Side story takes place during the timeline of the parent story.
summary: B is a summary based on A. (B is based on A)
full story: B is a full story for A. (A is based on B)
A summary summarizes the full story, but it may contain additional stuff.
Other: B is an other based on A. (B is based on A)
Other Source: B is an other source for A. (A is based on B)
Any other relation that does not match the list above.
If adopted, this wording (or something like it could be used on the add relations page, replace A with the Anime Name and B with <Title entered above>.
2) The Chained Add option should be removed.
Allowing for only one side of the relation I think will cause problems, and especially as defined above I cannot think of a scenario where only one side is true. The complement will always be there, no matter what; if B is based on A, then A is a source for B. Removing this will allow other optimizations and will make logic easier.
3) Always create the forward relation.
For existing relations hopefully it is easy to convert in the database. If the user goes to A and creates a relation saying B is a prequel, then rather than creating that relation, create it as if the user had gone to B and said A was a sequel. This makes it so there are half as many relations to worry about, also this would automatically clean up a number of routing issues with the graphs.
4) All relations should be presented in the “forward” direction in the graph.
If 2&3 are done, this is done automatically. If 3 is not done, then regardless of the direction the relation was created, it should be put in the dot file in the direction A->B if B is based on A. If #2 is not done and it is a one way relation going backwards, just have a tail arrow defined, the head arrow should be blank.
5) Cleanup tail arrows.
If #2 is done, then the arrows on the tail side in the graph can be removed, the reverse will always be true. If #4 is done, then leaving it as an arrow is fine. If #4 is not done, then the tail arrows should be changed to something like a dot to increase visibility.
6) Notifications on new relations added.
For anime I have completed, I have notifications set to new in case specials or other things are added. If a sequel (or other relation) is added, I don’t necessarily notice it. It would be nice if the notifications also handled adding new relations.
That’s all I can think of atm. Good enough for now.
First of all, I would like to compliment EXP on his rapid implementation of relations and graphs, I think they are great features and really useful.
I think that there is some room for improvement though, and I am trying to put all of my comments in one place.
1) All relations should be directional. Same as Elias request, different wording.
Currently there are some relations (same setting, alternative setting, alternative version, character and other) that are the same in both directions. Let’s take character for an example, let’s say Anime A and Anime B have a character relation, you don’t know if B is made with characters from A or the opposite. Generally one Anime would be first, so this really should be a directional relation. That means that we would need different wording for the opposite directions. Here are my recommendations:
sequel: B is a sequel based on A. (B is based on A)
prequel: B is a prequel for A. (A is based on B)
Direct continuation of a story, may have different characters and/or setting, but the timeline continues. NOTE: only put in the immediate sequel/prequel, sequels of sequels are handled by AniDB automatically.
same setting: B is a same setting based on A. (B is based on A)
same setting source: B is a same setting source for A. (A is based on B)
Same universe/world/reality/timeline, completely different characters.
alternative setting: B is an alternative setting based on A. (B is based on A)
alternative setting Source: B is an alternative setting source for A. (A is based on B)
Same characters, different universe/world/reality/timeline.
alternative version: B is an alternative version based on A. (B is based on A)
alternative version source: B is an alternative version source for A. (A is based on B)
Same setting, same characters, story is told differently.
character: B has a character(s) based on A. (B is based on A)
character source: B has a character(s) source for A. (A is based on B)
Shares one or more characters, story is unrelated.
side story: B is a side story based on A. (B is based on A)
parent story: B is a parent story for A. (A is based on B)
Side story takes place during the timeline of the parent story.
summary: B is a summary based on A. (B is based on A)
full story: B is a full story for A. (A is based on B)
A summary summarizes the full story, but it may contain additional stuff.
Other: B is an other based on A. (B is based on A)
Other Source: B is an other source for A. (A is based on B)
Any other relation that does not match the list above.
If adopted, this wording (or something like it could be used on the add relations page, replace A with the Anime Name and B with <Title entered above>.
2) The Chained Add option should be removed.
Allowing for only one side of the relation I think will cause problems, and especially as defined above I cannot think of a scenario where only one side is true. The complement will always be there, no matter what; if B is based on A, then A is a source for B. Removing this will allow other optimizations and will make logic easier.
3) Always create the forward relation.
For existing relations hopefully it is easy to convert in the database. If the user goes to A and creates a relation saying B is a prequel, then rather than creating that relation, create it as if the user had gone to B and said A was a sequel. This makes it so there are half as many relations to worry about, also this would automatically clean up a number of routing issues with the graphs.
4) All relations should be presented in the “forward” direction in the graph.
If 2&3 are done, this is done automatically. If 3 is not done, then regardless of the direction the relation was created, it should be put in the dot file in the direction A->B if B is based on A. If #2 is not done and it is a one way relation going backwards, just have a tail arrow defined, the head arrow should be blank.
5) Cleanup tail arrows.
If #2 is done, then the arrows on the tail side in the graph can be removed, the reverse will always be true. If #4 is done, then leaving it as an arrow is fine. If #4 is not done, then the tail arrows should be changed to something like a dot to increase visibility.
6) Notifications on new relations added.
For anime I have completed, I have notifications set to new in case specials or other things are added. If a sequel (or other relation) is added, I don’t necessarily notice it. It would be nice if the notifications also handled adding new relations.
That’s all I can think of atm. Good enough for now.
Skywalka wrote:Your ideas stink.
You have a weird way of making others reply
I don't see much use in 1 and 3, though...
(1) For old animes you'll often know the release-year. Additionally, newer animes most likely also have ascending anime-ids, so for a human reader, the information is implicitly available already.
I suppose you suggested using two directional relations instead of one bi-directional relation mainly to solve routing-problems - but I don't see those; (4) alone is a big enough change for the graphs' layout, so I'd prefer to start with that first, without such a big change as (1) first.
(3) This could be done dynamically when creating the .dot, without changing the db-entries. If this then proves useful, it'd of course make sense to convert the entries.
(5) Why? (Maybe giving an example of how this'd look may help)
I'd suggest to handle (6) seperately, since it can be done independantly from the other changes and it may need some more discussion how it should be done exactly.
I agree to what wahaha said, it is basically what I would have written.
at the moment I care about other stuff more than this (lame files, CRC32 values with only 5 digits because the leading 0 wasn't entered). While the graphs are a nice addition I think EXP should focus on more basic problems. The relation graph is fine the way it is at the moment, I really doubt there are too many people who want to see those changed (though it is hard to say since at the moment you have to get here to request changes to relations and I think few people do that).
at the moment I care about other stuff more than this (lame files, CRC32 values with only 5 digits because the leading 0 wasn't entered). While the graphs are a nice addition I think EXP should focus on more basic problems. The relation graph is fine the way it is at the moment, I really doubt there are too many people who want to see those changed (though it is hard to say since at the moment you have to get here to request changes to relations and I think few people do that).