has broader
sub property of: broaderTransitive
definition: Relates a concept to a concept that is more general in meaning.
comment: Broader concepts are typically rendered as parents in a concept hierarchy (tree).

has related
sub property of: semanticRelation
definition: Relates a concept to a concept with which there is an associative semantic relationship.
comment: skos:related is disjoint with skos:broaderTransitive

SoServe-Thesau
type: Dataset
type: Concept
type: ConceptGroup
type: ConceptScheme

alternative label
sub property of: label
definition: An alternative lexical label for a resource.
comment: The range of skos:altLabel is the class of RDF plain literals.
comment: skos:prefLabel, skos:altLabel and skos:hiddenLabel are pairwise disjoint properties.

Concept
type: Class

preferred label
sub property of: label
definition: The preferred lexical label for a resource, in a given language.
comment: skos:prefLabel, skos:altLabel and skos:hiddenLabel are pairwise disjoint properties.
comment: The range of skos:prefLabel is the class of RDF plain literals.
comment: A resource has no more than one value of skos:prefLabel per language tag.

interactive work
type: Concept
preferred label: Interaktionsarbeit @de
related: User Story

Methoden Service Engineering
type: Concept
narrower: User Story

is in scheme
definition: Relates a resource (for example a concept) to a concept scheme in which it is included.

process
type: Concept
preferred label: Prozess @de
related: User Story

definition
sub property of: note
definition: A statement or formal explanation of the meaning of a concept.

Methoden
type: ConceptGroup
member: User Story

editorial note
sub property of: note
definition: A note for an editor, translator or maintainer of the vocabulary.

User Story
type: Concept
editorial note: Leffingwell, Dean (2011): Agile software requirements. Lean requirements practices for teams, programs, and the enterprise. Upper Saddle River, N.J.: Addison-Wesley (The Agile software development series). @de
definition: Die Formulierung von User Stories dient der Definition konkreter Anforderungen an ein System und ist somit ein wichtiger Schritt im Designprozess. Sie sind nach dem immer gleichen Schema formuliert: Wer möchte was und warum? oder: "Als [Rolle/Nutzer:in] möchte ich [Funktion/Wunsch], damit/um/weil [Nut-zen/Wert]." Im Kontext der Gestaltung von Interaktionsarbeit unterstützen User Stories den Perspektivwechsel und tragen dazu bei, Software (z.B. Kommunikationstechnologie) bedarfsgerecht für alle Nutzer:innen zu gestalten. @de
is in scheme: SoServe-Thesau
related: process
related: interactive work
broader: Methoden Service Engineering