DCMI RDF AP Task Group
http://wiki.dublincore.org/index.php/RDF_Application_Profiles
Meeting date: Dec 3, 2015
Meeting link: https://meetings.webex.com/collabs/#/meetings/detail?uuid=M6Z5D9V6V6WIXOLFOKBAUSDVYV-JV0D&rnd=327025.71398
Meeting minutes: https://etherpad.wikimedia.org/p/dcmi-ap-03-12-2015

Attendees: Karen, Hugo, Antoine, Stefanie, Lars, Thomas
Regrets: Corey, Valentine (here towards the end)
    
Agenda:
    
    
    Karen's question to Tom: which version of the SHACL have you looked at
    Thomas: October
    Antoine: there's a new editor's draft from today
        
Karen: every complete validation will cover our needs probably
... things will be different for documentation
... we talked about it in the meeting in Hamburg

    
1.  look at the "to do" list from the minutes of the SWIB break-out session:
    http://wiki.dublincore.org/index.php/RDF_Application_Profiles/SWIB2015_breakout

- 1. take DC requirements and see if languages from W3C group (SHACL and maybe also ShEx) can cover them
Current DCMI spreadsheet: https://docs.google.com/spreadsheets/d/1bCpQVyxI-N2Ca83umvQD8OKTdsDyG6Sz-E8Qo3v8ynM/edit#gid=1060352541&vpid=A1
SHACL table: https://docs.google.com/document/d/1whx2DeJtng-WZXo2DAHc_GZL7ElXNS_B8fBxarGA-0o

- 2. start working on dcmi/dsp to shacl implementation
-- for DC and other community, SHACL can be a black box, we don’t intend to interact directly with its internals
-- There is SHACL validation, we want to be able to send profiles against it and receive results
-- If the point of the SHACL initiative is being driven by ‘hard core SPARQL types’, we can translate everything into SPARQL.

Hugo: constraints are defined in a different namespace; so you can see what was applied.
Antoine: SHACL itself not clear
Karen: SHACL is complete but it doesn't lend itself to expressing some doc about constraints.
... one of the proposals to the W3C group is that ShEx be used as the entry vocabulary into SHACL
... because SHACL is more complex
... would require TopBraid as interface
... the proposal is that people would use ShEx and then there would be translation to SHACL

Hugo: what's the problem? Complexity of the language or relation between (human-readable) constraints and the SHACL code?
... if the latter, then there are options.
Karen: yes, it's also what messages are returned as a SHACL rule
... there's an error vocabulary
... multiple iteration, including one that would return messages for every triple validated.
Hugo: there is a possibility, which can be customized
... in TopBraid
Karen: the problem is that it's difficult to understand how much of it is TopBraid and how much of it is SHACL
Hugo: it's standard SHACL (http://www.w3.org/TR/shacl/#results)
... I didn't use the TopBraid editor, just the validator

Antoine: we could end up with a set of SHACL patterns or expressions
Hugo: it is primarily terminology - what the message should incorporate

Karen: Hugo if you express a message and you do a validation, do you get a message?
Hugo: yes

ACTION: Hugo to show how SHACL would handle a couple of error messages

esh:CycleConstraint
        a sh:ConstraintTemplate ;
        rdfs:label "Language constraint" ;
        rdfs:subClassOf sh:TemplateConstraint ;
        sh:argument [
                sh:predicate esh:property ;
                sh:class rdf:Property ;
                sh:name "predicate" ;
                sh:description "The property to validate the values of." ;
    ] ;
        rdfs:comment "Cannot reference the same resource with this property"^^xsd:string ;
        sh:message "Cycle reference" ;
        sh:sparql """
          SELECT ?this (?this as ?subject) $predicate (?this as ?object)
      WHERE { ?this $predicate ?this . }
    """ ;
.

Karen: will the level of granularity be enough?
Antoine: we'd have to come with requirements.
Karen: messages with dependencies

Hugo: Something like this: "Check that if edm:ProvidedCHO is present, at least one dc:title or dc:description should be present,  one dc:subject or dc:type or dc:coverage or dcterms:spatial and edm:type should be present"?

Antoine:this is still very general - this message can't be customized.
Stefanie: if we have isPartOf we need isNextInSequence
Hugo: this seems doable.

Stefanie: we could go through our requirements and write down messages we think we need

ACTION: Stefanie to go through DDB/EDM requirements and create error messages.

Karen: Thomas, Hugo, about indicating optional properties
... cf Thomas' list on p 266
... whether it's open or closed
Hugo: it's closed
Karen: no it's open unless you say it's closed
... I'm interested in how this works with optional properties
... we'd have to create a Shape and close it with a minimal of zero
Thomas: for my evaluation I've assumed a closed world and then we could treat it with cardinality
Hugo: open/closed is really about a property can be used, which has not been defined.
Karen: properties that cannot be used?
... if a property is there that's not defined in the model
... with SHACL the default is that it's ignored.
... Do you want to flag it instead?
Antoine: where is our requirement?
Hugo: http://wiki.dublincore.org/index.php/RDF_Application_Profiles/Requirements#R-72_Recommended_Properties
Karen: 'recommended' is not an error.
Hugo: http://w3c.github.io/data-shapes/shacl/#results-severity

Karen: Back to waht we talked about in Hamburg
... not only validation, but also the workflow
... what is the validation on the data that is received
... and create some human-readable doc
... and user interface elements

Valentine: suggestions for data elements

Antoine: W3C SHACL says SHACL is for constraints, but it has messages that are not about (strict) validation
Stefanie: with Eric Miller we had talked about 'data analysis'
Karen: yes. We also want to document more than what others have expressed.

Karen: there is also the user interface problem
... right now it has comments, property names, stating the order of properties.
... less than what a user needs.

Antoine: couldn't we make out of scope?
Stefanie: yes
Lars: we talked about a 'schema' (more a style sheet similar to an XSL)
Karen: we talked about layering
... I can post to the list some options

ACTION: Karen to post about layering to the group.
+1 to layering...
but let's not reproduce the TEI/html5 issue

- 3. at same time, extend dsp as/if needed


Formal aspects:
    renewing charter?
    
    ACTION: Valentine to ask about charter extension in the next executive committee meeting
    
    ACTION: Antoine and Karen to send to Valentine our todo list
    

2. Moving time of meetings?
7am or 8am PST, i.e 16:00 or 17:00 CET

17:00 it is!

ACTION: Karen to post on the list