Where did "instance" go?

[Rhys Lewis 2]

Of course, being a Kiwi, you'd mispronounce 'Strine.  But you're forgiven... 

There's a class differentiation.  A person who says 'Strun probably went to a better school than a person who says 'Stroine

[Paolo F Cantoni]

Of course, being a Kiwi, you'd mispronounce 'Strine.  But you're forgiven... 

There's a class differentiation.  A person who says 'Strun probably went to a better school than a person who says 'Stroine

[haughty tone]indeed! As one, as mentioned, for whom English is not one's first language, one attended the type of school that taught one how to pronounce Cholmondeley.[/haughty tone] 

Paolo

[Glassboy]

Of course, being a Kiwi, you'd mispronounce 'Strine.  But you're forgiven... 

Yeah it's hard when you make vowel sounds in your mouth, not your nose :-)

[Paolo F Cantoni]

Just reiterating that, for the present, I'm NOT interested in the elements in a repository (UML or ArchiMate things), but merely the language we use to converse.  I don't know where Modesto or Rhys are located (I suspect the UK), but they and I (as examples) have never met and need to be able to communicate unambiguously using only the written word.  Having (as per the Helsinki Principle) agreed on our terminology/ontology, we can then look at how we put these things in a repository.

Previously Modesto said:
"ArchiMate is a name only modelling language, the ArchiMate specification does not mention attributes and operations anywhere when describing the metamodel. As a result, no features are inherited when specialising in ArchiMate because there are no features to be inherited."

I agree with his statement (about ArchiMate) however, it seems to me that the concept of a "name only modelling language" is a non-sequitur!

One can't create falsifiable models when, as in Alice in Wonderland^[2], a "word can mean whatever I want it to mean".  There need to be more formal differentiation mechanisms than just the name, otherwise, I can say BMW X3 is a specialization of BMW X1!

So, let us accept that the things we are modelling can be characterised by their features.  Features are defined by their nature (Structural and Behavioural) and by the characteristic they describe.  Thus a structural feature for a motor car might be body type, for a bird a behavioural feature might be migration behaviour.

Some things are specializations of other things.  In modelling, we normally associate specialization with "inheritance" of features.  In order to be an inheritor, the specialized item must have a different feature set than the more general item.  Cetacean is a special form of Mammal.  Hierarchies of this type of inheritance are classification schemes.  Classification schemes have depth and the item can only be one classification in one scheme.  However, schemes can be orthogonal.

But colloquially, we also observe a different type of specialization, that of restriction.  A completed order is a special form of an order.  Non-modellers would certainly say they were talking about specialization.  Restrictions are Categorisations - shallow and overlapping.

Thoughts?

Paolo

^[2] Alice in Wonderland: "When I use a word," Humpty Dumpty said, in rather a scornful tone, "it means just what I choose it to mean—neither more nor less." "The question is," said Alice, "whether you can make words mean so many different things." "The question is," said Humpty Dumpty, "which is to be master—that's all."

[Rhys Lewis 2]

I don't know where Modesto or Rhys are located (I suspect the UK), but they and I (as examples) have never met and need to be able to communicate unambiguously using only the written word.

I have existed in the UK, but at the time of writing I could not be much further from the UK without being on a boat.  Which is perhaps an interesting example of the need to add a temporal dimension to the representations of modelling, because structural and behavioral dimensions would only be sufficient in a presentist view of reality.

So, let us accept that the things we are modelling can be characterised by their features.
...
Some things are specializations of other things.

This is a useful approach for considering the taxonomy of modelling, but reality is in the opposite direction, where certain things can be considered to exist, and our models abstract away details to either:
1. Create patterns that are sufficiently vague that they can be usefully applied to multiple realities, or
2. Chronicle our journey from optimistic planning free of the burdens of detail through to the robust compromises of delivery

Inheritance and specialization are relevant to that second situation where the journey from platonic ideal to reality may branch to multiple realities (eg. Site A vs. Site B, UAT vs. Prod, Phase 1 vs. Phase 2...)

[Glassboy]

I agree with his statement (about ArchiMate) however, it seems to me that the concept of a "name only modelling language" is a non-sequitur!

The introduction for the ArchiMate specifications says it is for

for the representation of Architecture Descriptions

.

I'd contend that they shouldn't have switched from calling it "a notation" to a language.  It lacks most of the features of a language.

[Modesto Vega]

I am not sure if stating that ArchiMate is "a name only language" is a "non-sequitur" because this thread shows that perhaps we do not fully understand the implications. This is because as @Glasboy has noted it lacks most of the features of a language and it is the absence of some of these features that erases the boundary between an "instance of" and "type of".

We all understand and agree what "type of", generalisation/specialisation, means. The issue that this thread highlights, in my opinion, is that the same does not apply to "instance of", at least not with the same clarity.

Strictly speaking an "instance" represents the occurrence of something more abstract and describes its distinguishing characteristics by attributing values to its features.

In ArchiMate, the problem with this definition is that the only feature is the "name", and this means that the only way of describing any distinguishing characteristics is by adding words to the name - e.g., Being > Human Being > Female Human Being or Male Human Being, Vehicle > Motor Vehicle > Car > BMW X1 with VIN 13456789, or Switch, POE Switch, POE Switch with Serial Number ABC-123456. This does not look very efficient or elegant to me.

Consider the following, if ArchiMate elements represent types of words and the relationships the grammar, then
1) the words are featureless (unless the specification defines their features), and
2) all features must be represented through the grammar

What does having featureless words mean? Consider a natural language with featureless words, unless the grammar supports it, a natural language without features lacks inflection. Inflection is the process of word formation whereupon words are modified to express different grammar categories such as tense, case, voice, person, number, gender and so on.

I know this is a bit more complex but it is a good starter.

P.S.: Because relationships are also featureless, a similar argument may apply is the elements represented nouns and relationships verbs.

P.S. (2): There is nothing wrong with a featureless (or nearly featureless) language but it has expressive limitations, and this has to be acknowledged.

P.S. (3): Somehow, this reminds of W.V. Quine concept of radical translation, whereupon a linguist encounters a community whose language is completely unrelated to any language familiar to the linguist and the linguist has to attempt to fully translate the unfamiliar language. We are linguists attempting to translate a technical language to plain English and discussing how different technical languages are to be translated into each other. I think the later is a good exercise. I always have some resistance to the former because technical languages are there to express something non-technical languages cannot express.

[Glassboy]

P.S. (3): Somehow, this reminds of W.V. Quine concept of radical translation, whereupon a linguist encounters a community whose language is completely unrelated to any language familiar to the linguist and the linguist has to attempt to fully translate the unfamiliar language. We are linguists attempting to translate a technical language to plain English and discussing how different technical languages are to be translated into each other. I think the later is a good exercise. I always have some resistance to the former because technical languages are there to express something non-technical languages cannot express.

I couldn't disagree with this point more. One of the goals of ArchiMate was to render technical descriptions in plain language (I'm unsure if this was meant to be English or Dutch).  The translation problem isn't because ArchiMate is an unknown or alien language, it's because it's the equivalent of operating with the understanding of vocabulary and grammar of a three year old.

[Paolo F Cantoni]

P.S. (3): Somehow, this reminds of W.V. Quine concept of radical translation, whereupon a linguist encounters a community whose language is completely unrelated to any language familiar to the linguist and the linguist has to attempt to fully translate the unfamiliar language. We are linguists attempting to translate a technical language to plain English and discussing how different technical languages are to be translated into each other. I think the later is a good exercise. I always have some resistance to the former because technical languages are there to express something non-technical languages cannot express.

I couldn't disagree with this point more. One of the goals of ArchiMate was to render technical descriptions in plain language (I'm unsure if this was meant to be English or Dutch).  The translation problem isn't because ArchiMate is an unknown or alien language, it's because it's the equivalent of operating with the understanding of vocabulary and grammar of a three-year-old.

I think Glassboy has "hit the nail on the head".  It's what prompted my post last week.  To say that business-level items don't have properties of features is a non-sense to me.  It's a simplistic (NOT simple, TOO simple) view.

Also, the notion that you have to separate the structural properties from the behaviour properties is suspect.   I have actor "X" and I have a business object "data about actor X" (if I haven't misunderstood) seems stupid to me.

Paolo

[Modesto Vega]

If what Glassboy and Paolo are saying is that having a featureless notation/language, such as ArchiMate, is an oversimplification, I could not agree more. I was also trying to communicate this point. For the absence of doubt, I think most of the things we need to model have and should have features.

Despite Glassboy’s disagreement, I still think that we are doing in this thread is a ‘radical translation’ exercise insofar AFIK the ArchiMate specification does not explain how to translate a featurefull instance into a featureless instance. For example, if we had an Organisation element with a couple of attributes as its features - e.g., name and year created, one could argue that both Sparx Systems and the OMG groups are instances of an Organisation with a year created of 1986 and 1989. However, this is trickier with a featureless notation/language as all I can have is 3 elements with the names Organisation, Sparx Systems and OMG and a arbitrary relationship to show that last 2 elements are an instance of the first element.

Please keep in mind that there is no instantiation relationship in ArchiMate or UML. If I remember correctly in Sparx this is handled by setting the classifier to the instantiated element.

[Glassboy]

Despite Glassboy’s disagreement, I still think that we are doing in this thread is a ‘radical translation’ exercise insofar AFIK the ArchiMate specification does not explain how to translate a featurefull instance into a featureless instance.

If you compare ArchiMate to FIBO, for example, you'll see the difference between what happens when there is a group that cares about the epistemological and ontological issues. :-)  If EA supported a tool like Git for MDGs I think what you might find is that a) there'd be community made ArchiMate profile, and b) there'd be UML based MDG that did "ArchiMate" properly.  I personally have a number of items from when I contributing to Nick Malik's Enterprise Business Motivation Model revisions that I'd like to incorporate into business views in a proper Enterprise focused architecture tool.