User:Dvdkhl/Ideas: Difference between revisions
(→Ideas) |
|||
Line 5: | Line 5: | ||
== Character Relations Graph (2. Approach) == | == Character Relations Graph (2. Approach) == | ||
'''Note''': This model may not be | '''Note''': This model may not be project-able to the current model in use. | ||
The idea presented here tries to represent character relations completely text based without the help of any images which contain graphs. | The idea presented here tries to represent character relations completely text based without the help of any images which contain graphs. | ||
Instead of trying to generate a simple view over the complete dataset, this approach will use many simple views. | Instead of trying to generate a simple view over the complete dataset, this approach will use many simple views. | ||
Line 19: | Line 20: | ||
* If graph simple enough, fallback to different simpler view? | * If graph simple enough, fallback to different simpler view? | ||
=== Global View === | ==== Global View ==== | ||
* Layered: Each relation type is displayed in one (separate) layer | * Layered: Each relation type is displayed in one (separate) layer | ||
* Each layer has a (can) have a more specialized model/view | * Each layer has a (can) have a more specialized model/view | ||
* Prefer small graphs, i.e. A family view should only contain its immediate Members (Parents, Children, etc.) | |||
** Some entities have to shown more than once | |||
=== Local View === | ==== Local View ==== | ||
* Convert each relation model to a single graph | * Convert each relation model to a single graph | ||
* A cursor which moves upon that graph | * A cursor which moves upon that graph | ||
Line 29: | Line 32: | ||
* Switching cursor position replaces the selected items and with the new cursor entity | * Switching cursor position replaces the selected items and with the new cursor entity | ||
=== Models === | |||
* Each relation type has exactly one model | |||
* The model is used to describe the relationtype as concise as possible | |||
* Model also has to define how its data is (de)serialized | |||
** Relational Database as storage (Anime_EntityEntityRelation.RelationId as Primary Key) | |||
* Avoid complex structures | |||
** No reference to other models allowed | |||
=== Prerequisites === | |||
(Assumed) Global DB Tables: | |||
* Anime(<u>Id</u>, ...) | |||
* Entity(<u>Id</u>, EntityType, GuiseId, Name, ...) | |||
** ⊇ Character(<u>Id</u>, Gender, DateOfBirth, DateOfDeath, Age, ...) | |||
** ⊇ Organisation(<u>Id</u>, ...) | |||
** ⊇ Vessel(<u>Id</u>, ...) | |||
** ⊇ Mecha(<u>Id</u>, ...) | |||
* EntityGuise(<u>EgoId</u>, <u>GuiseOfId</u>) | |||
* Anime_EntityEntityRelation(<u>AId</u>, <u>RelationType</u>, RelationId) | |||
** Anime_EntityEntityRelation.RelationId as Primary Key for Relation Models | |||
** Each model has its own tables | |||
** The usage is defined by each model/view pair | |||
== Character Relations Graph (Abandoned) == | == Character Relations Graph (Abandoned) == |
Revision as of 12:53, 28 February 2013
Just a place to write down my ideas for AniDB before they reach oblivion.
Ideas
Character Relations Graph (2. Approach)
Note: This model may not be project-able to the current model in use.
The idea presented here tries to represent character relations completely text based without the help of any images which contain graphs. Instead of trying to generate a simple view over the complete dataset, this approach will use many simple views. The basic idea is to take each type of relation (family, enemy of, ally of, etc.) and create one view for each for a global overall view. In addition a local view is provided to show relations in detail. The local view is simply a cursor which points to an entity for which information of itself will be shown and in addition to that the nearest neighbours. When the user clicks on one of the neighbours the cursor will move to that entity. For this to be user friendly mouse scrolling needs to minimized.
Views
- Contains a list of selected entities
- Each view has to highlight a selected entity
- If graph simple enough, fallback to different simpler view?
Global View
- Layered: Each relation type is displayed in one (separate) layer
- Each layer has a (can) have a more specialized model/view
- Prefer small graphs, i.e. A family view should only contain its immediate Members (Parents, Children, etc.)
- Some entities have to shown more than once
Local View
- Convert each relation model to a single graph
- A cursor which moves upon that graph
- Take the first selected entity for the cursor
- Switching cursor position replaces the selected items and with the new cursor entity
Models
- Each relation type has exactly one model
- The model is used to describe the relationtype as concise as possible
- Model also has to define how its data is (de)serialized
- Relational Database as storage (Anime_EntityEntityRelation.RelationId as Primary Key)
- Avoid complex structures
- No reference to other models allowed
Prerequisites
(Assumed) Global DB Tables:
- Anime(Id, ...)
- Entity(Id, EntityType, GuiseId, Name, ...)
- ⊇ Character(Id, Gender, DateOfBirth, DateOfDeath, Age, ...)
- ⊇ Organisation(Id, ...)
- ⊇ Vessel(Id, ...)
- ⊇ Mecha(Id, ...)
- EntityGuise(EgoId, GuiseOfId)
- Anime_EntityEntityRelation(AId, RelationType, RelationId)
- Anime_EntityEntityRelation.RelationId as Primary Key for Relation Models
- Each model has its own tables
- The usage is defined by each model/view pair
Character Relations Graph (Abandoned)
Note: This model may not be projectable to the current model in use The idea presented here tries to represent character relations completely text based without the help of any images which contain graphs. Instead of trying to generate a simple view over the complete dataset, this approach will use many simple views. The basic idea is to take each type of relation (family, enemy of, ally of, etc.) and create one view for each for a global overall view. In addition a local view is provided to show relations in detail. The local view is simply a cursor which points to an entity for which information of itself will be shown and in addition to that the nearest neighbours. When the user clicks on one of the neighbours the cursor will move to that entity. For this to be user friendly mouse scrolling needs to minimized.
Prerequisites
Needs to be reworked: One model/view for all either too simple to represent all cases or too complex to display => One model/view for each relation type
class Anime_CharacterCharacter_Relations { int AId; Anime_CharacterCharacter_Relation[] Relations; } class Anime_CharacterCharacter_Relation { Anime_CharacterCharacter_Relation_Type Type; ConnectedGraph[] Graphs; } class Anime_CharacterCharacter_Relation_Type { Label Name; EdgeInfoControl[] AllowedEdges; } class ConnectedGraph { Label Name; //For something like clubs/organisations/etc. Entity[] Entities; //Graph Structure Info Tuple<EdgeInfoControl, Relation>[] Relations; //Graph Structure Info } class Relation { //Edge EdgeInfo Info; //Informational purposes only! Entity A, B; //A is Start and B is end Vertex if graph is directed } class EdgeInfo { Label Start, Middle, End; } class EdgeInfoControl : EdgeInfo { bool IsWeakLink, IsDirected; } class Entity {//Vertex //Informational Data } class Label { string Text; Bitmap Image; }
Text needs to be updated to sync with the classes above
- Anime_CharacterCharacter_Relations holds all information necessary for Character-Character of an Anime.
- Each Character-Character Relation Type (family of, enemy of, etc.) is represented by Anime_CharacterCharacter_Relation, where Anime_CharacterCharacter_Relation_Type sets restrictions.
- Anime_CharacterCharacter_Relation_Type contains the info whether the graphs are directed or undirected, a label (e.g. Family) and specifies the allowed edges for the graphs.
- Anime_CharacterCharacter_Relation contains in addition to the type, a list of graphs (ConnectedGraph) which are required to be connected (i.e. every vertex is reachable from every vertex).
If a Character-Character Relation cannot represented by a single Connected Graph it is split into several ConnectedGraphs until the condition is satisfied. - ConnectedGraph contains the graph structure (vertices, edges) and a label which serves as a header for the graph (i.e. Organisation).
The Relations field contains all edges in addition to its type which must be contained in the associated Anime_CharacterCharacter_Relation_Type.AllowedEdges - Relation simply defines an edge in the graph which can contain additional information which only serves informational purposes.
Add abstraction, i.e. allow subclasses for each Relationtype to allow special behaviours for views.
Presets
Family Relation Preset
- Definition
- Label: (Family, FamilyIcon)
- IsDirected: Yes
- Edges (IsWeakLink, IsDirected, StartLabel, MiddleLabel, EndLabel)
- Undefined: (Yes, No, false, "", "", "")
- Parents: (Husband, Wife) //Samesex Parents?
View
Aim: Each connected graph shows to each other unrelated families Possibility1: Special Relation, Container with Parents as Header and Children as Content => Recursive display Possibility2: Simple edges describing Parent-Child Relations => May result in a lot of edges Adoption:
Mentor Relation Preset
e.g. Marimite
Posession Relation Preset
e.g. Pokemon
Views
- Contains a list of selected entities
- Each view has to highlight a selected entity
- If graph simple enough, fallback to different simpler view?
Global View
- Layered: Each relation type is displayed in one (separate) layer
- Each layer has a (can) have a more specialized model/view
Local View
- Convert each relation model to a single graph
- A cursor which moves upon that graph
- Take the first selected entity for the cursor
- Switching cursor position replaces the selected items and with the new cursor entity
Character Relations based on episode range
User - Object Set - Analysis (Snippets of Wisdom)
AniDB Event: Anime of the Month Clean-up
New API: Based on TCP and EBML
AVDump2: Module for adding file entries (streamlining the adding process)
Tool for adding any kind of data to AniDB
MangaDB File/Chapter/Volume Hashing
-Image Hashing: http://www.phash.org/docs/pubs/thesis_zauner.pdf