minutes20150716

DCMI RDF AP Task Group
http://wiki.dublincore.org/index.php/RDF_Application_Profiles
Meeting date: July 16, 2015
Meeting link: https://meetings.webex.com/collabs/#/meetings/detail?uuid=M1RMXAWHCVXID8E5NEAFH8K88R-JV0D&rnd=416945.34093

Attendees: Karen, Antoine, Evelyn, Lars, Tom, Hugo
Regrets:  Thomas

==========
NB: This is a coordination call: we plan to survey many items, but will not dive so much into the content of these items. 
Rather, we will try to discuss what the group should do at a general level, and why.

AI: not sure the order I've put is perfect...

==========
Prior reading for coordination:
- our charter:
http://wiki.dublincore.org/index.php/RDF_Application_Profiles/Charter

==========

X. Documenting our work on use cases & requirements
Evelyn and Thomas' current version of the UCR report
http://wiki.dublincore.org/index.php/RDF_Application_Profiles/UCR_Deliverable
DCMI Req Database: http://lelystad.informatik.uni-mannheim.de/rdf-validation/
Requirement discussion pad: https://etherpad.wikimedia.org/p/requirements_analysis 

We now should have two documents: one on UCs and one on the Reqs
Corey: it could be unwiedly
Karen: we could copy-paste
Evely: I prefer two documents
Corey: OK
Antoine: we could merge them in the end

Use Cases document

Corey: there are use cases that have not been discuted

Proposal: assemble a "latest"/"as of today" version of our documents and advertise it.
(it can be still updated later if use cases and requirements are updated)

It's always possible to refer to the old versions in the version
http://wiki.dublincore.org/index.php?title=RDF_Application_Profiles/UCR_Deliverable&oldid=8496

ACTION: Evelyn and Thomas to make such update to the UC document


Requirement document:

New cleaned list: http://wiki.dublincore.org/index.php/RDF_Application_Profiles/Requirements
Karen 's mail gathering the "core" requirements : https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=DC-ARCHITECTURE;c8e0b38c.1506
Note: core requirements now noted in requirements wiki document

ACTION: Karen to point to the use case document from the Req document

Corey: I'm concerned about the straw poll we took for defining the core
... the basis was the assumption we were talking about validation only
... for my part I've left some things that I feel would be relevant
... looking at the charter, we've focusedon #3 RDF Constraint Specification and Validation
... The current list of core doesn't reflect the wider approach


Antoine: this sounds like a clear case for re-discussing the core after we've discussed the non-validation requirements
Karen: I can change the document to reflect that the bolded requiremnts are the core *validation* requirement
Antoine: a call on a broader core?
Karen: maybe not needed.
Tom: hard to say which part is which
... a lot of the meta-requirements are AP related
... some of the others (CWA) are prior to validation
Karen: we'd need an extra analysis
Antoine: are we saying that some validation reqs are not AP reqs?
Karen: it's ok, all validation reqs are AP reqs - we need to broaden our view

Karen: next calls could be on whitepaper.

Karen: in terms of documentation: many things are in the database. Should we continue?
Antoine: I'd like to base our reqs on cases
Karen: we could copy them outside
Corey: the DB has 'RDF validation' in the URI.
Evelyn: I could copy in the UC document
Karen: the requirement wiki also points to the DB.
antoine: if we copy the DB in one document, it could be huge
Karen: it has all our ideas
Evelyn: we could export it
Karen: we could do at the end of the task force
Antoine: in the meantime, where should we do our updates (use cases or requirements)?
Corey: if we draw new people to our group the 'RDF validation' title may be confusing.
Antoine: it has played a trick on us once already :-)
Antoine: we could ask Thomas to change the URL?
Corey: probably a non-starter. He uses it for his PhD, which is on validation
Corey: the LLD XG report had links to separate wiki pages with the original use case details
... which corresponds to an HTML version of what we could do.
... we could do an Markdown export
Antoine: thomas was using the DB to keep track of updates
... he could prefer us to keep using it rather than do updates on a separate wiki page
Karen: how many times would people need to access the origianl description?
... maybe not so much, so we could have the info exported in a more basic way
[discussion on creating one page on the wiki for every UC]
Corey: a page could be ok, as long as it has all the info
Corey: Here's something interesting: Drupal-Jekyll-Markdown module: https://github.com/lukaswhite/Drupal-Jekyll-Export
This would potentially allow us to export a markdown page per drupal node, and then generate media-wiki pages from those.

ACTION: Antoine to ask thomas his opinion/preference

X. Further identifying and defining requirements

Is graph management (de-referencing/caching prior to validation) in scope? 
-> discussion at https://lists.w3.org/Archives/Public/public-data-shapes-wg/2015Jun/0023.html
ACTION: Corey and Tom to write short position paper.
--DONE: white paper on Blending DCAM, DCAP, DSP, & SHACL
http://wiki.dublincore.org/index.php/RDF_Application_Profiles/blendingDoc
https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=DC-ARCHITECTURE;97253c14.1506

ACTION: Antoine to look at unclear requirements in Hugo's email
--ONGOING: only one requirement remains unclear: https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=DC-ARCHITECTURE;8c92de00.1506

Lars' new requirement:
Lars' mail at https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=DC-ARCHITECTURE;1208a4d2.1506
Discussed in previous call: https://etherpad.wikimedia.org/p/dcmi-ap-18-06-2015
Lars' mail to LDP list: https://lists.w3.org/Archives/Public/public-ldp/2015Jul/0004.html
ACTION: Antoine to sum up and email the discussion. [on the differences with other requirements] And put the case and requirement in our database.

Karen: Antoine has started a document. What was the requirements?
Antoine: it was about communicating data, partly
Karen: this one may not be for us.
Corey: the others were AP-related, the one on communication has been pushed to LDP


Comparison with W3C requirement (cf point below)
Hugo's email with suggestions: https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=DC-ARCHITECTURE;41aa27ca.1505
ACTION: group to tackle by email:
- requirements taken from W3C which apparently don’t have a match in DC
- suggestions on the mapping from DC to W3C

Antoine: should we postpone?
Corey: maybe we can do it.
... some of these W3C requirement are actually going outside of the validation area
Antoine: if it's the case, yes.

X. Further organizing requirements

Core requirements 
Voting: https://docs.google.com/spreadsheets/d/1bCpQVyxI-N2Ca83umvQD8OKTdsDyG6Sz-E8Qo3v8ynM/
Karen's mail: https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=DC-ARCHITECTURE;c8e0b38c.1506

Already discussed!

Other organization needed?
ACTION: Hugo to try to organize reqs in abstract requirements, trying to re-use Thomas' classification in the DB
--ONGOING: Thomas' classification was still ongoing work.

Hugo: it could help us map to W3C
Karen: now I have re-organized the W3C requirements following our own organization
Hugo: W3C requirements are much technical
... the ones not matched with DC are rleated to datatypes, formats.
... DC captures the general constraints.
Karen: ongoing discussion at W3C
... F2F meeting in early

suggestion: do we need the action
All: agreed to DROP
Karen: if we need it it will come back up

X. Development of test cases
- Europeana examples: one valid EDM, one with errors
https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=DC-ARCHITECTURE;e0ba3d12.1506
- Stefanie's examples:
https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind1505&L=DC-ARCHITECTURE&F=&S=&P=11705
- Corey's examples (based on Hydra work)

Antoine: do we feel it's still in scope?
Karen: it could be a W3C coordination task
... when W3C has their validation we can check whether it validates our data.
... Maybe we can test our use case when they announce their first implementation
Antoine: ok, we could wait.
... it started from the need to make the requirement as complete as possible
Corey: we could keep this in mind, that requirement need to have example
... this could remove the need for separate test cases
Antoine: we could distribute the material already gathered into the separate requirements
... once the w3c has their own implementation

===== Call stops here

Karen: we could discuss the other items
... and the DCMA issue

ACTION: Karen to post a message about the DCAM issue.

ACTION: Antoine to send the write-up of the discussion about Lars' case

=====

X. Alignment with W3C work
W3C Use Cases and Requirements: http://www.w3.org/TR/shacl-ucr/
Current W3C requirements list, reorganized: http://w3c.github.io/data-shapes/data-shapes-ucr/

Comparison of W3C and DCMI requirements:
https://docs.google.com/spreadsheets/d/1bCpQVyxI-N2Ca83umvQD8OKTdsDyG6Sz-E8Qo3v8ynM/

Hugo's email with suggestions: https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=DC-ARCHITECTURE;41aa27ca.1505
ACTION: group to tackle by email:
- requirements taken from W3C which apparently don’t have a match in DC
- suggestions on the mapping from DC to W3C

X. Express requirements as RDF, mapping between DSP and our requirements

X. Coordination with BIBFRAME
Thomas' evaluation of BIBFRAME AP
http://wiki.dublincore.org/index.php/RDF_Application_Profiles/BibframeAnalysis

X. Coordination with Hydra, Fedora
Hydra Metadata Working Group: https://wiki.duraspace.org/display/hydra/Hydra+Metadata+Working+Group
Portland Common Data Model: https://wiki.duraspace.org/display/FF/Portland+Common+Data+Model
ACTION: Karen: post this link to W3C group - on hold until W3C group gets to the right point

X. Coming conferences: DC, TPDL, SWIB

X. Glossary - postponed until we have time!
====
Final scoping discussion: Look at our old "possible next steps", see if we're missing something.
http://etherpad.wikimedia.org/p/requirements_next_steps

NB [Antoine]: ideally I should have distributed the items in these lists in the section above, but I didn't have time. On the other hand it may be a good group exercise.

====
AOB, next calls