Integration of Views: Conceptual/Classification/LogicalDataDescription

Conceptual/"LogicalDataDescription"/Classification

Further integration and rationalisation of the objects in the Conceptual, LogicalDataDescription and Classification groups was conducted on Friday 24th.

The Classification team should take PARTICULAR NOTE of this discussion and the resultant content now in Drupal, as the integration that occurred resulted in significant remodelling of their proposed model.

Meeting notes:

The following notes reflect changes that have been made to the Conceptual, Logical Data Description, and Classification group by the working group.

Participants: Arofan Gregory, Dan Gillman, Jenny Linnerud, Therese Lalor, Chris Seymour, Steve McEachern

CodeValue (form Classifications) has been represented in a different way - as an attribute on Sign. CodeValue is no longer required.

SubUniverseType has been removed as an object (to Review package)

Represention and RepresentationMap have been removed as objects (to Review package) and their relationships removed. The function of these can now be provided by CorrespondenceTable and Map.

Discussion on hierarchies has been placed in parking lot.

A new Correspondence/Map “pattern” has been established by Jeremy as part of the Conceptual discussion, with 4 objects: CorrespondenceTable, Map, CorrespondingItem and VersionableType. This will need to be communicated to and discussed by the Classifications team.

The definition of Sign has been updated to remove the suggestion of a relationship between Designation and Concept. Dan Gillman’s concerns on this have been noted, and there may be a need to return to this discussion at a later date.

ACTION: Review relationships to Node, in the context of the difference in structure between DDI4 and GSIM.

ACTION: The integration of the proposed Correspondence pattern needs to be finalised (particularly CorrespondingItem and VersionableType) but depends on what is decided about the treatment of Hierarchies and Nodes.

ACTION: There is a need to determine whether CategoryItem/CodeItem/XItem is required within DDI4 (to match as it exists within GSIM). This should form part the review of the Node object.

QUESTION (from Wendy): Whether RepresentedVariable should NOT be a sub-class of ConceptualVariable. This would be resolved if ConceptualVariable (and ALL the variable objects) are NOT abstract classes. DECISION: Simple Association Relationship “LinksToConceptualVariable” between CVar and RVar and from RVar to IVar have been removed.

Recursive relationships have been removed: on ClassificationItem

Node may require THREE relationships to itself: Instance of, Part/Whole, Parent/Child
A constraint on the recursive relationship within Node has been added that “Like must contain Like” (e.g. you can’t have a Category and a Code in the same recursive relationship).

LUNCH BREAK AT THIS POINT.
DAN GILLMAN DEPARTED IN THIS BREAK.

Meeting resumed.

Recursive relationships removed: Code, CategorySet, CodeList.

One recursive relationship was removed from Statistical Classification. The other recursive relationship is kept as it is required to identify the variants and versions (refer to Neuchatel for details).

SubCategoryType object has been removed (to Review package) - as it is only an artefact to support the creation of Hierarchies in XML. The remodelling of hierarchies makes this unnecessary.

Relationship between ClassificationItem and Code has been removed because it duplicated the relationship that was inherited from the Node.

Nodes are NON-REUSEABLE. This is to ensure that hierarchies can be described as their own NodeSet. (See Node explanatory notes).

We identified Objects that may need to be mapped using the Correspondence/Map framework:
Question
ClassificationIndexEntry
Universe
Code
ClassificationItem
Concept
Category
Variable(s)

PARKING LOT ITEM:
DISCOVERY - Get rid of Foreign elements - but note problem of changes in foreign namespaces. May need to version the foreign namespaces to maintain the references.

PARKING LOT ITEM: COMPLETED
At the end of the meeting, edits were then made to the following objects to remove the term “Type” from the end of their name:
Citation
Contributor
DynamicText
Form
HistoricalDate
Image
InternationalString
Latitude
Longitude
Point
Polygon
ProprietaryInfo
Publisher
Range
Relationship
Segment
Software
SpatialCoordinate
StandardKeyValuePair
StructuredString
BibliographicName
CountryCode
PrivateImage
Statistic
RangeValue
ArrayBaseCode

The following were retained as it was unclear if they were Types: 
PrivacyCodeType 
BaseDateType

The following require review of name - they are not types but need different names:
CodeValueType (can’t remove “Type” as there is another “CodeValue”)
OneCharString (suggest possibly “Char”?)

Process

We need a document that describes how to use the process model

ACTION:

Conceptual

Touch points for instrument

Response Domain,   - is a touch point for instrument, related to sentinel value domain and substantive value domain?

Relationship between Question/Capture and represented Variable - needed for instrument, could replicate 3.2 relationships (but relationship could be stronger). think it is represented variable.

Where is the data? Is there a link to Datum or is it to one of the variables?

Touch points for Data Description

We think that the work by Ornulf will touch instance and /or represented variable

Touch points for Codebook

Codebook is so meta. They need to wait until the other models are settled so they can see what has actually been proposed.

ACTION: Instrument use cases and further Drupal detail (Jon, Jeremy, Barry)

ACTION: More Codebook (Wolfgang)

ACTION: Looking at Conceptual objects (Steve, Therese)

Collections / Schemes/Groups

Needed by instrument, Codebook have discussed the study object. Jay has a draft model that could be used for this.

ACTION: Future action