You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current tag system is too reliant on AniDB, and is not very user-customizable. This request is for an upgraded system to replace the current system.
The new system should be at minimum be:
decoupled from any outside sources by default - The system should not be reliant on any outside sources, but it should still be possible to use outside sources to map tags to series, if the users so chooses.
user-customizable - The user should have more freedom in how tags are added.
And optionally:
provide plugin definitions - An abstraction of the new tag, an tag provider for pulling in tags from outside sources, and (optionally) a tag manager for managing the tags at a high-level (i.e. without using the repositories directly, but using an abstraction on top to hide them).
To-do
Some pointers to what needs to be done.
Choose implementation to use (A, B, C, D, or something else entirety)
Add the basic models to Shoko.Models
Create new repositories to contain the models in the database in ShokoServer
Modify the existing Anime_HTTP command to only add tags if a preference is set, and follow the mapping from Tag_Reference to the local tags.
Decide if it should either
create new tags if no reference if found,
try to search for a similar tag by name/path (depending on the implementation used), or
skip the tag without mapping it.
Add new endpoints to manage tags
Basic endpoints to create, read, update, and delete tags (The exact endpoints needed depends on the chosen implementation)
Basic endpoints to create, read and delete references. (May or may not be needed)
Create database migration script/command/function to convert an existing database over to the new system, converting the records from AniDB_Tag and CustomTag to the new format in AnimeTag.
Deprecate the current AniDB-based tag system and custom tag system. (Should be done last)
Suggested implementations
Shared details
Shared across all the implementations will be the reference table holding all references to and from outside source, and the tag/anime relation table.
If a tag provider want to integrate with Shoko, it should add its mappings toAnimeTag_Reference on first initialization, and later map it's tags to series using the mappings stored in the table. The table should be user-customizable, so a user can override mappings that a provider has set.
publicclassAnimeTag_Reference{// Record identifierpublicintID{get;set;}// The tag identifierpublicintTagID{get;set;}// Then name of the providerpublicstringProviderName{get;set;}// Can be anything that can uniquely identify the tag at the source, using the correct provider pluginpublicstringReferenceID{get;set;}}publicclassAnimeSeries_AnimeTag{publicintID{get;set;}publicintTagID{get;set;}publicintAnimeID{get;set;}publicboolIsLocalSpoiler{get;set;}}
Example S1
Example containing four different references to the same local tag, using three different providers.
Example containing three different relations between a series and a tag, where the second relation also indicates that the tag will spoil the plot for the series, and is therefore marked as a local spoiler.
The tag system should implemented with simple tags, each with an unique id, an unique name, an optional description, a hidden flag, and a global spoiler flag.
The tag system should implemented with scoped tags, each with an unique id, an unique name, an optional description, a hidden flag, and a global spoiler flag.
A slight twist to implementation A, where tags can be scoped as a relative path.
The dystopia tag can mean anything in the series, be it the theme, the setting, or both. But the theme/dystopia tag will only have dystopia as a theme, and setting/dystopia tag will only have dystopia as the setting. All three can be independently used, either together or separately.
The tag system should implemented in a relation-tree like structure. Each tag should have an unique id, a non-unique parent id, a name, a full name, an optional description, a hidden flag, and a global spoiler flag. The parent id is stored directly on the object, and all new tags added without specifying a parent tag can added under a user-preferred tag (or no tag at all, which would add them under the root), e.g. creating a tag named uncategorized and setting it as the preferred tag would add all new tags without a parent set as direct descendants (children) of this tag.
The tag name is non-unique, but the fully scoped tag name is unique and dynamically created based on the name and the tag's ancestors' names. The scoped tag name is unique across all tags. So multiple tags with the same name is not allowed under the same parent.
If the theme is dystopia (theme/dystopia), then you known that the setting is not dystopia (setting/dystopia), unless both tags are set -- since they can be set independently.
Abstract
The current tag system is too reliant on AniDB, and is not very user-customizable. This request is for an upgraded system to replace the current system.
The new system should be at minimum be:
decoupled from any outside sources by default - The system should not be reliant on any outside sources, but it should still be possible to use outside sources to map tags to series, if the users so chooses.
user-customizable - The user should have more freedom in how tags are added.
And optionally:
To-do
Some pointers to what needs to be done.
Choose implementation to use (
A
,B
,C
,D
, or something else entirety)Add the basic models to
Shoko.Models
Create new repositories to contain the models in the database in
ShokoServer
Modify the existing Anime_HTTP command to only add tags if a preference is set, and follow the mapping from
Tag_Reference
to the local tags.Add new endpoints to manage tags
Basic endpoints to create, read, update, and delete tags (The exact endpoints needed depends on the chosen implementation)
Basic endpoints to create, read and delete references. (May or may not be needed)
Create database migration script/command/function to convert an existing database over to the new system, converting the records from
AniDB_Tag
andCustomTag
to the new format inAnimeTag
.Deprecate the current AniDB-based tag system and custom tag system. (Should be done last)
Suggested implementations
Shared details
Shared across all the implementations will be the reference table holding all references to and from outside source, and the tag/anime relation table.
If a tag provider want to integrate with Shoko, it should add its mappings to
AnimeTag_Reference
on first initialization, and later map it's tags to series using the mappings stored in the table. The table should be user-customizable, so a user can override mappings that a provider has set.Example S1
Example containing four different references to the same local tag, using three different providers.
Example S2
Example containing three different relations between a series and a tag, where the second relation also indicates that the tag will spoil the plot for the series, and is therefore marked as a local spoiler.
Implemention A - Non-relational (simple)
The tag system should implemented with simple tags, each with an unique id, an unique name, an optional description, a hidden flag, and a global spoiler flag.
Example A1
The dystopia tag can mean anything in the series, be it the theme, the setting, or both.
Implementation B - Non-relational (scoped)
The tag system should implemented with scoped tags, each with an unique id, an unique name, an optional description, a hidden flag, and a global spoiler flag.
A slight twist to implementation
A
, where tags can be scoped as a relative path.Example A1
The
dystopia
tag can mean anything in the series, be it the theme, the setting, or both. But thetheme/dystopia
tag will only have dystopia as a theme, andsetting/dystopia
tag will only have dystopia as the setting. All three can be independently used, either together or separately.Implementation C - Relation-tree (One-to-Many)
The tag system should implemented in a relation-tree like structure. Each tag should have an unique id, a non-unique parent id, a name, a full name, an optional description, a hidden flag, and a global spoiler flag. The parent id is stored directly on the object, and all new tags added without specifying a parent tag can added under a user-preferred tag (or no tag at all, which would add them under the root), e.g. creating a tag named
uncategorized
and setting it as the preferred tag would add all new tags without a parent set as direct descendants (children) of this tag.The tag name is non-unique, but the fully scoped tag name is unique and dynamically created based on the name and the tag's ancestors' names. The scoped tag name is unique across all tags. So multiple tags with the same name is not allowed under the same parent.
Example C1
If the theme is dystopia (
theme/dystopia
), then you known that the setting is not dystopia (setting/dystopia
), unless both tags are set -- since they can be set independently.Implementation D - Many-to-Many
Help needed!
Example D1
The tags:
The relations:
The text was updated successfully, but these errors were encountered: