database - rmoehn/theatralia GitHub Wiki

four different kind of elements

  • Is this tested somewhere? What is the rationale behind this? I want justifications! ;-)

SINGLE-USER features

lowlevel: materials are consisting mainly of a TEXT & a BINARY and can be of a TYPE (str) metadata being stored: KEYWORDS and a (work) STATUS, and copyright Status LICENCE, LINK that is core data, as a user-dependent sphere data REMARKS, STATUS metadata automatically collected: who modified last

remarks etc. user dependent

fronts: list, single (new, edit), browse

usecase D1.1: store away material (whether being in a library, an archive or online quickly store a book title, an image or a scan with some remarks and tag it with some keywords and a status mark)

usecase D1.2: quickly find some material stored away earlier: while writing a paper or preparing a seminar quickly look up some image, book title or scan that one has stored later, or by searching for a keyword find all materials collected to some theme

usecase D1.3: browse through a set of materials (like images)

usecase D1.4: rework/update infos

advanced D1.α: guess TYPE of materials by input (and define types internally ) ask for affirmation

advanced D1.β check if material already in database

advanced D1.ψ check external databases to complement information of material (if a book title get the from…)

advanced D1.ψ history…

midlevel: entities have NAMES (str) and are supposed to be given TYPES (str), most important are the relations defined between them (m:m) and their references to materials (m:m), additionally as with materials they have explicit metadata like KEYWORDS, REMARKS, a STATUS and PRIVILEGES and implicit metadata like OWNER, MODIFICATIONdate, ACCESScount, access history

usecase D2.1: add an entity

usecase D2.2: find an entity and edit/update/expand information

browse through entities

add a material

add a link to another entity

advanced D2α : a strength of the relation

adavnced D2β: implicit relations when a user

advanced : propose type on past experience

define links to external

D3.1

highlevel: topics are groups of entities and materials, maybe later organised, for now only sets, and are to projects

MULTIUSER

  • elements

  • elements connected by links, the links can be strong, weak , explicit or implicit

  • each element has a core and a sphere: the core stores the objects essentials, the sphere data reflects the individual use

  • each material can be: a. private – it has a single owner who is the only one who can see and edit it b. shared – it has a group of owners who are working with the same data c. public – everybody can view and edit it, it has no owner only editors (only the core)

  • therefore there are three realms: private data, shared data and public data

  • accordingly the links between elements can also be private, shared or public

  • there can be diverse links between the three: a shared topic that includes a public entity and links to it some private materials links private, shared and public too.

  • materials can be private, shared or public and they generally have no links

  • entities can be private, shared or public and their links to other entities or materials can be private private entity -> private link to all kinds of entities or items shared entity -> shared link to shared or public entities or items or private link to all kinds of entities or items public entity -> public link to public items or shared or private … ???

  • topics shared topic -> links to entities and materials are shared as well, entities and materials are shared if not public private topic -> links to entities and materials are private as well, entities and materials can be private, public or shared all the links to entities and items of a shared topic are shared as well

  • projects can be private or shared shared project -> links to topics shared as well, linked topics shared as well, no private link or linked topic possible private project -> links to topics private as well, linked topics can be private, public or shared

  • on adding a new element: (α) on entering data see whether there is a private or public element similar to it and offer a list of possibilities (α-1) if element from list is chosen continue with -> editing that element (α-2) if no element is chosen continue editing, assigning private state to start of with incomplete data

  • on committing an element: () check with the completeness of the data and according to the state propose turning it public

  • on editing an element () check again whether there is a similar public element

  • on sharing an element change the ownership to a group so the element is accessible (and editable) by a group of other users, who can view and edit the shared element and its links, (sharing an element the links and linked elements are also shared)

  • on unsharing an element () ask whether to turn it public? -> publish () if not create two identical private copies for each user that might be discarded

  • by publishing an item enters the common realm and becomes public property, everybody can view and edit it and its links, publishing an entity one has to choose between publishing only the entity itself and links to public elements as well as the private elements it is linked to …. recursively,

  • the unpublishing of an element is only possible as long as no one has edited or linked to the element

  • on deleting an element: if private -> delete if shared -> ask group to confirm (?) if public -> negatively mark in rating the deletion request

  • every element has a user-dependent and a global RATING the rating relates: (1) lifetime, (2) #of accesses (3) # of search results, (4) #of accessors and their status, (5) #of edits, (6) #of editors and their status, (7) #of likes, (8)#of confirmations and status, (9) #of corrections and status, (10), #of links to, (11) #of links from, (12) delete request

  • every link has a user-dependent and a global RATING usage of link