[DDI-SRG] [MRT] Open model issues for decision - weird roles

[Wackerow, Joachim]

Thanks Larry,

I think it is not clear to me how to use the CV versus the four associations which represent basically also roles.
Furthermore, the 4 roles seem to be modeled as four different associations which seems to be unusual.

From: Hoyle, Larry [mailto:larryhoyle at ku.edu]
Sent: Wednesday, February 5, 2020 15:46
To: Wackerow, Joachim; DDI - Structural Reform Group
Subject: RE: [MRT] Open model issues for decision - weird roles

"The weird thing is that AgentAssociation itself has again a role item (external CV)."
The "weird" role referenced here is for the roles that agents play in the creation of some scholarly output. There are taxonomies for these roles (like https://casrai.org/credit/ ) which are beginning to be required by publishers like PLOS1. This facility was the outcome of the NSF grant that Mary and I had.

Creator, Contributor, Publisher roles are too coarse to truly give credit where credit is due. Unfortunately they are embedded as search terms as in Dublin Core.




From: ddi-srg-bounces at icpsr.umich.edu <ddi-srg-bounces at icpsr.umich.edu> On Behalf Of Wackerow, Joachim
Sent: Wednesday, February 5, 2020 6:35 AM
To: DDI - Structural Reform Group <ddi-srg at icpsr.umich.edu>
Subject: [DDI-SRG] [MRT] Open model issues for decision

Here is a list of open model issues.

The goal would be that we either find today an agreement or we describe the issue and possible solutions and park the issue.
I'll then make changes to the model according to the agreed decisions.


1.       Leaf classes without attributes and associations to other classes

a.       ControlStep, ScriptingAgent and RulesEngine

                                                               i.      Jay: they can be removed

b.       Sequence and Service

                                                               i.      Jay: need to remain as is in line with idea that this is a conceptual/logical model that some but not all will use for implementation too (Smile).
Sequence is a container for other ControlConstructs and because it inherits from ControlLogic which is reflexive maybe Sequence can host other ControlLogic and itself.
Service is an idea we would like to finish at another time.

c.       Designation

                                                               i.      Ja: Designation is another touchpoint with Signifier, Sign and Signified

                                                             ii.      Flavio: We are not using Designation anymore

                                                           iii.      Dan: Designation isn't really needed since we have the signification pattern. As a result, each application of designation, whether it be a code, term, or other, will be modeled in the realization. Designation, being a generic term, probably is not needed.

d.       What is the purpose of UnitSegmentLayout? Does it make sense for future expansion.

2.       PhysicalSegmentLocation has no attributes, only one association to ValueMapping, and only one sub class, SegmentByText. Currently it doesn't make much sense. Should this be maintained for future expansion?

3.       The current approach of string types seems to be too complicated. The structured string types could be folded into the regular ones. Furthermore, there are some inconsistencies.
Diagrams on the current approach and the suggested approach are attached.

4.       Missing identifiers for classes in DataDescription, Process, and value? of a Code , see Jay's email on "new model version 2020-02-04 / generated files" from 2020-02-04.
Attached is a list of classes in DataDescription and Process. The classes which inherit from Identifable are highlighted.

5.       Identification and Annotation. Identification could be an attribute not a super class (otherwise ", annotation could be a separate class.
The current model uses Identifiable and AnnotatedIdentifiable as super classes. The Identifable is just "Data-Based Inheritance". There are currently 16 classes which inherit directly from Identifiable and 23 classes which inherit directly from AnnotatedIdentifiable. There are overall 110 classes which inherit from other classes and finally from Identifiable.
The information which is captured by Identifiable can be modeled as a data type which could be used as attribute with the name "identifier" for each class. Even the information which is captured by AnnotatedIdentifiable can be modeled as a data type. The exception is the association to AgentAssociation. There are four m:n associations from AnnotatedIdentifiable to AgentAssociation, each with some kind of role (publisher, contributor, versioning agent, creator). The weird thing is that AgentAssociation itself has again a role item (external CV).
I see here some requirement for discussion how this could be simplified. Diagrams on the current approach and one suggested approach are attached.

a.       The information of Identifiable and AnnotatedIdentifiable could be collapsed into one structured data type with the exception of AgentAssociation.
Annotation could be an attribute of Identifier. This would be more limited than the current solution in terms of the annotation relationship.

b.       Another approach would be to have associations from classes which need Annotation. One annotation could be then used for many classes. A related super class could be constructed. The latter approach would make distinction between identification (which would be an attribute) and annotation (to which an association would exist).

c.       A third approach would be to include the identification information in the super class described in b). This is similar to the current approach but Annotation is not tied to a single class. This seems to be a flexible solution.

Achim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.icpsr.umich.edu/pipermail/ddi-srg/attachments/20200205/76862435/attachment.html