AAS is a series - reflect in aas folder structure about id

[sebbader]

Hello Birgit,
I just made a proposal in a new branch. Can you have a look and give me feedback?

[BirgitBoss]

Small comment wrt Readme.md in this new branch.: Revision 2.0.1 from 2019 [3] should be Revision 2.0.1 from May 2020 [3]

[BirgitBoss]

When I am reflecting on this again it might be better to not have folder for the different parts: in the moment we merged part 2 and part 3 and it can be expected that part 1 might be splitted in the future. So perhaps instead we should make more generic folders like "informationModel" "Interfaces" etc. without version: the versions should only be contained in the ids themselves.
E.g. vdi/2770/1/0/Document means Element Document in VDI 2770 Version 1.0 whereas vdi/2770/Document/1/0 means Element Document V1.0 in VDI 2770
What do you think?

Could there be more than one id for the same element? How do we document obsolete elements and thus obsolete ids?

[sebbader]

Trying to catch up on this topic.

E.g. vdi/2770/1/0/Document means Element Document in VDI 2770 Version 1.0 whereas vdi/2770/Document/1/0 means Element Document V1.0 in VDI 2770

That's a very valid point, the first version/revision paths (should) link to the versioning of the source document. I am trying to sort my thoughts a bit:

Pattern 1: vdi/2770/1/0/Document

• Versioning of the entities is bound to the versioning of the source standard.
• No revisions possible if the source version has not been changed.
• Bugfixes are independent, I would accept them at all times without having bugfix versions explicitly in the URIs

Pattern 2: vdi/2770/Document/1/0

• Problem with different versions of the source: In case version 2.0 of VDI2770 drops the Document element, the path vdi/2770/Document still stays.
• changes to the vdi/2770/Document element in this repo can be tracked (vdi/2770/Document/1/0, vdi/2770/Document/1/1 and so on)

Pattern 3: vdi/2770/1/0/Document/1/0

• Contains both a versioning for the source standard as well as the entity in this repo
• Bit of an overkill to me, creating certainly a lot of confusion and misunderstandings

--> For the existing aas, I'd prefer to leave the scheme as it is (Pattern 1). Just to prevent breaks as those URLs are also used in the RDF serialization. However, Part 2 already uses the scheme https://admin-shell.io/aas/API/<element-name>/1/0/RC02 (Pattern 2), which gives us only two options (or am I missing another one?):

Option 1: We introduce Pattern 2 for the Part 1 classes too, including changing the already existing versions.

Option 2: We change the identifiers in Part 2 for the final release 1.0.

What's your opinion?

[sebbader]

Could there be more than one id for the same element?

I would say so in general, yes. But simply because we cannot enforce it globally. The convention should be to not create additional identifiers, and definitely not in this repository.

[sebbader]

How do we document obsolete elements and thus obsolete ids?

Difficult question. I would say they should be marked with a deprecated tag in the latest version before the deletion, and then simply omitted...

[sebbader]

Small comment wrt Readme.md in this new branch.: Revision 2.0.1 from 2019 [3] should be Revision 2.0.1 from May 2020 [3]

I have integrated your comment with #22 and merged now.