Concept Creation Guidelines
So, you want to create a new concept for use within IDESG? Great! Go to the bottom of this page...
If you are not familiar with this process, we recommend that you first read the guidelines below.
What to look out for?
When proposing to submit a proposal for a new concept to be defined and used within IDESG, it is worth considering a few questions which may help others understand what you are trying to define.
What sort of 'thing' is this proposed concept anyway?
A "concept" can be anything, tangible or abstract; real or imaginary. However, thinking of every possible concept only as a "thing", an object, can itself be limiting and counter-productive.
A few examples to show the difficulty:
- thinking of an "employee", we can think of a person (in the abstract or a particular person) - whereas it may be better to think of an "employee" as a "role" played by a person. This is relevant because roles and relationships change (and can be multiple - simultaneously of over time), whereas a 'thing' is always a thing!
- the concept "user" (hotly debated in IDESG!) - do we really mean a person? or could it also be an autonomous technology agent (like a program or system)? Or is "user" just, again, a role played by some person in an interaction with a system? It may all depend on context and all approaches may be valid.
- is "authentication" a "thing" or more accurately a process?
These sorts of distinctions are important, because the properties, characteristics and nature of different types of concepts are quite distinct and each helps in developing a fuller understanding of the concept.
How to decide? Is it important?
There is no hard-and-fast rule, however. Just to make things more fun, a concept can actually be of multiple types - it all depends on context. For example:
- If you are busy discussing and designing, say, the user interface for a new authentication system, it will slow down the conversation - and probably confuse people - if you insist all the time that "User" is not an Entity but only a Role played by a certain type of Person entity...For the purposes of that particular discussion, it may be 'safe' to talk about 'User' as an entity.
What is important is understanding the context in which key terms are used. When questions arise, it may be worth revisiting the group's understanding of the concept:
- "...but what if the user interacting with the authentication system is actually another system that presents itself as a person..."
- "...OK, until now, we've taken 'User' to explicitly mean only the role played by a human person in their interactions with a system - should we look for another term to cover the situation of a digital system? Such as "Agent" or "Actor"?
- "...indeed and the 'User' is really only a set of attributes of a human person, presented for the purposes of this authentication. It may be a different set of attributes presented to another system, no?
- "...so is that what we would call a 'Persona', rather than a 'User'?
(These are extracts from a real discussion - and show how several important distinctions and concepts arose from asingle question)
The "Conversation" is valuable
In some cases, the conversation about a concept or term may be as valuable - more valuable even - than any particular result. Disambiguation is the name of the game - ensuring that we have clear and mutually understandable discussions and future modeling efforts based on avoiding muddled taxonomy.
Using a Meta-Model (or two)
The concepts that we intend to develop and use within IDESG need to be robustly defined. They are not only going to be used to improve mutual understanding and facilitate internal and external discussions. They are also likely to be used in the development of more formal models for possible future identity ecosystems and tehir components.
As such, we recommend that you look at two 'meta models':
Create a new proposed Concept
To propose a new concept and term:
<inputbox> type=create editintro=Template:Concept/editintro preload=Template:Concept placeholder=Enter the proposed new term buttonlabel=Submit break=no </inputbox>