Page Comparison

ATTENDEES: Wendy, Jeremy, Dan S., Larry, Oliver, Achim

DDILIFE-3595 language and CodeValueType - No change
DDILIFE-3593 Quality Statement / Quality Standard - resolved
DDILIFE-3594 [haven't entered yet]
DDILIFE-3519 Classification management (Copenhagen mapping) - New metadata items are present in XML serialization but need to add in their usages - end of month
Documentation:
Task - rendering examples in documentation

TC-8 Please review this issue and the related documents. I am attempting to organize these into sets of related issues we can discuss and resolve during the Prototype process. Also any additional means of internal review (particularly in terms of bindings, xmi, documentation, examples, etc.). Note that some issues need some background work that perhaps smaller groups could do in preparation for a broader discussion. Others are topics where we'll want to bring in others from outside of TC. I'd like to get some sense of what we can accomplish and how the work will be distributed over the coming weeks.
Need to front end issues for XMI - review and comment for discussion and decision next Thursday.

Note that MT will not be meeting for the foreseeable future so we have that timeslot Wednesday (9:00 CDT / 16:00 CET) for subgroups or additional discussion time.

NEXT WEEK:
--Example review for additional issues/problems - Wendy will prepare the content for this review of updated Examples
--Issues regarding XMI errors - send out email on what issues need to be looked at and commented on

ATTENDEES: Wendy, Dan S., Jeremy, Larry, Jay, Guillaume

DDI4: (15 minutes)
TC-68 resolved - fixed
TC-76 resolved - no change
TC-77 resolved and entered
TC-81 Post-Prototype

DDILIFE (45 minutes)
3593 - go back and fix
3590 - check extension base of two items that were ext base other material
3519 - Coppenhagen Mapping - did not get to
3591 - Review in Bitbucket see commit 4ae0eda in Wendy's branch
3594 - A documentation issue. Documentation of the elements MarkedIncrement and ValueIncreatment contain their target documentation instead of the use documentation. Because both use the same base type this is confusing. Review recommended documenation change on issue and comment.

Didn't get past 3590 some work will get done remotely so we can get as much into 3.3 for NADDI as possible. TC-77 and TC-68 were entered in model post meeting.

ATTENDING: Wendy, Jeremy, Dan S., Johan, Oliver, Jay, Larry, Achim, Guillaume

DDILIFE-3519 Copenhagen mapping - questions noted in comments;
DDILIFE-3590 OtherMaterial - management options;
postpone - DDILIFE-3593 QualityStatement review and recommendation; - review not complete
TC-58 (includes 38, 34, 51) - recommendation; resolved
TC-70, TC-71, TC-72, TC-74 all with recommendations - all resolved
TC-65 Add the 4 classes requested
TC-69 determined to be post-prototype

TC-60 - to address the immediate action needed and when the larger problem of production needs to be addressed
Cardinality errors with Composition have been resolved under the current framework TC-60

Aggregation cardinality should be a priority issue - review and fixed - TC-77
Example: 2nd to last comment from the bottom AggregationText
Cardinality as expressed in Aggregations and Neither in Lion

In future XMI should be exported correctly - TC-78

AGENDA: Wendy, Dan s., Larry, Jay, Johan, Oliver, Kelly

OtherMaterial changes (DDILIFE-3590) - see issue
Copenhagen mapping (DDILIFE-3519)
DimensionType documentation (DDILIFE-3591) - OK
StandardType BUG (DDILIFE-3593) - see issue
10-15 minutes on Priority Prototype issues:
TC-60, TC-59, TC-57 - resolved enter
set of TC-38, 45, 51, 52, 58 (dealing with reorganization of packages) - draft collective recommedation and put on next week's agenda

Timeline: End of March for final changes in 3.3; review out in April

NEXT WEEK:
DDILIFE-3519 Copenhagen mapping - questions noted in comments
DDILIFE-3590 OtherMaterial - management options
DDILIFE-3593 QualityStatement review and recommendation
TC-38, 45, 51, 52, 58 - recommendation

ATTENDEES: Wendy, Dan S, Jay, Jeremy, Oliver, Larry

DDILIFE-3589 - closed
DDILIFE-3590 - resolved - Wendy will write up all changes required and post on issue for review prior to entry

Copenhagen content
http://cdn.colectica.com/CopenhagenMapping/
--Where does it link into the model
--How can we use StatisticalClassification directly either as a choice in CodeListRepresentation or similar to GeographicStructure/Location usage, also Catagorical
--Is the target the same in terms of code? ItemCode is a property, Name, Label
--From a developer perspective its not a big deal
--For a large classification it keeps it in a unifying set
--In using it as a representation can we make the same clarification of what is used by the representation

Do the properties make sense in terms of what has been selected, cardinality, relationships.

Where do they go in
https://statswiki.unece.org/display/gsim/3+_Object+graph

Do we have questions about putting this into 3.3 - general agreement it should go in
--Derivation from Versionable or Maintainable - ClassificationFamily, ClassificationSeries, StatisticalClassification go in as Maintainable
--FILE (DDILIFE-3592) 3.4 possiblity to collapse Identifiable/Versionable/Maintainable - file as future issue
--Suggestion is to put it in LogicalProcduct and include in LogicalProductPackagingItem

--FILE (DDILIFE-3591) DimensionType documentation regarding inclusion of variables with representations other than CodeRepresentation (Geographic, Statistical, etc.)

NEXT WEEK Dan S will make a proposed list of where this would link in. Others should review and comment in JIRA issue

ATTENDEES: Wendy, Jon, Larry, Oliver, Jeremy, Dan S., Kelly, Jay

Reviewed TC issues related to Prototype identify those that were priority (could be quickly resolved and fixed)
Resolved TC-33, TC-32, TC-31, TC-30, TC-28, TC-24
Those requiring changes to model will be entered by Wendy and added to the change list for Prototype internal review
Those relating requiring documentation will have documentation located and relayed to RDF group.

ATTENDEES: Wendy, Dan S., Jeremy, Oliver, Larry, Jay, Guillaume, Johan, Achim, Eric, Kelly

1-RDF/OWL issues: Eric and Achim will be joining the cal

Thanks to Eric and Achim for joining us regarding TC comments on RDF Strategy

Prioritization in strategy
Doing some diagnostics on model to check types were coherent
Emitting OWL that used properties as defined in DDI model directly (no external namespaces) - isomorphic easy to roundtrip
3-5 figure out which foreign namespaces we want to use; write or document something that converts from XML to RDF; in practice the model always has some sort of implementation so "going through the model" may be just a conceptual approach. XMI describes the model but not an instance of metadata.

Focus should be on stategy and documentation of algorithms/approaches. Creation of tools could be part of review but not critical for prototype.

Add the strategy noted above to the strategy document and note how this relates to the Dagstuhl documents and discussions.

Protégé is one type of validation. Other forms of validation should be noted if know or a statement that we need to determine the types of validation needed.

Specific item 1: Package recognition: Useful in OWL for navigation. The use of packages and functional views could be confusing. Look at the requirement "supporting navigation". Is the package useful for this or would something else be more effective.

Specific item 2: keep contact to get on the same page, use of JIRA etc. so we can follow and comment

tool for exploring https://rawgit.com/ericprud/XMItoRDF/master/doc/index.html

Specific item 3: Easier to have a simple model but this could come into conflict with how patterns are realized in the model. Can the design patterns be modeled in another way that can be recognized by the UML. Future problem.

There is the regular expression twice defined. There is a property regularExpression.
5 poly morphic properties will be filed in TC
Several dialects of OWL: OWL/XML, Turtle, Manchester...etc.
Which OWL sublanguage is being targeted: DL probably, might fit with RL

Is there someplace that we a list of all the rules we should be checking? We need to put these together and post them in a promenent place. This needs to be clear what we're doing, what have automated checks. -- WENDY
alliance.atlassian.net/wiki/spaces/DDI4/pages/104857601/DDI+Design+Rules+-+draft+work

2-Triage on current TC issues related to Prototype Model
Go through TC issues with Prototype label for next week. indicate if the issue should be addressed, documented only, or tabled for post-prototype review

3-Update on 3.3 documentation progress

NEXT WEEK:
Copenhagen modeling work - where it links into the model

ATTENDING: Wendy, Jon, Oliver, Jay, Larry, Dan S., Jeremy

AGENDA:
1 - RDF/OWL Stategy for TC Review:
If package is being represented in RDF this is a problem in terms of references and movement of classes between packages
Would like to see early on what can be discribed for discovery purposes because members are already experienting with what they can do using the RDF
This means TC needs to be involved at Step 3
4.a. What does this mean. Patterns are not currently in Bindings

This should be addressed in this strategy - doesn't look like previous work was not brought into this document
Serialization in RDF must contain the same semantic content as other bindings - this is not stated explicitly here (they must be conceptually the same
Round-tripping is a general requirement - requires that they be semantically identical

Don't see anything in her regarding the approach they are using regarding including other vocablaries. Mapping of generated RDF to OWL ontologies in not on this list. There were discussions of this in Dagstuhl. When do we use our own predicates and when do we replace them with our own ontologies. Part of the issue was the level of effort to do this. Part is how far to reflect RDF limitations in the model (similar to issues regarding XML).

Being able to read it into Protégé. This should be part of the strategy to verify its usability.

ACTION: Wendy will write this up and send to Kelly after review by TC by email

2-Update on 3.3 wrap-up work : Copenhagen mapping and documentation - on schedule

3-Quick review of Prototype issues filed in TC - add or refine as needed
-- In terms of documentation it may allow them some additional time to do finishing/reviewed/refined
-- TC's role is to determine if its fit for release
-- If documentation is bad all the people reviewing will let us know

4 - TC Prototype Review: An agreement on what type of issues/bugs with DDI 4 Model should result in changes and how we should do them (as found, in sets, all at once) - we need to keep RDF group up to date on changes and also anyone doing examples - is there a way to front end this work to get any changes done asap to support other work

Changes that get made: Bugs, violations of the modeling rules
Problems that may just be documented: complexity issues, multi-class relationships, improvements

Timing of changes - we should consult with Eric on this to see if he has a preference
Any changes will be well documented in terms of informing RDF and example creators - Create a change log (date, change, Build number) - currently the build runs every night but only commits changes

ACTION: Wendy will write up, send to Kelly, and set up a location for a TC Review of Prototype Change Log

5 - DNS filing
CV DNS filing - Strong recommendation from TC to use the DDI DNS namespace and file for an agency identification of DDI.CV. This approach becomes more important as 2 formats for publication include a DDI 3 Codelist and DDI 4 Custom Vocabulary
ACTION: Wendy will write up and send to CV group, Jared, Achim and post on issue)

NOTICE:
Encourage everyone to register for NADDI and send some emails on this to any groups you know of. [Wendy will send to APDU and State Data Center lists] use Jared's email

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

Pull request - merged

Workplan - reviewed who can do what when for next few months, adjusted for dependencies, still target of first week in April for 3.3 public review;

ACTION: post on workplan page and create issue to track assignments and progress (done)

RDF/DDI4 Model review work - JIRA tracker is being used so file issues or comment if you have a stake in this

Documentation/Marketing - just setting up and Marketing is getting involved with recruitment - more after that meeting

ATTENDEES: Wendy, Jon, Larry, Dan S., Jeremy, Johan, Guillaume, Kelly

DDI 4:
We're supposed to get most of content by NADDI
RDF may be delayed
--binding
--documentation (RDF specific)
--examples
--documentation of process
Earlier consensus of AG:
--Model itself
--serializations (XMI, XML, RDF)

TC has some role for input on the serializations and can be reviewed prior to transfer of content to TC
Get model serializations out for TC to look at prior to this

Criteria:
--Is the XMI just out there or does it have a purpose
--How is it to be used in the reveiw and can this XMI support that review - what systems are supported
(ex: caviates regarding mangling of cardinality and directionality of relationships in EA)
--Are these acceptable or unacceptable caviates.

XML - usages of the two sorts of XML the Library and the Views
What are the relationships?
Are they doing what we expect them to do - act as a profile or subset?
Do the serializations to what they say on the "tin"

RDF -
What is the minimum level we are willing to put out for review
Valid according to the spec and opens in Protégé - needed for review
This should be an iterative process - need to review
They need to use JIRA so we can see their progress
First call was last week, Second call today
First task is to formulate invitation language to send out within the week
Kelly will bring this forward to Eric

Highlevel documentation is the next essential about the relationship between the serialization and the model. What is the production system doing so that people can navigate between the RDF and the Model.

Round-tripability:
Something that needs to step up a bit in the review - Something that TC should be looking at and commenting on the problems/issues
Should take a look at what round-tripping means in reports from Dagstuhl 2017
Is there a clue to where the platform specific model vary from PIM in each case
There is the programming that makes the binding as one point
The model shouldn't be flattened for the RDF is a comment from last weeks RDF meeting.
Round trip means Binding to Model to Binding

DDI Lifecycle 3.3

COGS is now taking highlevel documentation and examples
It will be ready for dumping in more into it next week

(next week)
3524 - gt it in
3585 in is and needs review
(in progress - hopefully next week or 2)
Copenhagen mappings
COGS is not yet making the high level documentation for 3.3 so that needs to be worked on -

(will start on once the near final review version is ready - not a lot of time - task that needs to be done)
Do DDItoCOGS for 3.3 so we can test that out
Can use the strongly typed sheet from 3.2 plus the change log to identify what changes need to be made
Should Jon start uploading stuff into GITHUB or wait until Dan S. done some magic
Create branch for 3.2 first

(1-2 months)
High level documentation
All will be done in restructured text

2018 -
This year having the week long TC meeting was highly successful - bring up doing again in 2018

With controlled vocabularies have the DDI publish as DDI CodeLists - as well as current and proposed.

ATTENDEES: Wendy, Dan S., Jeremy, Larry, Jon, Oliver, Kelly, Guillaume
Johan - unavailable

Update on DNS filing / DDI URN resolution
Achim will be filing issues - we need to track it and nudge as needed
Should CV one be revised to fit into the DDI structure (for example agency name DDI-CV)

DDILIFE-3585
see issue

DDILIFE-3524
NEW revision - Guillaume will review and comment - if OK then this is what we go with

3.3 documentation
Wendy needs to do a brain dump - ASAP
System is up and running after working with Jeremy
Moving examples to COGS
Will put up on Bitbucket to get it available for contributions
Make sure people have access - they aren't beating down the doors at the moment

DID not get to.
3.3 work plan for review release
2018 priorities

ATTENDING: Wendy, Oliver, Jon, Guillaume, Jeremy, Dan S.

DDILIFE-3524 need examples see issue
DDILIFE-3583 closed
DDILIFE-3584 closed

Documentation: Jon needs and hour with Jeremy next week to sort out final issues. Wendy needs to do a content dump for Jon.

Short Sprint prior to NADDI. This is at the pass-off point between documentation and TC review. This is being looked at as a chance to do the following:

Wrap up any documentation issues
Organize and plan work of TC review
Layout DDI4 project work for the remainder of year (this would include Drupal to COGS conversion of work platform)
[space has been arranged]

Oliver - remotely
Jon - remotely
Jeremy - maybe (Sunday is easter) focus is 3.3 almost certainly no

Announcement of sprints and ask people to participate

Should this be a TC meeting? in which case we have 3.3 work that could be done even if it is out for review. Implementation issues, software development issues.

We used to have annual face-to-face meeting and these have always been very productive we need to reinstitute support for this. If we want a TC meeting do we do this as part of a review of 4 or do we want more 3.3 line.

ATTENDEES: Wendy, Dan S., Jeremy, Oliver, Guillaume, Larry

DDILIFE-3524
Original idea was that the conditional text was interleafed with the static text. By using the current conditional text is compute text or identify text using the source parameter. But people want an IF condition that if something is true then insert this text. It's supposed to be generating the text but there is nothing there that does this. If we want both computing text and an IF statement that results in a literal text.

The conditional text type inserts a block of text
How can we a conditional for literal text choices - Using the control construct within the text is overkill so we could probably make something more streamlined for this situation.

IfStatement condition and text if true - should probably go through Else to provide a default insert at minimum

Resolve to add an IfThenElse to choice in ConditionalText.

WT will draft IfElse for dynamic text.

How to indicate the position. Write documentation and examples of usage.
Still want allow source parameter
Want to be able to insert a combination of a text and source parameter as a result of an IF - Limit to a combination of literal text and source parameter

Reviewed DDI_L_3 entries and pulled into Master

ATTENDEES: Wendy, Oliver, Johan, Jeremy, Larry

DDILIFE 3581 - OK to remove

DDILIFE 3582 all approved with following not#4. Make sure it stays in the same order as previous when it was in in AbstraceVersionable. If not just add to each (non Abstract) to retain order

#7-9 move to reusable

DDILIFE 3524 - Check with Guilaume and others about using computation and logical expression, separating "true" and "false" responses into separate conditinal texts. How to specify which text. Definately good to be able to express specific text insert in a consistent way.