Pre 2016 Meeting Minutes

ATTENDEES: Wendy, Dan S., Achim, Dan G., Jon, Larry, Jeremy, Jay

AGENDA:
DDI 3.3 issues and action plan

• 15 issues - including the 9 new ones
• Majority have proposed solutions - go over these and decide if these are reasonable
• Those without proposed solution except the one about parameter bindings - wlt (in next week)
• Agenda for Monday - hammer through those with proposed solutions - Monday 5th
• Add Hilde and Guillaume for discussion of parameter bindings on the following meeting
• Send out email---have people read through and comment

Contents of Functional Views

• The point of the views is that we have document types are know
• How does this get associated to the other content information
• There is a difference between a class called a data set and a collection of classes you might want to call the full documentation for the data set
• So how does this associated to the view as a whole
• DocumentationInformation is the metametadata
• How does this get serialized in RDF? Plan is to have an ontology element per view but not about the instance. A constraint can be done per view but not per instance.
• This shows that we need to look at all other types of information in the same way as we are no longer document focused
• Enter an issue in DMT on this - Dan Smith will enter and others should comment

Terminology - DMFQA-41

• Label and DisplayLabel - the framework Dan G. laid out is a differentiation of kinds. DisplayLable you could put a label into
• If you want the framework to d
• Definition belongs to Concept and perhaps not other things - have a good guideline for WHEN would this be applicable.
• Identifier - A name you INTEND to use to dereference, implies uniqueness within context
• A name is actually the highest level and label and identifier are "kinds" of name but there is also a generic use of name
• Need good documentation on how each is used
• Column name could have two columns with the same name
• Trying to define it terms of what it was going to do not how it compares to other like things
• Identifier could be defined as within a namespace/context
• Jon will take a bash at examples and guidelines 

ATTENDEES: Wendy, Achim, Larry, Jon, Flavio, Johan

Update from Sprint

• All had either been at sprint or on the MT meeting update  

Work on Views

• Documents from TC were used as input to the discussion and decisions on Functional Views at sprint
• TC assignment to finalize list of standard content for FV's which will be accepted and tested in next release
• ACTION: Wendy will draft final list and send to TC for review 2015-12-17 

Election preparation

Role of Chair:

• Convene meetings (Post agendas, minutes, additional materials)
• Ensure that tasks are clearly articulated and prioritized by the members
• Manage workflow
• Prepare yearly reports to Scientific Board
• Prepare statements from the TC to external bodies as required (Scientific Board, Director, Executive Committee)
• Ensure that procedures for publication and review are followed
• Ensure that the work of the TC is transparent to the community
• Encourage new membership
• Moving Forward Advisory Group member
• Executive Director’s Advisory Group member

Role of Vice Chair:

• Convene meetings when chair is unavailable
• Assist Chair in performing the tasks of the Chair
• Moving Forward Advisory Group member
• Executive Director’s Advisory Group member

Preparing next year’s agenda (what do you want on it and what we are scheduled for)

• Q2 2016 MF release – May/June

• 3.3 beta release for review - March

• RDF Vocabularies: XKOS, DISCO, PHDD(?) – February

• Versioning of the new DDI – Flavio’s paper, earlier discussions – implementable proposal to MT – Nice before a Codebook release

• Disposal of review responses for 3.3 – April/July

• Disposal of review responses for Q2 2016 – June/Dec

• Disposal of review responses for RDF Vocabularies (make sure that its done by RDF creators) – March/June

• Release of Codebook View – possible post Q2 release to review View structure – July/September(?)

• Release of updated 3.2 High level documentation

• Update of Dublin Core files in 2.5 – sooner rather than later

• Shifting documentation production for DDI-L and DDI-C into the production framework being set up for DDI-Views

• Design Principles document from Dagstuhl 2015 –

• Process for reviewing material from MT for publication

Assignment for 2015-12-10: Designations, Terminology, Name, Label, etc.

• Flavio      walked through his summary chart of Dan's document (see DMFQA-41) 
• Discussion      on need for clear, non-geeky, documentation on usage is needed but we need      to retain the technical descriptions and diagrams which better explain the      relationship between the classes involved
• Review      for next meeting and note comments via listserve and on DMFQA-41

ATTENDEES: Wendy, Dan S. , Flavio, Dan G., Larry, Jeremy, Olof, Johan, Jon

Repository Structure

• needs to be based on actual intended use cases
• Olof will request a short period of time at the Sprint to address the structure of the production area other than the UML and  Documentation section which are similar in the two proposed models
• The settled parts of the repository will be set up, the decision for the remainder will occur at the sprint

Functional Views

• Copies of the two documents on the standard content of Views and the  structure of views will be sent out on the listserve. Please comment and prepare to finalize for submission to the DMT issue tracker

Designations, Terminology, Name, Label, etc.

• Flavio walked through his summary chart of Dan's document (see DMFQA-41) 
• Discussion on need for clear, non-geeky, documentation on usage is needed but we need to retain the technical descriptions and diagrams which better explain the relationship between the classes involved
• Review for next meeting and note comments via listserve and on DMFQA-41

NEXT MEETING WILL BE 2015-12-10 

ATTENDEES: Wendy, Flavio, Jeremy, Johan, Larry

Issues 71/66: View content

• Reviewed the document on 71. Added comments on lack of current decision on how views are created technically and clarification of types of views. Document will be revised and sent out on listserve for any final comments. When finalized will be entered as a DMT issue.
• Conversation raised the issues of how views are created from a technical perspective. Discussion centered on a balance of technical and documentary approaches. A draft of this approach will be written up and entered as a DMT issue for consideration as decisions about views are made. This is not a recommendation of TC on how to handle this issue but a statement of an approach that should be considered

Issues 41, 53 and related Name, Label, Definition, Description issues

•  Discussed the document in 71 that Dan distributed (Identifiers-Labels_Names_Designations)
• Clarified that Designation was abstract which may cause resolve the specific issue of 41
• Flavio will draft a short summary of sections 4 and 5 as they relate to the issues raised which will be distributed on list for additional expansion
• Larry will add to this document
• Wendy will prepare a table that will hold DDI classes and their definitions, classes and definitions from the document
• The intent is to clarify documentation in Drupal, relationships between classes, and identify where and why DDI has added additional granularity
• This should clarify where and how we address the issue of class specific "name" property

Some brief notes form the document: 

Designation ABSTRACT  (Sign, code)  

• Labels are called designations  
• Code - non-linguistic designation whose signifier corresponds to alpha-numeric strings  
• Datum - designation of a value

Local ID

Label A signifier has the potential to refer to an object.  In this case, the referring signifier is a label.  If that object is a concept, then the referring signifier is a designation.  A label is a representation of an object by a signifier which denotes it.  For instance, the token http://www.bls.gov is a label for the web site maintained for the US Bureau of Labor Statistics. The label is also an identifier, since it is intended to dereference the BLS web site. It is a locator, since the HTTP service is associated with it. Finally, ‘Dan Gillman’ is a name for a co-author of this paper, since the token is linguistic

• Serves 3 roles:  
  • a representation of an object by the signifier which denotes it   
    • Display label - human readable  
  • as an identifier (dereferences object within specified environment)  
  • locator as the environment  
  • name

Definition - A definition is descriptive statement conveying the meaning of a concept which serves to differentiate it from related concepts. It should be stated in the singular as a descriptive phrase. It should state what the concept is, not only what it is not.

Description - Describes purpose and usage (should this be changed to Usage?)

ATTENDEES: Wendy, Olof, Larry, Jay, Dan G., Flavio, Achim, Jon, John S.

Discussed the structure of the Bitbucket repository

Currently have a publication repository and a development repository, need to create an integrated system/structure to manage the flow of development work through production to publication

Achim set out a draft of a structure for the published repository for the Moving Forward production line

Decision:

• A separate repository for each publication  line (DDI-C, DDI-L, RDFVocabularies, DDI-Views) with a main branch containing published specifications and development branch containing production work
• The DDI web page would have explicit links to current/past versions
• Current priority is the development section for DDI-Views (suggested name to differentiate folders) in place prior to EDDI Sprint
• Other sections populated over the next few months

ACTIONS:

• Wendy will update document to reflect decisions
• Achim will revise folder names to be clear and descriptive and resend
• Everyone should review for completeness and clarity
• Olof will work with John S. to get repository structure set up
• Olof will work with Wendy to get currently published work and revision history out of sourceforge
• Wendy will work with Dan and Jeremy to get TC development work (DDI-L DDI-C) moved
• RDFVocabularies structure needs to be set up prior to February 2016
• Olof will work to translate production work to Ant

John will be available in a remote advisory capacity during sprint

Wendy will seek additional Ant expertise among active members 

John set up a Tool Administration Section - documentation on organization and a link was added to this page from TC and Modelling Team pages

ATTENDEES: Wendy, Dan G., Flavio, Jeremy, Jon, Larry, Arofan, Dan S.

Issues:

66, 77 related to views - discuss at Dagstuhl

52 Classification Design - is part of work Flavio is currently doing

48 - Wendy needs to review in light of collection document and put a recommendation to TC

47 - Documentation issue that Jon has on his list

32, 34 - enter in drupal

70 - note in report

77 - assign to Modellers

50 - Jeremy to provide background list of occurances

38, 41, 43, 53 - all part of the label name definition description discussion. Definitions have been clarified, need to write application rules

ATTENDEES: Wendy, Dan S., Jeremy, Dan G., Larry, Jon

Closed Issues 8, 78, 76, 75, 74, 72

Reviewed format of draft review report and made clarifications and minor structural changes. Wendy will continue to update as we progress through issues and get out a draft prior to Dagstuhl for final comment.

 ATTENDEES: Wendy, Jon, Jeremy, Dan S., Johan, Dan G.

Agenda:

DDI-L 3510, DMFQA-41, 73

DDI-L 3510: In version 3 there are two styles of inclusion (inline or by reference). 3.2 was made consistent in terms of having the choice at all locations. With schema validation they can still use by reference or inline.

• The idea is that we should create a profile that will support the fragment system rules. This would be an additional schema with its own namespace.
• It would validate the same fragment by importing instance and then restricting to disallow the inclusion by reference.
• Since the first would still be there it would cause no backward compatability.
• Provides a means of validation for the standard intended structure.
• Dan Smith will provide a draft of the schema

DMFQA-41:

Two points

1. application of Definition and Description
2. accurate documentation of what they are

Discussion:

• ISO 1087 has a good definition of "definition"
• Not everything needs both a definition, This was discussed in London.
• Go back and look at the Modeling material on name label description
• Jon will review wording options for documentation
• Guidelines for application will be reviewed if available and clarified

DMFQA-73:

• related to 41
• get draft to point for review (what's missing, what's not clear) to return to Modeling Team

ATTENDEES:  Wendy, Jon, Dan G., Dan S., Jeremy, Johan, Larry

Discussed: 7 (and related issues)

ATTENDEES: Wendy, Flavio, Larry, Johan

Resolved: 6, 10, 11, 13, 14, 18

Noted that upon writing up the report to the Modeling Team any action requests should be listed in the Modeling Team's issue tracker with reference to the document and any related review issues.

ATTENDEES: Wendy, Jay, Flavio, Dan S., Dan G., Jon, Johan

Resolved 37

28 has basically been resolved but Jon will draft out specific wording for the design rule for review

ATTENDEES: Wendy, Jay, Flavio, Johan, Larry

Resolved 69, 9, 58, 16, 17, 4, 23, 30

Closed 19

ATTENDEES: Wendy, Dan S., Larry, Flavio, Dan G., Jay

Started with DMFQA-8 and focused mostly on clarifying the use of CodeValueType and InternationalCodeValueType. We need to do a better job of linking related issues as opposed to similar or same issues as one discussion spreads into other related areas.

Assignment: Each person review their issue list and report to the group (via DDI-SRG mail list) which are ready to discuss in the next meeting. Notes in JIRA should include clarification of issue, identification of options and impacts, recommendation for action. Members should review issues identified as ready for discussion adding notes with agreement on recommended action, questions, alternate recommendations, etc. In this way we may be able to quickly resolve some issues and move through the whole set in a timely manner while not short-changing those issues that require more thorough discussion.

Wendy will send out an email of this assignment along with issue assignment lists.

ATTENDEES: Jon, Wendy, Dan S., Dan G., jay, Larry, Jeremy, Johan, Achim 

Reviewed 61-68

Reviewed 51-60

Attendees: Jon Johnson, Dan Smith, Jay Greenfield, Jeremy Iverson, Larry Hoyle

Reviewed JIRA Issues 41-50

ATTENDEES: Wendy, Dan G., Jay, Jeremy, Jon, Larry, Flavio, Dan S.

Reviewed and assigned issues 25-40

Wendy will not be at meeting next week, Jon will chair

NOTE: A recent review of the bylaws indicates that TC  will need to elect Chair and Vice-Chair next spring (3 year terms, no term limits). Probably want to document roles of Chair and Vice-chair prior to election. Election does not have any procedural requirements (in terms of how voting is accomplished)

ATTENDEES: Wendy, Achim, Larry, Flavio, Jon, Dan S., Jeremy

Review of DMFQA issues

• Updated previous assigned items
• Jon has taken the assignment for all documentation related issues (67,57,53,46,40,35,15,13,12,4) he is consulting with others as needed for content
• Began adding labels for documentation, modelers, production, others will be added as needed
• Assigned issues 19-24 to Flavio. He should have some update on these by July 9 meeting
• Issues 11, 16, 17, 18 assigned to Wendy (two are consistency issues and others are issues reported back to modelers and production teams

Jon will chair 9 July meetings as Wendy on vacation

ATTENDEES: Wendy, Dan S., Jay, Jeremy, Jon, Larry, Achim, Dan G.

Agenda:

• 3.3
• Review process for DMFQA issues

 3.3

• Due to conference/post conference issues no additional work has been done
• There are a number of new issues entered post our last review. We should decide if these will be addressed in this release 

Review process

• Triage and approach for dealing with Q1 review issues
  • Split them out in terms of content/packages
  • Separate the ones related to each other
    • documentation
    • specific content
    • overall structure
• conceptual level issues allow us to address the work process
• identify those that have a long range impact and push for changes
• if we simply park issues this may result in disillusionment of those reporting
• Whatever action is taken (resolution, parking) we must explain action - detailed thought and responses to every comment
  • Its a draft release and all the issues might not be resolved
  • Not all issues may be resolvable at the moment because we are in a draft/development mode
  • The comments are there to help guide us to a solution
  • The resolution may be a set of directives to the modelers
  • Part of the review of each comment is a target milestone for being addressed

Walkthrough of issues in order of entry

• Completed first 10, assigned - 2 were deleted, 2 resolved and closed others in  progress
• Wendy reviewed remaining and classified into general areas such as Documentation, Class, RDF Mapping, Modeling approaches, etc. and sent to list. If we can agree off-line to bundle some things such as documentation or RDF Mapping we may be able to speed the process along

ATTENDEES: Wendy, Olof, Achim, Jeremy, Dan S., Dan G., Flavio, Jon, Jay, Larry, Johan

Atlassian Tools

• Wendy will reconcile the two documents and comments from the email exchange in the past week
• The document will identify were discussion is needed and identify the areas regarding access and organization under discussion 

Documentation for DDI4

• At the bottom of these notes is a copy of an email from Olof, provided just prior to the meetings
• The two primary issues are
  • Where do we author the content
  • Where does content integration take place
• In terms of authoring content for non-class/view specific information we can do it in Drupal or outside of Drupal
  • Outside Drupal:
    • content can be stored and edited in a subversion system (BitBucket) - Olof has provided an example of this using Sphinx and the DDI_4 Bitbucket repository
    • If we hold outside of Drupal in time this could be a management issue
    • If we're trying to insert things from the class information into something that is held outside could make it more complicated
  • Inside Drupal:
    • We currently cannot support structured text, images, graphics, etc. within Drupal and would need to add this functionality
    • If we provide a WYSIWIG editor we could add HTML tags without users having to learn structured format This is needed for class/view level documentation also
• Requirements
  • We need to create content in a way that can be chunked into identifiable, classifiable, and manipuable sections for repurposing. This is needed for class/view level documentation and high level documentation
  •  We need to be able to process content into the format needed by the user
  • Now as the models are becoming slightly more mature we want to talk about them in ways that are not posible in Drupal (pictures, texts etc.).
  • We need to remain flexible as tools and environment changes
  • One of the requirements is to be able to edit a chapter with pictures, graphs, text, links, examples, etc.
• Right now DocBook is problematic. First we are not creating a book. Second the current output from Drupal requires a considerable amount of handwork.  

• The thing we want to do is have a submission granularity so we can repurpose such as inserting a live example, or insert the Drupal graph. The intermediate format should provide the little bits. Seems much better to manage this in the builds in the same way we do that in the bindings.

• Sounds like it can accommodate a lot of different workflows. When Drupal bits change we don't lose the other bits

• Advantage to holding outside of Drupal will make versioning syncs. User outputs should be more "snapshot" than granual in terms of versioning. We should sync at the snapshot level.

• There is a tension between concept driven and resource driven
• Structured text is more of a streamlined approach.

What we should do:

• Existing stuff in Drupal should be pushed out into a folder structure in BitBucket
• Documentation format for Class and View level - Sphinx and resturctured text
• Documentation format for other - Sphinx and resturctured text
• We can use restructured text in the in-line content in Drupal
• What happens with what is invalid - (it won't break) it will come in the error log during a build
• Need a validator to spit out error messages.
• Putting structured text inside an editor in Drupal will hopefully go to Help and find out how to do it.
• We need to determine length of content for different usage (long discursive content in Drupal) probably needs to be managed differently

Proposal

Test out the usage of Sphinx and structured text

• Olof will do some examples and send to email list and do a more complete output from Drupal for this
• Achim will provide the limited HTML we would want to use with a mapping table.

Pertinent links:

http://sphinx-doc.org/

http://sphinx-doc.org/examples.html

http://ddi4.readthedocs.org/

https://ddi4.readthedocs.org/en/latest/Introduction/index.html

***email from Olof***

I have been thinking a lot about the future for the documentation and how we can and or should be doing it. Your suggestions for merging the structured documentation outputted in the DocBook xml to xsd and rdf specs makes a lot of sense. This documentation should be plain text containing descriptions, labels etc for classes, properties, relations etc.

For writing and maintaining all the chapters containing static texts and tutorial I don’t I have a different opinion. This documentation should have an online-first approach where we target the html output first and also build the complete pdf from the same source. Having a folder structure in bitbucket would make this easier to maintain, build, extend and version for working collaborative. The same technical documentation should be outputted in this structure as well (directly from lion).

The point I tried to make in the last sprint was basically having some kind of standard way to do the documentation in a open way where we easily can combine the class documentation with any kind of extra documentation in a plain and versionable way and I think restructured text in git is the most flexible solution for this.

The documentation is something where we need to have a lot of flexibility to write examples, references, include pictures etc and doing this in drupal and have complete control of the output via DocBook/DITA is a nightmare to do (mapping tags, including pictures, markup examples etc).

Having this parts in markup in folders, each chapter in its own file would be the best way to solve it.

To summarize:

• ·         Class documentation in plain text (captured in lion)

o   XMI + DocBook -> XSD & RDF

• ·         Class documentation in plain text (captured in lion) and hand written formatted documentation

o   Folders containing restructured text (from lion and manually added) & graphs -> html, pdf, ebook

ATTENDEES: Wendy, Dan S., Jeremy, Jon, Larry

Extended review period:

• Extend review through June 14 after which we will continue to accept comments. Subesequent development review releases will be comprehensive (include all previously released material) so comment are still relevent.
• Disappointing not to get feedback from those who were pushing for publication. What is the point of pushing if you don't engage with review? It would be interesting to know who not involved in Moving Forward Project has looked at any of the work?
• Would be useful to have afew minutes at the Scientific Board meeting to raise the following questions:
  • Does this look like we're moving in the right direction?
  • Does it look like we're aligning with GSIM in a way people like?
  • We've outlined some views, have we missed something?
  • Does the documentation meet your needs?
• The Alliance has invested money and individuals have contributed in-kind and will into an indeterminate future. It shouldn't continue in a vacuum and we need community contribution. Is this the priority of the Scientific Board? There is still work to do on documentation and examples for the previous versions.

Production Framework

• Versioning will impact documentation.
• Seems like implementing versioning in Drupal is not something we are doing during sprint.
• Top priority in Drupal is finessing the current output of Drupal
• Versioning decisions can make major impact on bindings.   We need to settle the discussion and make a decision before introducing things into Drupal.
• We need to ensure these longer term issues don't override the need for short term changes

LOST INTERNET

ATTENDEES: Arofan, Wendy, Jon, Flavio, Larry, Dan G., Jeremy

Recap of Modeler's meeting review of Flavio/Jay's paper

License:

• Reviewed License draft
• We ant other models to use and incorporate our model (with attribution)
• Recommend change to CC International
• Revise and send to AG

Documentation in the Production Framework of DDI Lifecycle (MD)

• We need to have a discussion prior to sprint on this
• Pertinent to process integration work
• What needs to be done in the short, medium, and long term
• Delay start of next weeks meeting by 1 hour so Jon will be available

The continuing "name" saga

• Is the use of "lifecycle" in the name still important
• Saying its model driven is now a bit like saying a car has wheels
• Model is more of a functional orientation rather than a lifecycle orientation
• What about our assertion when we started this that it was a continuation of Lifecycle
• There is a generalization process going on so that "lifecycle" is a misnomer
• DDI-Unified (agghhh no)
• We need to reopen this issue among a broader group
• Just DDI
• ACTION:  bring to AG via email and recommend a fuller discussion of our vision of the boundaries of what we are trying to achieve among the membership (perhaps at meeting) and then pass on to Marketing group
• Let the name and marketing strategy of the product come out of that discussion

ATTENDEES: Wendy, Dan S., Jay, Jeremy, Johan, Jon, Larry

Agenda:

• update 3.3
• New Issues 3503 and 3504
• Unresolved issues

Update on 3.3

• Set up Bitbucket and created a DDITC Team and 3 repositories (DDI-C-_2, DDI-L_3, and DDI-L_4)
• Members need to set up Bitbucket logins before being added to the team
• These are linked to their JIRA projects
• Instructions on the use of Bitbucket coming soon from Wendy
• Once the this last set of issues is resolved and committed we can validate the Beta version, create field level documentation, and release for review (probably June)

New issues 3503 and 3504

• See JIRA for details
• Reviewing use of xs:integer for replacement by xs:nonNegativeInteger

Unresolved Issues

• 3499 Quality Standard - attachment was damaged. Dan will put up as pull request
• 3498 Development Activity Type - Wendy will do review of link provided by Peter Granda, expanded empty group members as needed, and reduce substitution group members as required

ATTENDEES: Wendy, Arofan, Achim, Dan S., Flavio, Jay, Jon, Johan

Status of Questionnaire development feedback on DDILIFE-3498

• Peter Granda sent link to source information
• http://ccsg.isr.umich.edu/pretesting.cfm
• Dan S. will review and add comment on this issue to JIRA

What needs to be done regarding remaining deliverables in Q1 release 

• User Guide
• Bindings and documentation
  • RDF
    • Issues in terms of how the HTML is embedded
    • HTML in the production framework - embedding in the RDF/OWL is tricky. The common tools don't work
    • Open source tool is an option
    • Semantic web lists for tool suggestions
  • XSD and XSI
    • Could use existing tool to create this
    • Need a list of allowed HTML text
  • The documentation should flow from Drupal to DocBook to XML schema
  • There is an XSLT needed for both XML and RDF production (merge on class name)
  • Documentation in the XSI that can used for tools (needs to be in ASCII) could also be used as a second means of entering into the XML schema
• For the purposes of getting the Q1B it seems to make sense to use OWL Doc.
• Do we release Q1-B
• Do we need another tooling focus sprint? Release process as well as production processes
• Documentation issues:
  • Bugs in what we've already done
  • Need a sprint
  • Add User Guide and Binding to Q2 and not release any of it for Q1 content
  • Meeting outlining main issues and then schedule meetings to focus on them in the Sprint
• Can we check on the addition of Bamboo (build server) - Wendy will check on what we gain.
  • Currently build process is in Drupal. Bamboo could help in update file - what does Drupal do (xmi, DocBook, etc.). Would more people know how to change things in the Atlassian product? Could this help with the Drupal bottleneck issue? Dan S. will check out functionality
• What do we recommend? Do we have a consensus?
  • Q1-B
    • bad decision politcally to delay. forces us to deal with the issues now and not push it down the road; until you physically do it you don't know what the problems are (JJ)
    • If it is resolved in the sprint then a Q1B (FR)
    • Quality must be acceptable (JF)
    • Need to have the documentation in line before the release of the bindings (JG)
  • All in Q2
    • The bindings are a by-product and the model is the focus so just include them with the next one (DS)
    • Fewer releases are better and the bindings are really not ready for comment.(AW)
    • Still too many problems (AG) If the binding stuff working and well documented maybe after IASSIST. Freezing during review. A Q1-B might extend the freeze period.
• Focus on the MPLS sprint to get the process working. If we can get it working we will release documented binding on Q1 content in the summer. If not, then there will be no release of Q1 sepcific bindings but they will come out in Q2 (which is inclusive content).

DDI Lifecycle (MD) - Structure in Model and Bindings (see email 4/23 read and comment before meeting) (Achim)

• If we do the versioning as currently planned it has some potentially devistating effects on the binding
  • version names in the bindings is non-optimal
•  with each class being versioned every time it changes and the model being versioned
  •  is capturing that a modeling issue or an issue for the user?
• Would be helpful to see if a class has changed or not.
• Flavio and Jay had agreed to frame up an example so we could look at the effects
• If the version of each class should be in the bindings or not, but it should be in the model?
• Right now a class is published as a new version (i.e. by being in a different namespace that is versioned)
• In future a system may need to support 2+ views that contain multiple versions of the same class
• Has a class changed?
• We need to get the rules right and try to model possibilities and how they act within these rules.
• Our relations are strongly typed and one that is strongly typed to a "version" of a class and are you repeating a
• For RDF if we are putting the versions into the classes and the releationships are strongly types the predicates may have specific ones they relate to. How do you support that with the data?
• When you have 3 versions of Question object what are the class names that allow for disambiguation?
• Versions on classes are similar to program libraries. Can a section of a program library be seen as a view? Is the situation the same. Can the system use the updated program library. It has a release number. Classes change with updates of libraries. Some are now versioning classes. Can we learn from this experience?
• What's been proposed on versioning makes sense within the context of the library but how can it be exposed in the bindings?
• We wait for the examples and then discuss again.
• Questions on document (Achim):
  • issue of namespaces with bindings. Where and in which namespace do all of these classes live. They can't live in the functional views
    • All could live in one namespace (i.e. DDI) or in a specific namespace like the UML package they are living in.
    • The discussion in London. The only namespace living in the Functional View is that of the functional view which doesn't live in the model.
    • Right now we have them in the packages to support partial releases. We need to collect pro's and con's
    • Single name space
    • PRO moving between packages not a problem
    • CON it will get huge, problem pulling the whole thing
    • There is a feeling that in the current DDI there are too many so we'd need to review this
  • See the XML binding section:
    • A separate XML schema per functional view; list only those used for inclusion others are listed as documentation
    • That corresponds with the plan of the functional view.
    • Right now theres a hybred of this approach
  • Identification of each class (section: Identification) and a couple of xmi attributes could be used for this purpose xmi:ID xmi:UUID xmi:label)
    • These attributes could be used to capture the version of a class but this may not be necessary. The version would be part of the identification value of the UUID. To have version information as a property of each class. see the document
    • Use of this option depends very much on how we deal with the versioning in general
  • Would like to stress that everyone has a look at views and view parts of software architecture. We should be able to learn from this and make use of some of the terminology.

JIRA  implementation issue:

• Dan and Jeremy will get together with Wendy next week and get Bitbucket

Next weeks agenda:

• Updated 3.3; new issues 3503, 3504
• Achim and Arofan will not be on next weeks call

Attendees: Wendy, Arofan, Achim, Jon, Johan, Jeremy, Dan S., Jay, Dan G., Flavio

Last minute release issues  

• Agent example when completed it will be added to the site as a document (not in release)

Town Hall possibility -

• Brief tour
• Walking through the model
• Interactive with video and slides
• Who would do that - small group (2 or 3 involved in presentation)
  • walk through (Jay?)
  • example / use case
  • Q & A
• Do for second release when there in more use case content and more band width to make it good
• Should have agreement on identification and versioning, overall architecture, functioning bindings, and the XMI flavor used
• class diagrams will be available - need some work
• Check with Mary regarding software and what support is provided with this 
• (Larry, Flavio, Jay) - a small core group to outline the content

CSPA LIM work (Flavio)

• Develop a implementation model for CSPA LIM - how can we interact with them
• Do we share UML?
• How do we work in a harmonized way?
• TO DO: (Flavio) Send email to AG on what is going on in the CSPA LIM world and the value of interaction

License options work:

• When do we want to get this to AG?
• Pulling in background information from http://opensource.org
• Creating a comparison grid for BSD, quick_access, mit, gpl (others?)
  • What criteria are we comparing them on?  
• Issue of contributor's agreement separate or part of the license issue?
  • Default is that the person who made it owns it 
  • DDI should have the interest that contributed ideas are not protected by limiting rules
  • Individual is interested in publishing paper that were contributed to the community
  • Statement should address both of these perspectives
• list goals and it identifies a license that will support those goals
  • http://choosealicense.com/    
• What is the timeline
• Are any of us in relationships that could have more potential conflict than others?
• Get going to the Executive Board before June 3 members meeting on June 1 (to AG on the 20th)
• AG should decide if this should get discussed in Annual Meeting
• TO DO: Wendy with Achim pull together what is there by around first of month

Agenda item for next week:

Look again on the conceptual issues DDI Lifecycle (MD) - Structure in Model and Bindings April 10 mailing (resend email)

Attendees: Wendy, Achim, Johan, Jon, Larry, Flavio, Jeremy, Dan S., Jay

DDI Licensing and Copyright

• Copyright for Documentation: its not clear between the specification and implementation
• International ?
• Commercial Use ?
• Model/Specifications -
• Copy left forces everyone to release in the same way  
  • If its a derivative work it has to all be open
  • Others say anything you add can be closed - but what they get must be open
  • Collective mark - says that only Alliance members have right to post the logo   
    • Each "signifying that they have the right to publish and develop the specification"  
    • The alliance can publish   
    • Extensions can be used behind closed doors  
  • If its LGPL its safe but they cannot pull out the documentation and display to user  
  • Apache or BSD (see W3C) very open license for software development  
  • CC with attribution - commercial use allowed
• Documentation - CC with attribution - commercial use allowed (currently use non-commercial)  
• Data capture thing which is a new
• Are we publishing the XMI for the model - claiming rights for part of model by claiming the extension - others own things that are part of your body.
• New data sources are raising the possibilities of abuse. Commercialization is a bigger issue.
• ACTION: Long term write up and bring this summary to the AG then jointly bring to the Exec
• ACTION: Short term - they are no longer separable at least for the DocBook on the class level etc. Everything is one great big run. Use LGPL for Q1
• Its not clear what the implication of the collective mark. If the DDI is modified they can't call it DDI without the permission of DDI.
• Contributor's agreement does not exist
• Development Drafts should go out as LGPL - then bring back to AG and Exec. This is a holding position and we need a decision in a reasonable time frame. We need to make a clear proposal along with the AG.
• Do we want SAS to incorporate DDI into their products. Yes. If so we need to look at the Apache license
  • http://www.apache.org/licenses/LICENSE-2.0.html
• How is it done with the documentation for apache and BSD licences? Is it separated? Apache seems to cover all parts under the same license
  • http://en.wikipedia.org/wiki/BSD_licenses
  • http://www.cdisc.org/quick_access
  • http://recomparison.com/comparisons/101197/gpl-vs-bsd-vs-mit-license/
  • CDISC  http://www.cdisc.org/quick_access

• This site has a lot of information on open source licenses.

  http://opensource.org/

  
  

Q1 update:

• Reiterated reason for week delay and limited products.
• Olof has solved rendering problems

User Guide:

• Class Specification needs to be re-rendered based on Oliver's changes All of the full and partial review All introductory stuff Diagrams will probably be in separate PDF because of landscape issues with link to PNG in same document plus a PDF Still have to hand build the primitives Views also currently need a hand build - may be flat - get feed back on this (where are the views confusing) - maybe a request to self identify for a more focused discussion
• User Guide - pull in the bits from Achim's versioning document and then we'll need to iterate it as we go along. Currently bare but worth putting out in order to get feedback. Especially since we specifically did not put things in the class document. For this draft release it is important for people to understand the overall picture. Which document lays out the overall specification. An overview of the technical specification. The point of the User Guide was taking the documents on confluence, editing them down, and adding a high level view in Class Specification or User Guide (more conceptual things). The FAQ has a broad picture of why we are doing this craziness. What isn't covered by that?
• Where are the latest versions? Are they on the Google drive? Jon will get them up.

README for Q1 Review:

From Modelers

• Hold an on-line meeting with folks who want to do the reviews by walking them through the model - a DDI Town Hall
• Do we need a UML Tutorial - post it to SRG list
• Click through document - future thing
• We may have not done enough cleaning to simplify - are things still too complex? too simple?
• Are we covering the 60%, 80%, 90%?
• Reaction to the cascade model of describing variables
• Under-specification or under-documentation
• Inheritance through extension strings needs to be explained!!
• A table view inherited attributes - so people can see everything that is available
• Have some examples of views, an Agent view etc.
• Point out the problem of the "wrapper" - mechanisms for including information about the package - we could have input at the binding level but it would vary by binding
• A standard set of things that go into every view and then put a container around them like "View Management"

Additions from TC

• If we're not publishing bindings we state that we're not asking for specific feedback on those (particularly last piece)
• Model and high level documentation.
• Are the set of properties complete? under-specification?
• Do properties and relationships look correct?
• Are there too many levels in terms of relationships?
• Are the classes modeling something in real life?
• Is there a balance between real life and a clean model in a technical sense?
• Does it have reusable components to the extent needed?
• Documentation - Class level
• Is it sufficient? Do they relate to the domains well?
• Do we understand how they relate to other domains?
• Is it clear what a class is and what it relates to in the real world?
• We have some abstractions of things, like collection and other patterns? Is this the way to go?
• Overall structure, class library, views, bindings etc. Are there any comments on that?
• Is it a workable approach? Is it sufficiently documented?
• If we give them use cases (stakeholder, viewpoint) along with the views.
• In the future when we publish other views we'll publish in this format with use cases, narratives, paths through, etc. Help people think about their cases. What would be useful to have?
• Is this useful for you? Do you see yourself using this? Why/why not? What could be done to make it better?
• If you don't plan on using this what would you be using? Let's us know what we should be looking at in terms of what we cover.

• In the future when we publish other views we'll publish in this format with use cases, narratives, paths through, etc. Help people think about their cases. What would be useful to have?

Future reviews:

• Do we have the right views?
• What is the value of looking in Lion -- are the right classes being used? Should others be added or extended?
• We are asking technical questions about the product
• If we give them use cases (stakeholder, viewpoint) along with the views how should they be presented? captured in Drupal?

Attendees: Wendy, Achim, Dan G., Dan S., Jeremy, Jay, Johan, Larry, Arofan

Work Products Paper - work product paper

•   Needs formatted and copy edited
•   Send out edited document with sentence removed

BitBucket organization for DDI-L DDI-C and DDI4 work - deal with via email

Process documentation

• DDI4 Q1 documentation -
  • Submit comments
  • Introduction section "DDI-object-description"
    • Change - Object to Class (OWL/RDF uses classes, UML uses classes, XML doesn't care class/object)
    • There is a distinction regarding view (Template, composition, instance) remove sentence mentioning this...just talk about functional views (see Achim's comments on Figure 1)
      • Use remove Views and Composition of Views (See Larry's drawing)
      • ADD text in A to describe picture including a sentence:
      • Model - the whole thing
      • Library of Classes - the reusable packages  datatypes and classes
      • Functional Views - use things from the library
      • Suggest a visual of specific packages/views being released in Q1 - in future generate it from Drupal images
    • Versioning Section G.
      • the classes within each package are versioned
      • the Functional Views are versioned
      • See Larry's changes to second paragraph
    • Always use "Library Packages" and "Views" never just "packages" 
    • The conceptual issues should settled first
    • Need to clarify how maintaining multiple versions will be expressed in the bindings
      • Discuss at NADDI
      • Clarity is the issue - where and how we use UML and UML terminology
      • For Q1 review: instead of "packages" use "Library Packages" change "views" to "Functional Views"
      • Review Achim's "Thoughts on functional views"

RDF/OWL Bindings (from Achim's email)

• I had last week a one-day meeting with Thomas Bosch, Benjamin Zapilko, and Johann Schaible (better known as Wanja) at GESIS.
• I discussed with them a list of open issues regarding the OWL binding and related questions. I’ll provide the results in an issue list in Jira.
• With the background of this conversation, I realized now better how the functional views can be realized in the model and the bindings.
• Most of these thoughts are very much in line with previous thinking of views.

UML Model

• Functional views have only references to classes in packages, they have no classes for themselves. Functional views are realized as packages as well.

XSD/XML Binding

• Functional views have a XML wrapper element (the root) in their own namespace. All used classes (referenced in the model) are in the namespace DDI. Classes which are used in multiple views exist as “definition copies” in each view. Therefore it is not possible to have the classes in the namespace of the functional view. This would result in the existence of multiple instances of the same class in multiple namespaces.
• The described approach can validate XML instances according to a specific functional view. The approach is in-line with the thinking of the DDI developers to minimize the number of namespaces.
• A more elegant way than “definition copies” would be a reference to elements in the DDI namespace. This could be more explored. But the issue can be then that a functional view needs the whole DDI library as XML Schema which can be cumbersome and is not intended by the idea of functional views as subset of the whole specification.

RDFS/OWL Binding

• A functional view would be the ontology (in the functional view namespace). But all used classes would be in the DDI namespace. This approach has basically only documentation purposes. Ontologies cannot be validated according to a functional view definition. This is the case with all ontologies.
• Thomas works currently in his PhD on validation approaches of ontologies. He mentioned that a tool-based approach could validate an ontology regarding the existence of required classes and their relationships.

General

• Having all DDI classes in one namespace can be overwhelming. Another option is to use the namespaces of the UML packages where the classes are living in.
• Pro: easier maintenance, easier orientation
• Con: packages are used in the bindings, not only for maintenance purposes in the UML model. This means: one a class has a home in a specific package it can’t be moved to another.

General discussion:  

• Review Technical User Guide and comment and raise issues that need to be covered and if we need to decide these
• Need a statement of versioning policy and how we express it in Drupal, Model, and bindings
• What is the relation with this conversation and a release? Is it is scope for this release.
• The responses to the release are input to the discussion
• If its not in scope we should be prepared for some very negative feedback
• The negative feedback is critical to doing something useful - we need to put this in perspective for the AG and everyone else
• We need to understand why people hate this and what we need to do in practice going forward
• Your making me nervous - everything is about managing expectations - if we can scope out what we're doing in such a way that we are not claiming that the XML / RDF is anything like what its going to look like but we need to kick the tires
• The key is how we deliver this message
• We need to be prepared for negative feedback but is the AG and Executive Board prepared? is the public?
• The risk in this strategy is we might not get the negative feedback. If they are new to it they are going to look at it and never come back.
• Brings up publishing to whom? DDI4 is getting released to a broader community - AG position
• Do the Q1 only to the inner DDI community - contrary to position of AG
• The model has also been developed and we may want broader input to the model - maybe just put the model out for review
• How do we manage the input from DDI to other vocabularies

Attendees: Wendy, Dan S., Jeremy, Jon, Larry, Arofan

Agenda:

• New 3.3 issues
• Q1 page (comment form) - next week
• DDI4 Documentation - next week
• Achim's email

New 3.3 Issues 

• Bug DDILIFE-3502
  • ItemMap is still not usable
• Bug DDILIFE-3501
  • Fix errors in 3.3 schema found by consistency checker
• Bug DDILIFE-3500
  • ComplianceType has accidental duplication/nesting
• Bug DDILIFE-3499
  • Create a quality standard to be used with quality statements
• Bug DDILIFE-3498
  • TypeOfXXX in DevelopmentActivityType should be 0..1
• Bug DDILIFE-3497
  • Add UserAttributePairs to OtherMaterial
• Bug DDILIFE-3496
  • Allow additional context in ReferenceType
• Bug DDILIFE-3495
  • Question Item types should have a Label and Description
• Bug DDILIFE-3494
  • ProcessingEvent needs a Name, Label, and Description
• Bug DDILIFE-3493
  • Update schemaLocation of xml.xsd
  • Discussion of user specific means of doing this stuff.
  • What we don't do is have a real means of validation
  • Optionally allow reference to a thing where its structure is described in DDI - make a means of natively describing these in DDI

Kelly question response content backlog -

• I believe we've forgotten it existed
• There is no one to prioritize this AG thing what we'd like or a modelers thing of what's actually going on

Achim's email regarding distribution of release:

• Messaging on main the DDI Alliance page - needs to address the fact that the current versions are functional (don't wait for 4)
• Concerns for confusion factor, but it means we need to address it up front
• We need to show people what we've been doing for the past few years
• Arofan drafted a document on our products - sent to AG and TC and Marketing group
• Main page and community events needs to be balanced in terms of DDI products and not such a big push on DDI4
• There is not a good message regarding what to use

3.1 and 3.2 Issues:

2920 2919 3028 2930

• Proposed solution is to have a list of errata - where are we putting those errata add an errata to the page in question that links to the official standard
• a repositioning of sub-minor? Use of errata is a non-versioning change

Other

• Wendy will explore timeframes Beta Review - Final implementation check - going to publish within X weeks
• Check on DocBook production process for HTML documentation

Attendees: Wendy, Dan S., Flavio, Jeremy, Larry, Dan G., Arofan

AGENDA:

• DDI4 Q1 release issues
• TC confluence site
• DDI 3.3 additional issues - defered until next week

TC confluence site

• check that everyone has both Jira and Confluence access
• is there a means of linking an agenda to a meeting minutes

DDI4 Q1 release issues

• Look at options in JIRA for retaining Q1 unresolved issues so they can be found in the original project AND be brought forward - draft process rules
• BitBucket - need to sort out organization
  • Deliver the product through BitBucket
  • Single verioning chain in BitBucket
  • Versioning releases in BitBucket
  • Other products (DDI-C, DDI-L versions, CV, RDF products) - how will these get organized in BitBucket
• Comment and Review Site Specific Issues
  • Can we link to specific related material to a package (i.e. PDF within review) - how does it link to BitBucket - how and what do want load
  • Lets see what we can do easily for Q1 and what we want to do for future releases
• Should an UberView be published?
  • Any reasonable definition of View would say the entire library is one but is it one we publish? The discussion took place 2 Dagstuhls ago but hasn't arisen lately.
  • It makes sense that there is a requirement for bindings of the entire published library
  • Were there any issues identified for not doing it? Not really...we were just focusing on other things. Theres additional stuff we'd need to do to make this happen but it is doable.
  • Very useful a means of connecting different views and understanding the holistic model
  • Let's people mix and match without creating new views
  • In the current lifecycle we have internal and external references...what are the implications in defining views.
  • ACTION: Send strong recommendation to Modelers that we produce an UberView of the Library Packages, either in Q1 or later if it would cause a delay in terms of generating it out of Drupal XMI
  • ACTION: Send an advisory to AG, Scientific Board, and Executive Board that a technical decision has been made to publish a full Library View "UberView"
• Steps in release
  • Modelers need to deliver text that goes into the release
    • Bullet items with related materials (text, diagram, other)
    • Request also from Chairs of Views being published - run through Modelers
  • Modelers state that they are within a week, possibly 2 of usable schema output.
    • How much time will Jon need to do hand work.
  • ACTION: Talk to Jon - when should we freeze model for release
• Use time at NADDI to finalize release

NO MEETING

Attendees: Wendy, Jon, Arofan, Achim, Jeremy, Dan S., Dan G., Johan, Jeremy, Larry, Falvio, Jay

Documentation

• Is there anything obviously missing. The individual object stuff and documentation is in the library document.
• Content overall looks good.
• There is a more complete version of the design principles
• The idea of having a libraries and views needs to be in the high level
• Page 5: not currently being output in the XMI - will double check what is available and what isn't
• /xmi:XMI/uml:Model[1]/packagedElement[1]/packagedElement[1]/packagedElement[1]/@isAbstract
• What we trying to do in the implemenation section? What is it we want to describe here?  
  • How does XML differ from RDF  
  • Both focus currently on the packages not the views but we publish the views  
  • Achim will meet next week with GESIS staff regarding RDF open issues - please send any additional issues to Achim
• Collections information from
• Comments to John by 13 March
• Creative Commons non-commercial clause - what is our intent with the licensing? Should the content be reusable so the commercial use should be allowed.
• International license is now available and there is a 4.0. https://creativecommons.org/licenses/by/4.0/
• We should review this Mary. It should be applied retrospectively to reissues of earlier publications

3.3

• Change namespace to 3_3_dev (check what we've done in the past)
• Additional issues from Dan Smith(?) - enter for next meeting 19 March

Versioning in DDI4 

• Versioning of the specification we version on the class level
• The view is what people are really using
• On the one hand we have flexibility with this approach and we can version functional views
• Interoperability if we have too many versions of all of these things we have a danger
• Policy on versioning of class
• Not too many versions of a specific functional view
• For example: Functional veiw for codebook should remain fairly stable
• Rule is that a new version is not produced unless there is a community demand for it.
• Better development - multiple beta releases before finalizing a view
• What is the difference between a version of a class and a new class based on an earlier class?
• Defining extensions which would not be the same as doing a version.
• Better means of incorporating extensions into the library. Using BitBucket to file these.
• We need a structure in the model to define an extension.
• Mapping key/value pairs in a system to DDI objects which are being populated by this material
• Extensions should be made to the Model not the syntax (example of GSIM) We need instructions on how to do this in DDI
• How does this relate to the metamodel object?
• What we want is people to describe their extensions in the same expression as the model
• Nothing expressed as a key/value pair is not a condidate for extension to the model. You need to formally model the extension.
• Keep in mind that this is kind of binding specific. RDF can just be added, whereas XML needs a content area for it.
• How do we control the versioning of the library as a whole...with a version number or a release date?
• We have the UML level which is realized in XMI.
• One release could be realized as one XMI file of a specific date should contain all versions of all classes and all functional views.
• Nice from the organizational point of view but some problem relizing this in XMI and UML tools.
• Each class has a unique name and each version of a class has a unique identifier in addition of the name (classname_version). That means there are classes with the same name and with different identifers in the same file. Technically no problem but if imported to a UML tool they show up as the same class with the same name but multiple versions. Each class should have a property version of the class which would show up in the UML.
• One release has only the latest version of each class and each functional view.
• Chris Nelson pointed out you can have classes of the same name in different packages. There is no object versioning at the class level.
• A functional view references a class used in the functional view. If you have multiple releases you have multiple definitions of this class.
• Only put difs in a latest release (what changed).
• Achim will include this in the document as well.
• It would be easier to made a decision if we can see what these options may look like.
• If you are using UML tools and want to import XMI to UML tool you'd need to import multiple files which could be confusing.
• Can we decouple the UML behavior from the way we handling versioning. We need to detail the options and then look for a solution
• We could treat the XMI as a separate deliverable. Version the way we want to do it and then release an XMI as an end deliverable rather than as a canonical representation
• So then what is the canonical representation? Drupal?
• Chris tried to load the XMI in EA and was not successful (was using older version). We want some version of the XMI that is useful and importable.
• Speaking of Drupal and there is not a means of referencing a specific version of a class.
• ISSUE: Do we currently make use of all possibilities of UML for our requirements Classification limitation issues (specialization of association relationships) UML may provide means of dealing with these 1) Constraints (can be expressed without OCL, ie. natureal language or xml schema pattern) 2) UML provides "power types" which are additional attributes of associations or classes - disjoint 3) use the ID of UML profiles which are mechanisms to redefine UML metadata in a way UML tools understand it (example UML profile for XML schema constructs)
• UML is based on MOF (Meta Object Facility) a metamodel for XMI and UML etc. Lightweight extension is a UML Profile (a refinement of definitions) Heavyweight extension would require changing the MOF description - should not used
• Is UML defining "profile" in the way of ISO/IEC TR10000-1? What you do is you create a conforming implementation of a standard and then add to it. It has to conform to base UML. http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=30726 A Profile which is a subset but also a way of extension How do we do data specific constraints (sub-type associations) How much can we add to the expressivity? We can't let the bindings define what we do. The bindings have to work with whatever we define in the model.
• A profile can includes the following: Scenarios of interoperation (what you want to do in a binding) Adapting definition elements Constraints on values that can be used Customization High level information on integration etc.
• Not sure the profile stanard doesn't say what it should be in the sense of perscribing a particular syntax.
• An advantage is to specify that there is a way to put these artifacts together without adding external languages.
• Do we need a formal constraint langauge or do we need to read them from the XMI expressed in natural language and reflect it in the binding.
• I have a collection with members and when I use this in ConceptSystem need to constrain Members to Concepts. I do not indicate that collections contain members as it is never substantiated as an object so that Members are added in the instantiation.
• Hierachal or agreeing values (i.e. object X with value A is only valid if object Y has value B)
• SBVR is a means of using natural language to express formal rules. Equated designation with definition of a concept. Which is so wrong (DG)
• To have a clean model vs. to have end products that express the model
• It is important that the XML not get too complicated. We may need to provide Arofan with poetic license to express the model in XML.
• We need to look at the XML with usability in mind and the same time keep the UML as rich as possible. We then limit the complexity of the instantiation into the expression language but don't constrain the UML.
• Our model is plateform independent and could adjust to a plateform specific level change it. This may just move the problem up a level. It is more visable
• If we don't do that and go straight from model to schema and we have to document the process to retain visability on how we do binding. (not just trust the XSLT)
• The issue with the current solution is that the XSLT addresses 2 purposes drills model down to the expressiveness of the binding and at the same time generate very specific syntax solutions for the expression.
• There is a document that explains the binding rules used to create the expression.
• We need to get more practical for the next release.

Rough discussion notes only

• OWL version infor would have consequence on binding and intance level Maintenance table is just an addition means of tracking this information. Not required but useful (look up latest version of a specific class or previous version). Each class would have status information (when is it released, is it in development stage). This could be derived but the table makes it easier to use. Who are the users of a class in a Maintenance Table. ie what other class or View When there are profiles of functional views these would also be users.
• Can we derive a maintenace table which reflects the power point so we know about classes, class versions, and users of particular classes (i.e. View) - this could be generated out of Drupal this would be a justification for adding the property to the class
• Yes much of this can be derived from internal content of Drupal (which means we need to get an estimate of effort to do this) Different types of versions is a concern (Major:Minor:SubMinor) - can the UUID in Drupal capture that? Major to Minor must be entered by modeler. What may be compatable at the model level may not be compatible at the implementation level.
• Are we talking about versioning the model or the standard and its outputs? Focus in on Model and releases, not the bindings
• The situation could be a little different in the bindings. The UUID used inDrupa; os a generated. The UUID being proposed is a semantiacally constructed one which is a URI which caontains class name and versioning information. Either the version information can be derived from semantically constructed URI or from the Maintenance Table
• Use of the word "Class Library" (see last page) Specification  Class Library   Library Package (for the purpose of maintenance)  View   Thought we'd agreed Package was purely administrative and without inherent meaning. Seem to be reverting to the Oct 2013 idea. From the users point of view (developers) the library packages are unimportant It matters only for developers of the specification - could eventually becaome a "published" and "development" super packages
• Needs both a unique UUID and XML ID
• In theory the inclusion of an unchanges class in a versioned package is by reference. Different UML tools may not be able to handle this. Do we model to the lowest common denominator? A generic UML approach plus for example an xmi file in EA flavor derived by transform.
• Version information per class - only on the model description or as a property Views use specific versions of properties and classes so it needs to be able to bind directly to a specific version Nothing is immutable versions must be retained How is this maintained in Drupal? Different versions already exist but what we see in the web interface is just the latest one.
• If we go into an object we can step back through revisions.
• If we release an object at version 1.0 and then we release a version 1.1. We have to maintain the previous version. What we can't do is fork the previous version and do something with it.
• At the moment we could release a 3.1.1 but we can't release an equivilent. Archive the released versions outside of the Drupal environment. A separate published version of an object is a separate object. You should be able to assemble a version out of a lake. You can but the problem is if you want to make a change in version 3 after version 4 is created you cannot do that. We would need a policy around versioning about what can be done when. There needs to be some reasoning before for use of an older version. The big question is forking your version tree
• We need a versioning policy that does not support forking. In a model the important stuff is the semantics so a documentation change is a more signicant change. Are we trying to treat the model like software and is this a good idea? Who is the poor sod who will manage all of this stuff?
• Jeremy Iverson (to All - Entire Audience): 9:49 AM: i quite like your "we are treating the model like software" comment. quite true
• We have the links between the views and classes but there is no information between links between classes. If a class has a new version all the classes using this class need to be checked. The version of the classes effect the identify.
• There is the unique class name and a specific version. References between classes have to be early bound.
• The instances shouldn't be affected as they are published
• There is a rule of using only one version of a given object in a view.
• There needs to be two environments: published (what views are created from) and development (where changes need to be propegated)
• Versions of the views and versions of the objects are separate things.
• If I have a view it could use objects from a variety of releases. if I use a version 1 of Object A I can version the view and add a version 3 of Object B and continue to use version 1 of Object A.
• What is important of the schema perspective is versioning the views
• RULE: Only one version of an object can be used within a view. RULE: Once something is published it never goes.
• One is to create rules machine actionable (coached by the maintenance system) If you create a new view you should start fresh with newest version
• Version information as a property of each class - I think if you are going to be versioning things its kinda required. There are other standards such as UBL that embedded in the name space and changed to property (impact on software is not a bad thing)
• Procedural question: This will come up in modelers group, how do we handle communications between those 2 groups?
• Could important comments be sent by email to Achim. These will be incorporated and redistributed to TC and Modelers
• Version of the UML 2 or 1 some are supporting 2.1 Can we have a more version independent UML and xmi expression. The model would then be interoperable with a number of tools. uggth yes (Arofan)
• What is the canonical model? Right now its Drupal but we need it to be xmi.

ATTENDING: Wendy, Flavio, Jon, Jeremy, Jay, Dan G. Achim

Confluence

Versioning

URL

Internal target schedule  

• March 1 - XML schema  
• RDF use what is currently in production framework - Accompanying paper regarding issues and unrealized solutions  
• list of dates and deliverables  
• What requires handwork

RDF vocabularies  

• Dependencies:
  • Versioning topic can have an influence on the general setup
  • Technical framework on the xmi documentation
  • Documentation on Drupal and how DocBook and xmi get exported
  • Documentation merge into the XML Schema and OWL representation
• Documentation no major issues, just write it up and test details
• Versioning topic we need to think this through on updated documents
• Documentation should be part of the XML schema and OWL representations - Q1 crutial Versioning - Q1 is not a show stopper can use an intermediate XML

DDI 3.3

• no effect for versioning or URL

RDF - old

• Different URI for development and published
• Some people are already using some instances that refer to the development namespace (URI/URL) - so there could be an issue  
  • Either instances need updating or DDI needs to provide a redirect  
  • ACTION: Check with Frank regarding above    
  • ACTION: Straw poll of TC members regarding conscensus on structure

2015 Q1 release:

TC activity:

• Goal date for release: 31 March 2015
• Comment site ready: 15 March 2015  
  • This includes text content and comment capture  
• Modelers activity: (need intervening detail on mid-point functional XML and RDF, reality check of what details will and will not be available, what requires handwork and the amount of time needed for this)
• Goal date for product deliver to TC: 15 March 2015  
  • XML Schema  
  • RDF/OWL Vocabulary  
  • High level (DocBook) documentation  
  • UML Model    
• Discussion of current Modelers discussion that have implications for High Level documentation in terms of what the UML supports (and what are limitations of the implementations)  
  • Ordered relations  
  • Restrictions
• From the release point of view would be to articulate this discussion and decisions and the consequences.
• True that we don't need to be as expressive as the most expressive language but to be as expressive as we need to be to express and do what we need to do.
• The issue is how do we manage the bindings. How can programs benefit from content of the implementations that cannot be expressed.
• Constraints must be accounted for in a testable way.
• UML limitations and solutions. Also for the bindings. - request from Modelers (ACTION: Wendy relay to Arofan DONE)

MEETING on March 12 has been cancelled.

ATTENDEES: Wendy, Achim, Arofan, Dan S., Jeremy, Johan, Jon, Larry, Dan G., Jay

Access to Atlassian Tools

• TC was asked to draft this and I have attached both the draft of the document I was working on and one that Achim sent to the Moving Forward AG yesterday. There was also a call of Mary, Kelly and I last week and the results were incorporated into the TC draft. We should probably try to reconcile these.
• John Shepardson's response
  • User accounts/Administration
  • Admin group or topic in JIRA - dispersed is better
  • Email list is not offered within Atlassian
  • Bitbucket is separate
  • Google groups
• Arofan
  • What goes in JIRA and what goes in Confluence
  • Haven't settled what gets used
  • Need profiles for use
• Dan G.
  • Need to layout and identify what both confluence and JIRA are being used for
• Achim
  • JIRA used for technical issue tracking
  • BitBucket is subversion we need to know how to link these
• Until we have guidelines of how to use these systems in the short, middle and long term it is difficult to proceed 
• Clarify for users - login, connection to email system
• Templates, rules, what-to-do and how-to-do - Could Kelly work on these (Wendy talk to Mary about this)
• Achim pull these together (ACTION)

Versioning (documents)

• See minutes from 201405
• See Versioning DDI 4ever.pptx and Versioning DDI 4ever.docx
• Should this impact how we manage the library
•  A version should be documented and be a property of the object
•  Forward to modeler at this point and focus on specific areas within TC
•  Seems it isn't just for modelers as it is something for everyone that will use the model
•  Need to elevate into our communications - high level documentation
•  ACTION: (Achim) Will update documents and will send to both groups put on next weeks agenda
• RDF publication - this has been an outstanding item for several weeks. What do we need to do to get this moving

 URL - first need the rest of the versioning discussion cleared up

•  FROM LAST WEEK:
  •  No decision made, options were raised
  •  Achim will update document and clarify the options
  •  First discuss versioning in modeling group version and naming
  •  RDF vocabularies will be discussed with the RDF guys for input
  •  Need additional input. Need decision on RDF prior to RDF publication other has longer time frame. SKOS format for CV also needs clarification.

Current discussion

• Access to Atlassian Tools
  • TC was asked to draft this and I have attached both the draft of the document I was working on and one that Achim sent to the Moving Forward AG yesterday. There was also a call of Mary, Kelly and I last week and the results were incorporated into the TC draft. We should probably try to reconcile these.
• RDF publication - this has been an outstanding item for several weeks. What do we need to do to get this moving

2) URL - first need the rest of the versioning discussion cleared up
 FROM LAST WEEK:

•  No decision made, options were raised
•  Achim will update document and clarify the options
•  First discuss versioning in modeling group version and naming
•  RDF vocabularies will be discussed with the RDF guys for input
•  Need additional input. Need decision on RDF prior to RDF publication other has longer time frame. SKOS format for CV also needs clarification.

Current discussion

• URLs needs to talk to RDF guys.
• Few documentation issues regarding DISCO and alignments
• Trying to finalize in March
• Jay is working with Census and they are very interested in DISCO

Documentation 

• No cycles from Olof so in terms of XMI output is limited to what we have now - do some things by hand (PDF) HTML
• Does Jannik have some time to help on this
• Hand work will require a free-up of time -

High level start with the basics and iterate (Jon):

• Versioning
• Identification
• Collection - Grouping
• Library Package
• Views
• Implantations (XML and RDF and UML)
• Name, Label, Description, Definition
• Administrative information
• Strings and how they work

We don't have a mechanism for getting the production done - what are the dates (timelines)
Internal target schedule

• March 1 - XML schema
• RDF use what is currently in production framework - Accompanying paper regarding issues and unrealized solutions
• list of dates and deliverables
• What requires handwork

ATTENDEES: Wendy, Arfoan, Larry, Achim, Dan G, Dan S., Johan, Jon, Jeremy

AGENDA:
1) Documentation - tracking issue (JIRA and GitHub) how do we use these effectively to limit confusion and provide some triage

• The documentation is an integral part of the model so the issues
• High level documentation within Drupal
• Documentation issues driven by change in model and others driven by reviewer request
• To Do list for each team
• What we're going to do long term and what over the next few weeks
• High level documentation in Drupal is not a short term issue
• Formal migration from GitHub to JIRA - we need to manage this shift carefully
• Use a release as the exchange point.

2) URL - first need the rest of the versioning discussion cleared up
 FROM LAST WEEK:

•  No decision made, options were raised
•  Achim will update document and clarify the options
•  First discuss versioning in modeling group version and naming
•  RDF vocabularies will be discussed with the RDF guys for input
•  Need additional input. Need decision on RDF prior to RDF publication other has longer time frame. SKOS format for CV also needs clarification.

2a) Versioning

• • DDI 4 ever and functional views
  • What does versioning mean in terms of the releases
  • Started in Vancouver with Views
    • We considered incremental releases
    • What is the practical reality
    • How we can include the version in the reference of the object
    • Is the name of an object its unique identifier - separate from its version inside Drupal
    • When you publish a version of View it would contain specific version - how do you represent that to user - you can record it but can you lock it
  • What do we really want to do?
  • What is the user perspective?
  • Then realize in Drupal and XMI
• If you are looking at a view as someone who is designing it, it should be clear which version of the objects are in the view as they are persistant. (This needs to be surfaced in Drupal i.e. capture version 1 and this should occur on PUBLISH)
• From user perspective how do we express its component parts? Is it a build issue or is it an  "at publication"
• If you have an object and its versioned and it appears in a view. A different version can appear in a different view.
• The requirement is for example for exchanging a Codebook View. Two parties agree on a specific version of Codebook View. Even when a new verion comes out they can continue to use the older view as it still exists.
• What is the difference between a Version change and an extension. Most important thing for the user is that version 2 is always version 2 and that if there is a change then its a different version.
• The library contains a large number of versions of objects. If we use the Drupal versioning then you can't differentiate major/minor (all changes are equal).
• What UML and XMI is offering is a universal ID for an object which is maintained in a package that can be versioned. We could use both pieces of information (package and object). The Universal identifier for version 1 would be different that version 2.
• We need to design what we need to express object level versioning.
• Specialized fields creates an issue about wanting to create a standard notation so you can use different tools.
• When I implement a view I care. I don't have to manage a library in a UML tool but in XMI.
• Need to diagram these relationships to clarify this for everyone.
• ACHIM will diagram and explore the possibilities of XMI and summarize the basis of next step
• Requirement: A functional view should reference a specific version of objects used in the view

3) TC presence on Wiki (DDI Governance)

• Where do we want to track things? JIRA for standards development issues
• General tasks: reviewing, writing up a statement draft, etc.
  •  For topics which could benefit from email comments etc could be migrated to JIRA
  •  For topics which need more exploring discussion probably not
• Goal is not only to see if something is done but to let outside people know what we are currently doing
• Members...We have a huge overlap with Modelers. My feeling is that these people (plus others from the modelers group become regular TC members. Note that meeting attendence will vary depending on topic with the expectation that a small core group will try to attend all meetings but others will call in only on specific topic areas
• Question about on-going "tools" group that manages the implementation tools for generating the model, documentation, RDF and XML. They should be listed as TC members but with a specialized activity role?
• Whatever we do should be visable not in the core group so there is not as much of a problem

Main page should have greater possibilities

• Sub-areas for each major area
  • Governance
  • Executive Committee
  • Scientific Committee
  • Working Group
  • TC
• The paths should be accessible from different perspectives not just the through the governance structure.

ATTENDEES: Wendy, Arfoan, Jay, Larry, Achim, Dan G, Dan S., Johan, Jon, Flavio

AGENDA:

1) Text items for review pages

2) URL's for specifications  

• No decision made, options were raised  
• Achim will update document and clarify the options  
• First discuss versioning in modeling group version and naming  
• RDF vocabularies will be discussed with the RDF guys for input  
• Need additional input. Need decision on RDF prior to RDF publication other has longer time frame. SKOS format for CV also needs clarification.

3) Documentation/Drupal "wish list"

4) Access to Atlassian tools - Policy draft  

• TC has been asked to draft this policy    
• TC and Modelers need access to JIRA and Confluence  
• Separation JIRA access and Confluence which would wider (definately sprint/group participants)  
• Confluence access for Scientific Committee - what level of access   
  • Add comments but not edit   
  • What are the roles people play?   
  • A new kind of committee/special interest group - what is the access for non-members but involved      
  • Define roles and then identify groups of people who belong to these roles  

Attendees: Wendy, Achim, Flavio, Dan G., Jay, Johan, Jon, larry

General access question:  Who currently has login access to Atlassian products? Is there an overall management for how this is handled going forward?

ACTION: Wendy - Check with John and AG

Agenda:

1) Review Pages - structure and content  

• overall no issues not noted below

2) Form interface  

• review options for customization of JIRA issue content and form. Primarily a more specific means of capturing line number, object name, etc. to support searching  
• need to balance conformance to support searching and ease of entry

3) Specific issues:  

• New term for Burndown   
  • changed to Coverage - link needs text associated with it that explains what this is: purpose is to replicate functionality, what moved (with editing), what was replaced
• Content for  First page of DDI4-Review pages.ppt:   
  • Brief statement of what this is and how it is organized    
    • Wendy will draft something for next week   
  • Instructions for submitting a comment    
    • Wendy will draft something for next week   
  • Identify documents to link to: (X are kept up to date by owners)    
    • X The Role of Technical Committee in the Review Process   
    • X Release Plan https://dditools.atlassian.net/wiki/display/DDI4/Project+Management    
    • X Communication Document for Content Modelers https://dditools.atlassian.net/wiki/download/attachments/2588861/Communications%20Document%20Modelling%20DDI%204.docx?version=3&modificationDate=1418822733373&api=v2    
    • Glossary https://dditools.atlassian.net/wiki/display/DDI4/Glossary    
    • Process for DDI 4 Development Project https://dditools.atlassian.net/wiki/display/DDI4/DDI+4+Process    
    • Design Principles https://dditools.atlassian.net/wiki/display/DDI4/Design+Principles    
    • DDI Moving Forward Project: Structure of DDI 4 and the process to create it https://dditools.atlassian.net/wiki/display/DDI4/Structure+of+DDI+4    
    • Roadmap Production Process https://dditools.atlassian.net/wiki/display/DDI4/Roadmap+Production+Process

• • • We need to review/edit directly or create new updated documents (Wendy- ask AG about editing)    
    • This will be an ongoing issue (manage expectations) make sure there is a blurb noting the historical nature of some of these documents    
    • Jon will review last 5 and get back with edits by next week     

• Contact information: do we want to create a specific mail box or list    
  • Decision to refer to TC list and/or wendy (some people are adverse to asking questions to a list)

• Content for  Second page of DDI4-Review pages.ppt:   
  • Can there be custom fields in Jira as well as the form, May not want to overuse the custom features. some instructions on how to handle comments on various types of objects   
  • Wendy will reveiw JIRA documentation and report back  
• Review Instructions   
  • Wendy will draft something for next week  
• Identify documents to link to   
  • Request this from Modelers and Content groups for published Library Packages and Views  
• Content coverage list   
  • Wendy will draft something for next week

Agenda additions:

Review Instruction Notes:  

• If we lay out too many options we'll end up confusing people  
• How to read documentation, its a draft where any and all changes can be considered  
• Keep it general - organize a session at IASSIST if we are not getting good results - something to keep in mind about in the margins of the conference

Specific publication issues:

• URL's for specifications: Achim will pull together information and put on next weeks agenda  
• How to do this with DDI 4 (representation formats and views)  
• RDF vocabularies URL scheme and how those mesh

Specific documentation issues:  

• documentation paths for each object - lion and html output  
• were there decisions? what is displayed when you are not in edit? what gets into the XMI  
• Can we get this list together regarding documentation and up on Modeler subpage for documentation  
• Jon will pull together his Drupal "wish list" and will work with Wendy to set up a page linked to the modelers page to track the items and their status

Next weeks agenda:

• Text items for review pages
• URL's for specificaitons
• Documentation/Drupal "wish list"

Attendees: Wendy, Arofan, Johan, Jeremy, Dan S., Dan G., Flavio. Larry, Jay

1) Publication of RDF Vocabularies

•  Deliverables of specification: document and vocabularies
•  Issue about attribution - has this been solved? check with Achim (Richard and Franck regarding)
•  W3C blessing / review has this been accomplished?
•  Follow up with Franck (XKOS) and Achim (Disco and Physical data description)
•  Where does it live? We need to have this discussion

2) Instructions for review (draft document coming)

•  Imbed line numbers (see notes from previous meetings)
•  See "DDI-Review pages.pptx"
•  Form could include a topical classification - to track where we are or are not getting comments - probably not useful
•  Information on levels of review should go at main page, release page, plus in the email
•  How is commenting on a schema different from a document? Documents, XML, Turtle (no real rule for lines) Line numbers
•  Style (of XML, RDF, Documentation) or specific (open in a text editor or something that provides line numbers and use for comment)
•  Provide object name and parent File Object Relationship or Property - line number from documentation

3) Follow-up on last week review of Jon's documentation sample (any additional suggestions?)

•  Wasn't completely happy with package and view level content
•  There will be a High level document
•  UML diagrams problem - Olof came up with a means of resigning the output of the UML broad plus object level diagrams

4) Additional comments:

•  Resourcing production framework - ammunition for addressing the long-term problem
•  Is XMI part of the release? as a workable input to EA...talk to Achim - should be part of the release
•  EA reviewers and those that only looked at the spec
•  Images are out as SVG files and could be made available

Agenda for next week

Carry on with review pages - text blurbs
Form interface  

Questions for Modelers:

What is in Conceptual? where do representations and collections fall?
Binding and In Out issues - can I fix these?
Decision on XHTML in structured string -

COMMENT FORMAT ISSUES:

Uniquely identifies whatever it is that they are commenting on
 Line numbers in documentation
 Standard way of referencing document
 XML and RDF object name - check with others on how its writen out (subject|predicate|object) (xsd can have line numbers)
 Model - graphical representation (any graphical representation is an informative artifact - normative and informative documentation
  normative - what you need to know to conform to a standard
  informative - explanitory, goes along with what your doing but doesn't give requirements
  everything you ask people to comment on/review is always going to be text so line numbers always apply
 Archive old issues until a release and then have final  

Is it possible to put every single one of the Drupal
 The views only borrow from the fundamental model
 Comments on objects should refer to the Library Document
 Views are focused on the selection of items
 
What do we want reviewed?
 View - all that matters what the view says overall and what the objects that are used say - does the view make sense does it have the correct objects and relationships
 Library - really look at the modeling, structural and migration issues - line numbers of library document
 
-Broadly people focus on the model and the library whereas the views utility as a composit (not too big, not too small, functionality)
-We've been working for a year, we want a sanity check, we need input on the overall approach and answering are we going in the right direction
-Design rules - are they right and are they being followed
-Transparency and early input
-How do we approach review of the Library that makes sense and is doable? How do we put constraints so we can ask reasonbable questions of people?
-Comparing conceptual to GSIM - we can only see this through the view - but we don't have views on this - we need package level descriptions of why we did what we did, what problems are being addressed, what community is it serving
-Library organization - if its not a UML package, what is it?
-What sort of thing do you think people could effectively comment on? If the objects are in a UML diagram that can be presented informationally that people can see. If they don't exist within a diagram that has a clear usage its would be difficult.
-How do we form the questions for review - what is the core?

To get Jay to write 250 words max on what we're trying to do with Process Core. Identify who should write 250 words on what we're trying to do with packages.

Multiple comment collection forms?

Self catagorize what they are doing - or we can catorize it
Can we tag the collection form - yes

http://www.britannica.com/EBchecked/topic/618178/universe
http://www.britannica.com/EBchecked/topic/470303/population

Discussion of the alignment of DDI 4 releases for the purpose of making a revision proposal to the Moving Forward AG
https://dditools.atlassian.net/wiki/display/DDI4/Project+Management

Timing and what things were in the second release

Add DDIResource could be moved to Core Process so it is available and then expand Discovery View
Help define the notion that a View is nto the same as a package

Expansion of Discovery View
Are these both Library and View?
Defintately the Library
How do you extent a view without access to the process to generate the vocabulary (XML or RDF) to create the view

A view is a refined set/grouping of relationships and entities.

Classification View YES
Simple Instrument View? plus any related package materials Data Capture (Library) plus Simple Data Capture View
Simple Data Description View? There is not currently a view...would need to be created
 there is a scheduling issue here; they are continuing to work on this
 what was done at Dagstuhl could be published - any questions can be resolved by virtual meetings
Add an updated Discovery View
Add non-core process could probably made ready prior to the IASSIST Sprint (if available)
Stages and drafts rather than "versions"

Working Draft to Draft Standard (BETA) to Edition 1 (community is used to version numbers)

Recommend that the AG review the back log and look at priorities again

**************************************************************

TC work items coming out of EDDI Sprint
https://dditools.atlassian.net/wiki/display/DDI4/Sprint+Agenda
LS-84
LS-31
LS-2

https://dditools.atlassian.net/wiki/display/DDI4/Checklist+for+Q1-2015+Release
Set up new project
Page to enter comments - talk to John Shephardson about this 
Instructions (general)
List of specific issues to focus review

JIRA/Confluence update and discussion of TC presence

DDI 3.3 coverage and time line

      P ID #  Category Severity Status Updated Summary
  
 Update Issue   0000634   Documentation, field level minor new 10-22-14 Processing Instruction Reference documentation error
 
 Documentation reads:
  A reference to a General or Generation Instruction that was used by the parent object, e.g. an instruction used to derive a Variable or used by a ProcessingEvent. The basic Reference structure is extended to allow for the use of Binding to link specific source parameters to the InParameter of the instruction at the point of use. TypeOfObject should be set to ProcessingInstruction.
CHANGE last sentence to:
 TypeOfObject should be set to GeneralInstruction or GenerationInstruction.

 Update Issue   0000633   !Schema minor new 10-13-14 URN regular expression improvement
The regular expressions of both, CanonicalURNType and DeprecatedURNType, allow that an agency id can be just a string without a dot, which could be - for example - just a country code. This wouldn't be allowed by the agency id registry process, but it should be detected by validation.
Change regex in CanonicalURNType and DeprecatedURNType:

 from
 [a-zA-Z0-9\-]{1,63}(\.[a-zA-Z0-9\-]{1,63})*
 to
 [a-zA-Z0-9\-]{1,63}(\.[a-zA-Z0-9\-]{1,63})+

 i.e. the cardinality of the additional sections of the agency id is 1..n (not 0..n)

 Update Issue   0000623 2 !Schema minor new 09-25-14 Revision of DDIProfile to support recursion within Used
Proposed adoption of the ABS extension which supports recursive content (Used and NotUsed) within the object UsedType.

 The addition of a recursive Used element allows the specifier the be unambiguous as to what elements/attributes are used and not used in the scenario where the outer element is optional and an inner element/attribute of the outer element is mandatory.

 The path of the used not used statement need not specify the complete path for element/attribute it could be build up programmatically by appending the parent used path.
 This would make the process of building the profiles considerably simpler and you only need to make sure that the name of the current element/attribute is correct not the entire path for every path statement in the profile.

 Note that the attached documents also include a new attribute in Used "limitMaxOccurs" which has already been added to 3.2 (ABS uses 3.1)
 
My impression is that manual work should be minimized by the suggested solution.

 A recursion is often error prone because it is often not clear and it is more complicated to handle by a program.

 DDI 3 and also the profiles are intended to be written by programs. Therefore I don't see really the advantage of the proposed solution.

 An example of a DDI profile would be helpful to see what should be achieved. A basic version without suggested solution and a version with, to see the difference and possible advantages/disadvantages.
 
 Update Issue   0000630 1 !Schema minor new 09-25-14 New extended dcterms.xsd has been issued
We are still using the 2003 version of dcterms.xsd in the publication packages which limits us to objects existing at that time due to our inclusion of the xsd in the distribution package and use of a local schema location in import.
Continue to provide a local copy and update the xsd. Review the namespace declarations for support of dc and dcterms. ATTACHMENT dcterms.xsd

 Update Issue   0000625   Documentation, field level minor resolved 09-25-14 Name, Label, and Description in ControlConstructType documentation wording error
The documentation in standard items in ControlConstructType refer to ConstrolConstructScheme.
Correct field level documentation at next sub-minor edition. We should have a list of noted errata for field level documentation as well as manual level documentation.
 i.e. A description of the content and purpose of the ControlConstructScheme
 
 Update Issue   0000624 2 !Schema minor resolved 09-25-14 Orphan element in reusable
 
    <xs:element name="ComponentParts" type="ComponentPartsType">
         <xs:annotation>
             <xs:documentation>A stack of LocationValueReferences to each of the locations of the specified PrimaryComponentLevel type that make up the Component Area. Includes a GeographicTime to allow for repetition for change over time.</xs:documentation>
         </xs:annotation>
     </xs:element>

     <xs:complexType name="ComponentPartsType">
         <xs:annotation>
             <xs:documentation>A stack of LocationValueReferences to each of the locations of the specified PrimaryComponentLevel type that make up the Component Area. Includes a GeographicTime to allow for repetition for change over time.</xs:documentation>
         </xs:annotation>
         <xs:sequence>
             <xs:element ref="LocationValueReference" minOccurs="0">
                 <xs:annotation>
                     <xs:documentation>Reference to the LocationValue of a basic building block of the composite area.</xs:documentation>
                 </xs:annotation>
             </xs:element>
             <xs:element ref="GeographicTime" minOccurs="0">
                 <xs:annotation>
                     <xs:documentation>The time period for which the LocationValues listed are a valid set.</xs:documentation>
                 </xs:annotation>
             </xs:element>
         </xs:sequence>
     </xs:complexType>

Verified this is NOT an orphan. See following from what was supposed to have been added with 521. It was either missed or a later replacement of the parent object removed it in error.

 ADD to GeographicLocation/LocationValue following DefiningCharacteristic

                     <xs:element ref="ComponentParts" minOccurs="0" maxOccurs="unbounded">
                          <xs:annotation>
                              <xs:documentation>A stack of LocationValueReferences to each of the locations of the specified PrimaryCompnentLevel type that make up the Component Area. Includes a GeographicTime to allow for repetition for change over time.</xs:documentation>
                          </xs:annotation>
                      </xs:element>
 Update Issue   0000632   !Schema minor new 09-25-14 Statistic is a decimal and does not allow for very large numbers
  There are occasions when the result of the statistic is a very large number requiring an xs:double 
Provide a StatisticDouble choice where a StatisticDoubleType is the same as a StatisticType except using xs:double as the extension base.

DDILIFE-1702 - Use of term StructuredString in field level documentation. Change to reflect support for multiple languages and XHTML structured content.

Attendees: Wendy, Larry, Achim, Dan, Flavio, Jay, Jeremy, Jon

Draft of TC role in review
Jay: proposal for addition to process model which could be part of what is needed for the first delivery -

Draft role review:
ISSUE 1:
Do we need more comment about MySequel
 More than one way to do this therefore putting out a "DDI" implies a single way
 Technical issues
 Policy issues
Can we provide the technical framework in a configurable way for a program library to be used to generate sequel statements (not as a product) and let the community deal with it?
Isn't this "single way" also an issue of XML and RDF?
XML has two purposes (preservation and exchange)
Sequal is needed for management as most people manage content in a data base
There are tools that can generate this from the UML

This should be brought to the Scientific Board for long term product/output base

With 3.2 we came up with over 1000 tables so perhaps a view approach would be better in terms of restricting complexity
Best practices / guidelines

Cons:
We're resource bound
Problem of plateform indepence - can Sequal ever be plateform independent? The data definition language used to describe the schema is definately plateform dependent

ISSUE 2:
Assumptions and procedures in the comment and comment
We need a game plan for the comment resolution process and transparancy
There are some ISO directives that address this - can we get from ISO web site (we can learn from them)
NEED:
 Template for comments
 Well defined comment period and stages of development (draft, finalization of technical, final editorial stage)
 Rules about the human management

How to identify in a general way a pointer within a top level object (document line numbers)

Dan is working on a document for AG and will send out

*******************

See the lists in EPIC 1 and 3 (and any others) in the London Sprint for any that we need to chime in on as the TC

https://dditools.atlassian.net/wiki/display/DDI4/London+Sprint

Jay: proposal for addition to process model which could be part of what is needed for the first delivery -

Move to JIRA

https://dditools.atlassian.net/browse/DDILIFE-1699?jql=project%20%3D%20DDILIFE

Any outstanding collection questions -- examples

******************

DataCollection 3.3Beta - incorporate all the new objects into this

wlt: remove write access to mantis for all

1) Final package for review (DDI 4 package 1)

How are people going to review so that people can easily attach their comments.

make sure all materials are there and findable

is there a list of what involved in a package for review - Toronto, Vancouver or presentations at NADDI or IASSIST

a report card - more or less mature - a grad in terms of its status and maturity

ready to be used in prototype
parity with current content
burn down charts of 3.2 coverage - check on how people are moving over drupal objects so that those can be generated
GSIM coverage - programatically created from Drupal

once we do the review - how do we freeze something in Drupal

are there drawings which capture some of this process -
there are a bunch of technical issues

pull together these discussions and documents for consistency or change in approch over time -

I went through the convergence site and here are the relevant documents with links that we should review in outlining the TC review process and review package release. I have not gone into the minutes of the sprints. Can we all try to look through what we can of these and try to condense and consolidate along the lines discussed at todays meeting? Please share your ideas to the list (plus added players).

[raised in TC calling this a Core Review rather than a "Public Review" which implies in the past that this was material almost ready for production level use. This is material as well as package structure that is being reviewed. The title has to very much imply that this is a step in the process and that progress has been made. Core Package Review was suggested. We want to focus the review up front: specific content, style of RDF, XML, Documentation, relationship to GSIM objects.]

X Wendy email MFAG
X Arofan write up the recommendation on production support for TC review

Wendy write up Agreed checklist draft

Thanks, Wendy (also in the attached text file)

What I found trolling through the Moving Forward Project site...

In DDI 4 Documents:
General working process (v.03 2014-04-28)
http://www1.unece.org/stat/platform/display/DDI4/DDI+4+Process
Design Principles (2014-04-16)
http://www1.unece.org/stat/platform/display/DDI4/Design+Principles
Report to Modelers (2014-07-30)
http://www1.unece.org/stat/platform/display/DDI4/Report+to+Modelers
Roadmap production process (2014-05-30)
http://www1.unece.org/stat/platform/display/DDI4/Roadmap+Production+Process
Structure of DDI 4 (2014-04-14)
http://www1.unece.org/stat/platform/display/DDI4/Structure+of+DDI+4
Glossary  (2014-04-11)
http://www1.unece.org/stat/platform/display/DDI4/Glossary
Identification  (2014-04-09)
http://www1.unece.org/stat/platform/display/DDI4/Identification
Drupal Conventions updated (2014-07-30)
http://www1.unece.org/stat/platform/display/DDI4/Drupal+Conventions+updated
Relating to other standards (2014-07-30)
http://www1.unece.org/stat/platform/display/DDI4/Relating+to+other+standards
Guidence for relevant standards (2014-07-30)
http://www1.unece.org/stat/platform/display/DDI4/Guidance+for+relevant+standards
has link
http://www1.unece.org/stat/platform/download/attachments/100303224/Relevant-standards-v3.odt?version=1&modificationDate=1401479164039&api=v2
Relevant standards guidence
http://www1.unece.org/stat/platform/display/DDI4/Relevant+standards+guidance
There are word documents from each day of the Vancouver Sprint at the bottom of this page (I have not reviewed for relevence)
http://www1.unece.org/stat/platform/display/DDI4/Vancouver+Sprint
There a page with documents distributed at Toronto Sprint at the bottom of this page as well as internal links (I have not reviewed for relevence)
http://www1.unece.org/stat/platform/display/DDI4/Toronto+Sprint
Modelers meeting notes [see particularly TC modeling related meeting notes at end of list
http://www1.unece.org/stat/platform/display/DDI4/Modelling+Team+Meeting+Minutes#expand-TCMeetingof20140612regardingModelingIssues

2) Discussion of issue tracking options

There are various approaches - via a 'feedback' component within the DDI4 bug tracking project (so you can easily view the feedback/non-feedback related issues) or a separate feedback project spring to mind at present. Latter approach allows community to create feedback issues, whilst restricting bug raising to developers group for instance. Former would work best if we put a web page up for community to add feedback that gets turned in  to JIRA issues in background.

If you look at http://ukdataservice.ac.uk/help/get-in-touch.aspx, there are a number of topics, each of which has a different template but each of which creates an issue directly in JIRA for our User Support team to deal with.

Behind the scenes, we use the JIRA REST API to achieve this, which is also available in the OnDemand version (https://developer.atlassian.com/display/JIRADEV/JIRA+REST+APIs).

Clearly if its in a database we can a report and get information back. We don't want to mix production issues with development issues
Do each round as a separate project.
Template entry for ease of use
If its important
Do we have time to migrate from GitHub - or is this better to do after EDDI but before we send out the package
What are the requirements for Drupal backup in terms of moving platforms
Be able to run a report after we've disposed that show the dispostions and organize all the comments together

How are people going to review so that people can easily attach their comments.

You could let the tools development group continue to work in the GitHub environment as an independent tools development
What that means in terms of production related tools is still open. It could work just as well. Need a Tools Support Team. Can TC have a sub-committee that is Tools Support (sister or child) check the legalities.

Lets think about what we do about setting up a tools support team. Is this a coordination

We should discuss more fully in TC and then email to Mary, Adam, Steve that we need to continue the tools support past the project. What is the coverage of such a group. Meeting the requirements that come out of TC to meeting production needs. Tools maintenance for creating binding and to continue the model development.

find the document with roles: Document, production
Production Framework

XWendy write up TC requirements send to AG and John S.

3) DDI 3.x sampling, weighting, questionnaire development, bugs

In Attendance:  Wendy Thomas (organizer), Johan Fihn, Jay Greenfield, Jeremy Iverson, Flavio Rizzolo, Dan Smith, Achim Wackerow

Secretary: Elise Dunham

AGENDA

The overall production process for preparing packages for public review for DDI 4 includes a TC Review. We need to flesh out what this means.

1. With so many of us on the modelers team there should be no modeling or consistency surprises so what are we reviewing? That is, are we looking at the content in terms of its being complete or for quality?

2. My assumption is that we will be pulling together the package for distribution. Do we have a review "check list" for what goes out in the package for review?

3. Is there a list of what should go in the review announcement dependent upon the content of the package? (i.e. specific sections we want them to beat on, summary of what it is intended to be able to do/cover)

4. We need to be clear on what we expect to receive for the purpose of the TC review. What would this include?

ACTIONS

Wendy

• Find and distribute list of what goes out in the package for review that was noted in a document from either the Toronto or Vancouver meeting

• Find and distribute documents/notes relevant to package governance/workflow discussion

All

• Review documents Wendy distributes relevant  to review package release and the TC review process

DISCUSSION

By the time modeling/content work gets to TC, many TC members will have seen or worked on the material, so there should be no surprises. This means we need to identify what our role in the review process is from the TC-specific perspective.

TC’s Review Responsibilities in Moving Forward Project:

• Review for adherence to TC-produced guidelines and position papers and Design Principles

  • Method: checklist and report that documents reasoning behind decisions to adhere to TC guidelines or not

• Create/maintain burn down chart to track status/progress. Perhaps this would live on the Convergent site and get periodically updated.

Package for review (to be compared to list developed at either Toronto or Vancouver meeting):

• Overview of specific things we want reviewers to look at

• Clear indication of what the review release covers/is supposed to be able to do

• Warning that the review release should not be relied upon for production

• Model

  • .xmi file

  • Enterprise Architect file (?)

• Representation

  • XML schema

  • RDF/OWL

• High-level document to explain the overall approach

• Field-level documentation

  • Drupal

  • DocBook

  • HTML/PDF

• TC Review report

• Possible mappings between model and representation/specific solutions

• UML diagrams representing classes and their neighbors

Unresolved: Once we review and approve something, how do we freeze it/govern updates? Do we need to seal the package? What is the workflow/approval process? This discussion has happened at different times, and perhaps some of it is in the Vancouver report. There was no resolution. TC will review the documents and see if they need to be updated, if they are consistent, to get a sense of where we are, and develop a coherent document.

In Attendance: Wendy Thomas (organizer), Johan Fihn, Dan Gillman, Larry Hoyle, Jeremy Iverson, Jon Johnson, Flavio Rizzolo, Dan Smith

AGENDA

DDI Moving Forward: Collections-modeling classification hierarchies

• Discuss materials sent over the past week, i.e. Flavio’s on modeling classification hierarchy using ordered relations and Johan’s on ELSST

DISCUSSION

Modeling classification hierarchy using ordered relations

• This approach will require that we define some constraints to ensure that people will build classifications in the right way.

• What if a violation of one or more of these constraints is necessary/preferable from a business point of view?

  • We need to do some analysis to distinguish between what’s really part of the definition of a classification scheme and things that are optional.

• Classification-wise, there are some situations where this would be overkill. Are we creating one structure and instructing people to take what they need from it, or are there simplified versions?

  • We want building blocks, generic structures, that you can put together to build more complex structures. Perhaps a classification is something that we would define based on these building blocks. The important thing is that classifications, etc., will be built on the same building blocks. Users may not even have to know that they exist.

• Does the ordered relations approach to classification hierarchy satisfy the needs of ELSST representation?

  • Yes: we can use classification maps to handle flexible group memberships/synonyms.

• How does this approach work in UML, specifically in regards to the question of ordering a set depending on whether or not the contents are unique? Do we support nesting and partial ordering to handle groups of groups?

  • They’re equivalent conceptually, so it’s hard to determine how we would choose. We can support both. This is potentially problematic because it introduces interoperability issues, but there are transformations procedures in place to change nesting into ordered sets.

• Are we at a point where someone can draft this up so we can test it out on various use cases? UML and supporting documentation (the documentation doesn’t have to be at a point where it would be ready for use outside this group).

  • Yes, Flavio will work on it over the next few weeks.

NEXT WEEK’S AGENDA

Regular TC: SDI, 3.2 documentation

In Attendance: Wendy Thomas (organizer), Johan Fihn, Arofan Gregory, Jeremy Iverson, Jon Johnson, Dan Smith

Secretary: Elise Dunham

AGENDA

Does anything else need TC’s attention on the Moving Forward project?

SDI

3.2 Documentation

DISCUSSION

TC + Moving Forward

• After we finish work on grouping mechanisms, we will have completed our original set of Moving Forward tasks.

• Do we inform modelers that we are looking for other Moving Forward work, wait for their instruction, or jump in?

• Decision: We are here if the modelers need us, but we won’t actively seek out more Moving Forward work.

SDI

• SDI work has been on TC’s agenda since 2010

• The SDI working group put a lot of effort into this, and it is essentially ready to go

• Many institutions & organizations want this in DDI, including but not limited to ABS and AAPOR

• Group agrees on this approach: E-mail will come from Wendy to Mary and the Scientific Board saying the following:

  • We have SDI work in hand

  • We will review it for consistency with 3.2

  • We will fix 3.2 bugs and release it as a beta

  • Raise the issue of whether this should go out as an official 3.3 release; leave that decision to the Scientific Board

3.2 Documentation

• First priority: high-level documentation. Plan is to get drafts out in September

• Second priority: updated examples for the DDI site

  • Create list of what use cases we hope to get

  • Solicit from specific individuals

  • Where possible, match up to what people are working on

  • Dan had planned to make some examples for 3.2 for quite a few content areas; he will outline the areas he’s working on and share with group

  • Arofan knows that Eurostat just finished a DDI project; he will talk to them

  • Jon & colleagues have been working on transferring paper questionnaires to 3.2 and are already writing something up; could tie that in

  • Wendy has an example she’s been using for an ABS workshop (Australian Longitudinal Study of Aging)

  • Also should think about tools—Sledgehammer & Colectica’s—and see if anyone wants to play with those

• DDI website

  • There have been issues with links

  • Achim has taken care of existing issues. He did standard HTML, some other versions, and made the HTML ones a part of the distribution package

  • Plan is to replace packages and add a note saying there was a minor revision in HTML documentation only. Note on what’s been changed will also go out to DDI lists.

Discussed document on Grouping (Collections)

In Attendance: Wendy Thomas (organizer), Jay Greenfield, Jeremy Iverson, Dan Smith

DDI Moving Forward

AGENDA:

What objects are referenced?

    - What class of objects are identified, managed, and require a set of "management" information (name, definition, description..)

    - What class of objects are traditionally "referenced" objects

    - What other class of objects need to have identifiers

Administrative metadata - spreadsheet distributed last week

    - name vs userID - further discussion on the relationship and naming of these two objects

Decisions

Guidelines for What Objects are Referenced

If it makes sense as an object on its own, not just as a property of its ownership

If it’s something that is managed over time (this is a clear indicator that it would get a standard set of elements)

If there are other items that make a reference to it

Modelers should document the reasoning behind other factors that influence decisions to make an object reference-able

Administrative Metadata

Wendy, Dan, and Jay reviewed and discussed Administrative Metadata spreadsheet in detail and made decisions regarding whether objects should be kept or dropped. Wendy annotated the spreadsheet as the group finalized their decisions. Wendy will write a preface piece to this annotated document and pass it along to the modelers group.

In Attendance: Wendy Thomas (organizer), Guillaume Duffes, Silvia Fraustro, Larry Hoyle, Jeremy Iverson, Dan Smith, Achim Wackerow

Secretary: Elise Dunham

Action

Wendy: Draft document outlining TC’s current consensus on Name, Label, Description

Discussion

Summary:

• We know that it makes sense to have some form of locator with all objects

• It also makes sense to have a label/linguistic designator all objects

• “name” is an ambiguous term and should be gotten rid of; labels will have “short” and “long” types

• Discussion still underway on whether all objects need a definition, or whether definition should just be used in particular object use cases

• TC/modelers will need to revisit the way note fields function in a separate discussion

In Attendance: Wendy Thomas (organizer), Johan Fihn, Jeremy Iverson, Dan Smith        

Actions

Wendy: Finish Questionnaire Development portion by end of June

Jeremy: Review complete package in July/August

Discussion

How to proceed with 3.2+ issues

Sampling

Weighting

Questionnaire development

Publishing decision:  release these changes as DDI 3.3

Jeremy + other TC members will review content in July/August. TC will also finalize how to bring the new content into the existing 3.2 structure.

Release beta/review version to larger community by Dagstuhl in October 2014.

3.2 Documentation

A smaller contingent of TC will be looking over and working on 3.2 documentation.

TC Priorities

Next Week’s Agenda

Wrap up Name, Label, Description

What are we referencing?

Administrative metadata

In Attendance: Wendy Thomas (organizer), Johan Fihn, Dan Gillman, Jay Greenfield, Jeremy Iverson, Jon Johnson, Dan Smith

TC used this meeting time to advance work commitments to the DDI 4 Moving Forward Project

AGENDA:

Name, Label, Description

Identifiers

Containment and Reference/What do we reference?*

*TC decided to begin referring to the Containment and Reference portion of their work as “What do we reference?” at the 2014-06-12 meeting.

Actions

Discussion

Name, Label, Description

Frame of discussion/background: in previous versions of DDI, we’ve used ISO/IEC 11179-5 as the basis for our approach. This included a set of 3 objects: Name, Label, and Description. For Name we used a NameType, with each object having a specific name of type=”NameType” (i.e. VariableName, ConceptName, etc.)  We’ve made the decision to just use Name as a direct property of the object. Questions are:

1. What objects should we be using this with?

2. Is the full triple always required?

Dan Gillman would like to see us put more structure around names, concepts, labels, and designations. He will write up a document where he’ll lay out his ideas on this issue to give a sense of what the distinctions are and how to structure them. Aiming for early next week; send any questions to Dan in the meantime. The group consents to this plan and will use this document when making its proposal to the modeler group.

Identifiers

Dan Smith wrote up a document on this issue and discussed each section of it with the group. Highlights from this discussion:

• Group agrees on requirements Dan outlined in this document

• Character restrictions: in 4 we will lift character restrictions to allow for support of localized identification schemas. The historical reason for character restrictions is now managed by the ability to capture a DDI lifecycle URN in 2.5: identifiers in 4 will still be able to be represented in Codebook.

• When we get back to working on administrative metadata we need to pay attention to potential overloading.

• XML serialization and RDF serialization: Dan has outlined 2 potential strategies for doing this, and says it could be done with either approach or a combination of them. The group responsible for determining the approach are the groups doing the transformations.

• Dan’s document is ready to be presented; it’s meant to describe the how’s, not the what’s—that’s for the modelers; the how and the application are intentionally being treated as two separate functions in this workflow.

  
  

  Containment and Reference/What do we reference?

  
  

• Will discuss fully in another meeting.

• Changed what we refer to this discussion as to “What do we reference?”

  
  

  Other TC Business

   

  Dan Smith put out a call on the DDI-user list that starts the mapping of the GSIM 1.1 to DDI 3.2. He asks that everyone look that over and send in any comments. If there’s feedback, Wendy will put on the agenda for next week’s TC meeting.

  
  

  Plans for Next Week

   

  Back to TC 3.2 work: Sampling, weighting and questionnaire development.

In Attendance: Wendy Thomas (organizer), Dan Smith, Johan Fihn, Jon Johnson

Minutes

• Update on Core Group:
  • Foundational was split into Conceptual and Basic (reused objects) at Vancouver Sprint. Basic may belong with Core (as a separate object package)
  • Need rules to make these decisions consistently over time
  • Will these be finalized by end of IASSIST Sprint but should be able to get as "finished as possible" by end of sprint. There may be changes required later on

• Status update on loading 3.2 into Drupal:
  • Scripts finished
  • Concern with elements with same name - substitution groups for Record Layout - need a resolution and then we can push it through
  • Suggestion has been to differentiate by attaching namespace
  • Jon and Olof are working on this and will be in contact tomorrow to agree to a solution
  • Aggregation and composition still need to happen when an object is used (which is OK)

• IASSIST Sprint:
  • Jon is available for remote call-in
  • He is 5 hours ahead of Toronto - Jon is flexible for when he is needed to call in during sprint
  • There is still a concern that needs to be addressed at sprint (raised through emails with Therese). How the item formerly known as package gets settled. How object sets are organized in Drupal and subsequently in the object library. How its operationalized. Concerned that people doing view having things change under them without them knowing it. At least do something by hand to make sure it can be done (A to Z). We have a dependence on a locked down library on which things will depend. Currently vapor ware.

• GSIM and DDI 3.2:
  • Dan and Jeremy have been working with Statistics Sweden and Statistics Denmark and mapping the Neuchâtel model GSIM 1.1 to DDI 3.2. The draft will be sent around soon and should be available for Sprint.
  • It was noted during these discussions that the separation of code from categories and the ability to link categories to concept was useful.

In Attendance: Wendy Thomas (organizer), Jeremy Iverson, Dan Smith, Achim Wackerow

Actions

Wendy:

• Upload 594/595 E-mail thread to Mantis (done)

• Include 3.2 conversion as to-do item in TC report (done)

• Continue working on Questionnaire development SDI  prep work

• Continue working on Name, Label, Description framework document

• Write up a Containment/Reference framework document

Achim

• Put XKOS explanatory paragraph on Web page

Minutes

• Update on actions from 20140417

  • Issues 594 and 595: Wendy will upload E-mail thread with her, Bill, and Mary where TC discussion about these issues is summarized onto issue 594.

  • 3.2 load: Jon is working on simplifying the spreadsheet, and Olaf should have some time for this next week. It’s moving along.

  • Sampling, Weighting, and Questionnaire development:

• Wendy sent the updated 3.2 draft for weighting and sampling to Jeremy. Still working on questionnaire development—should be done by Toronto.

• Clarification on Jeremy’s role: review ABS (Australian Bureau of Statistics) material and verify that the structure captures what they need it to capture.

• Name, Label, Description: Wendy is still working on writing up the framework/statement from TC that will inform the modelers’ discussion.

• New Items

  • Update on Disco and XKOS Review:

    • XKOS explanatory materials (METIS paper, ISI paper, and ISI poster) have been added to the XKOS page of the Alliance website under Related Publications (http://www.ddialliance.org/Specification/RDF/XKOS). The short paragraph highlighting XKOS’s purpose is also ready to go.

    • The announcement will go out to various DDI and Semantic Web listservs in about 5 weeks.

    • On track for DDI public review in the fall.

  • Containment and Reference:

    • There were no volunteers to write up the framework document for this discussion.

    • Wendy will write something up that clarifies the question and proposes a framework. Will send to Thérèse and modelers.

  • DDI Profile – comments from ABS:

    • ABS developed nested-stack DDI profiles. It’s a local extension that ABS thinks has value, so Wendy will be filing a new issue so we can continue thinking about this idea.

    • Max thanked Achim for the XSLTs. Achim suggests we put on website. Wendy suggests the tools page as a home for those.

  • High level documentation for 3.2 – completion: Jon not present for update.

  • Update of examples on DDI site:

    • Everything needs to be converted to 3.2. Who will do the work?

    • Consensus that the task should be coordinated by TC, but is not a current priority due to a heavy workload.

    • Wendy will put this in the TC report as a to-do item. At the meeting with the Scientific Committee, TC will acknowledge that we have too much, and will ask people to take on a few conversions while at that meeting.

    • Achim suggests we create a to-do/task list in the new collaboration platform where people can sign up to complete tasks like this.

  • Validation and Transformation Language (VTL):

    • The timeline is tight and the development process has been moving quickly.

    • What is TC’s role in the development of this?: Observer position. Arofan may be in touch to collect TC ideas to be added to the discussion, but if he doesn’t then TC isn’t in a position to make suggestions.

In Attendance: Wendy Thomas (organizer), Johan Fihn, Jeremy Iverson, Jon Johnson

Secretary: Elise Dunham
-------------------------------------------------------------------------------
Goal: Set priorities for coming year.
________________________________________________________________________________________
Actions:

Everyone:
*Review project management platform and come up with a "wish list" of features.
*Ensure that consideration of outstanding Codebook issues (594, 595, 496, 498) be present in development of DDI 4.

Wendy:
*Seek out more information about issues 594 and 595.
*Prep SDI work.
*Draft paper on relating to other standards.

Wendy and Jon:
*Flesh out plan for addressing upgrade of 3.0 examples on website.

Jeremy:
*Follow-up with Wendy about SDI work will take place in May/June.

Johan:
*Set up a phone conversation with Jon and Olaf about loading 3.2 objects in two separate batches. Also discuss strategies for streamlining the load process for Olaf (i.e. template).

Jon:
*Review Wendy's 3.2 loading spreadsheet and have comments to her on 2014-04-11.
______________________________________________________________________________________

Minutes

-Administrative-

*Secretary:
Elise Dunham recruited at NADDI 2014 to take notes at TC Meeetings

*Meeting balance between TC specific activities and Moving Forward Project:
Most TC members are in the Modeling Project group, and will have meeting commitments in that capacity. TC meetings will be REDUCING once the Modeling Project meetings get going.
**Additionally, TC meetings will NOT be held on:
2014-05-01
2014-05-08
2014-05-29
2014-06-05

*Jira/Convergence platform:
Since TC/Moving Forward will be juggling a variety of moving parts (modeling/DDI 4, 3.2 documentation, SDI), Thérèse Lalor (DDI Modeling Project project manager) is setting up a project management platform and will be sending out more information soon. The platform is open source and there's opportunities for add-ins, so everyone should review it and put together a "wish list" of features/functionality they'd like to see.

-DDI Codebook-

*Outstanding Issues:
Issues 594 and 595 (access constraints and provenance--more information needed)
Issues 496 and 498 (URN--legacy issue)

Wendy will seek out more information about issues 594 and 595. TC will ensure that consideration of these issues be present in development of DDI 4.

-DDI 3.2-

*Documentation - Part I and Part II
Jon and Wendy are heading up this effort. Discussion point: how to develop/acquire example DDI instances for Part II  (which is based on a use case approach).
Suggestions: Search Web for DDI 3.2, grab from MIDUS once it goes to 3.2, post to Users and Developers list asking for 3.2
Decision: Post to Users and Developers list. Specify types of examples we are looking for. Ask for 3.2 OR 3.1; we can upgrade any 3.1s.

*Website examples are still in 3.0
Suggestion: recruit--ID 3.0 instances on website and ask for users to upgrade them to 3.1 and/or 3.2.
Jon and Wendy will flesh out this plan.

*SDI content (Sampling, Questionnaire Design, Weighting)
Decision: It is time to move forward on this. Jeremy volunteered to put some work into it in May or June. Wendy will prep and they will get together to see it through.

-DDI 4-

*All projects fall into combined TC/Modelers territory. TC separated projects into 3 priority groups (1=highest priority, 2=middle priority, 3=lower priority)

1
-Modelling: Name, Label, Description
-Modelling: Containership and reference
-Loading 3.2 content
Actions:
*Johan will set up a phone conversation for him, Jon, and Olaf about loading 3.2 objects in two separate batches. They will also discuss strategies for streamlining the load process for Olaf (i.e. template)
*Jon will look over Wendy's spreadsheet and have comments to her on 2014-04-11.
Note:
*Wendy's goal is to keep detailed conversations about the spreadsheet outside of discussions with all of TC.

2
Modelling: Administrative metadata
Modelling: Grouping

3
Relating to other standards
Note: Wendy is working on a draft paper about this based on what came out of NADDI Sprint in Vancouver.

-Other things TC should be doing in the next 6 months to a year?-

*Propose that the DDI Alliance prioritize marketing.