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

[Wendy Thomas]

contributor  -- roles: editor, data capture, project manager, project
member, ...
DataCite alone has about a dozen of these for contributor

On Wed, Feb 5, 2020 at 8:55 AM Wackerow, Joachim <Joachim.Wackerow at gesis.org>
wrote:

> 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
> _______________________________________________
> DDI-SRG mailing list
> DDI-SRG at icpsr.umich.edu
> http://lists.icpsr.umich.edu/mailman/listinfo/ddi-srg
>


-- 
Wendy L. Thomas                              Phone: +1 612.624.4389
Data Access Core Director                 Fax:   +1 612.626.8375
Minnesota Population Center             Email: wlt at umn.edu
University of Minnesota
50 Willey Hall
225 19th Avenue South
Minneapolis, MN 55455
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.icpsr.umich.edu/pipermail/ddi-srg/attachments/20200205/201a928d/attachment-0001.html