Ecosyste.ms: Awesome
An open API service indexing awesome lists of open source software.
https://github.com/doriantaylor/owl-interaction-design
An Interaction Design Ontology
https://github.com/doriantaylor/owl-interaction-design
Last synced: 24 days ago
JSON representation
An Interaction Design Ontology
- Host: GitHub
- URL: https://github.com/doriantaylor/owl-interaction-design
- Owner: doriantaylor
- License: apache-2.0
- Created: 2022-04-26T19:29:28.000Z (over 2 years ago)
- Default Branch: main
- Last Pushed: 2024-03-10T17:37:20.000Z (10 months ago)
- Last Synced: 2024-03-10T18:42:59.668Z (10 months ago)
- Language: Makefile
- Size: 17.6 KB
- Stars: 0
- Watchers: 3
- Forks: 0
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
- License: LICENSE
Awesome Lists containing this project
README
# An Interaction Design Ontology
Author
Dorian
TaylorCreated
January 23, 2012Updated
December 18, 2013Namespace URI
Preferred Namespace Prefix
ixdThis vocabulary defines a number of concepts peculiar to interaction
design which are not accounted for by other vocabularies.![](https://vocab.methodandstructure.com/interaction-design-classes)
The purpose of the interaction design ontology is to codify a model for
the set of artifacts and relationships between them that are used to
take a project from a pile of stakeholder requirements and user research
to a distinct set of interactions and interfaces to be designed.The interaction design ontology unifies and extends the following
vocabularies:- A Process Model Ontology
- FOAF
- The
Bibliographic Ontology
- DCMI
TypesAs with the other vocabularies on this site, the canonical
representation is the machine-readable data embedded into this
specification. It is also, however, available in
RDF/XML and
N3 formats.## Classes
### Personas and Scenarios
The overarching purpose of the scenario and persona classes is to be
able to pick them out from larger pools of documents or representations
of agents. This way it's possible to mix real people and organizations
into scenarios with fake personas and still be able to tell them apart.#### Persona
A persona is a fictional agent for use in interaction design scenarios.
> ixd:Persona is a decorator class for instances of other foaf:Agent
> classes. Use this class in conjunction with something like foaf:Person
> or org:FormalOrganization to denote that it is fictional.Subclass of:
foaf:Agent#### Scenario
A scenario is a document that depicts the steps toward the achievement
of one or more user goals.Subclass of:
foaf:Document#### Vignette
A vignette is a short part of a scenario that isolates one single
interaction.Subclass of:
bibo:DocumentPart#### Branch
A branch represents a potential change in state in the scenario, such as
the user making a choice, or some exogenous event.### Interactions and Interfaces
The purpose of a scenario is to distill out the interactions, so we can
further distill those interactions into interfaces, from which we can
extrapolate technical entailments, and finally, construct the result.#### Interaction
An interaction is a particular kind of event wherein an agent uses an
interface to change the state of a system.Subclass of:
pm:Action#### Interface
An interface is some kind of artifact that mediates interactions.
> It is conceivable that ixd:Interface could be used to describe, in
> addition to software user interfaces: ABIs, APIs, file formats,
> protocols, natural languages, and physical interfaces that genuinely
> have to do with physics, like electrical plug/socket systems.Subclass of:
dctype:InteractiveResource## Properties
Ain't got none yet.
> Should we have ixd:material-context and ixd:incidental-context? A
> material context would be one that is necessary to complete an
> interaction, whereas an incidental context would be one that was
> chosen for the narrative continuity of the scenario. Furthermore,
> contexts like "at the office" or "using smartphone" could be reused in
> both material and incidental castings, even across different vignettes
> in the same scenario.