DCMI RDF AP Task Group http://wiki.dublincore.org/index.php/RDF_Application_Profiles Meeting date: Oct 14, 2014 Meeting link: https://meetings.webex.com/collabs/#/meetings/detail?uuid=M827XI891J15VQUQJE8CLM2I2W-JV0D&rnd=208157.54032 Etherpad: http://etherpad.wikimedia.org/p/dcmi-ap-rdf-14-10-2014

Attendees: Thomas, Karen, TomB, Adrian, EricP Regrets: Evelyn, Valentine, Mark M, Gordon D, Corey H

Re-organization of requirements (EricP)

Karen: EricP can explain what he needs. Obvious next task for us is to review next steps. Eric, how does this fit into W3C work?

EricP: First link is to requirements database. A few weeks ago, Arnaud and I were floored by the 200+ requirements. Then Peter Patel-Schneider pushed back on the inclusion of OWL there. Maybe instead of "disjoint classes", "pattern A and pattern B". I'm trying to figure out a way to characterize this in a way that is useful to everyone. I created a hierarchical view. Single monohierarchy. Meant to tease out patterns. One requirement for the language and for constraints on the language. You want the language to be terse. How many people have looked at it?

Alot of the constraints are expressed in OWL - not clear how disjoints lead people to arrive at the constraints. Hoping for a simpler language. Pattern A and Pattern B would be better. Maybe reflects my biases as editor of shape Expressions document. Also PPS didn't want to have the OWL inferential stuff in the requirements. So if we can have a view that slices those out...

http://www.w3.org/2014/10/rdfvalreqs/#R3 is at the top of the OWL inferential category I created.

Karen: Makes sense to me not to include OWL - do not see it as a requirement. We should write them as our requirements.

EricP: In this document, coding discipline: I write down the requirement in a human-readable form, link to requirement in the database, and under that, N examples in different languages. " In OWL/Resource Shapes/etc - this is how you would write it..."

karen:[ Looking for example that fits those requirements]

EricP: A person needs either foaf:name or foaf:firstname + foaf:lastname

Karen: We have something like Data Property Domain (R26). Seems fairly simple but described in fairly complex way. Are you considering ShEx expression that formal expression?

EricP: ShEx good at simple cases. You need SPARQL for things that span different records. Such as the uniqueness of a key. My guess: taking advantage of language that is most convenient. Down side: reader must be conversant in all languages.

Karen: This will be necessary for software developers.

EricP: People can look at English example. Urgency is that I am encouraging Shapes group to discuss this in first telecon and to have read it before.

Karen: Thomas, if I recall, place to put actual examples?

Thomas: You can have multiple examples. Maybe one per constraint language.

Karen: We could get testable examples for each one.

EricP: Formality is testable in following scenario when people need to clarify whether a requirement will meet their need [?].

Karen: In terms of this group, we have been focusing on the two dozen use cases we have added. We have not looked at the remaining use cases. Our use cases link to requirements that we have not produced, but altogether, we are only linked to about 24 requirements. Click on "DC requirements". And I have done a Google Doc that I cobbled together out of your first email - just pulls out DC ones. Hard to compare them. https://docs.google.com/spreadsheets/d/1fZLRRkKkCiR0ZQoiBtQGM_Q5NbUF2tn6g2iSidF2scc/edit#gid=0

Karen: I find some specific requirements that seem solvable with more general solution.

EricP: I didn't understand some, such as subsumption.

Thomas: Superclass relationships.

EricP: Have test in the demo. [pulls up link] http://www.w3.org/2013/ShEx/FancyShExDemo?schemaURL=test/Issue-inheritance/schema.shex&dataURL=test/Issue-inheritance/pass-user-employee.ttl What this does is say that an issue has to be reported by a person shape, and a person shape is inherited by a user shape and an employee shape. So you can match either user shape or employee shape. When you are trying to match something, you want polymorphism. Is that a typical use case for subsumption?

Thomas: I used the OWL spec. [1] Should be the same.

EricP: Should be a shortcut for eliminating disjoints.

Tom: So you mean disjoints between shape patterns?

EricP: Yes.

Karen: But there are alot of the cases, put in by Europeana - "this can be A or B but not both"

EricP: Exclusive OR. OWL will not do this as a pattern. R203 and they called it "context-specific"

Thomas: This pattern stands only for specific context for class. Context can be.

EricP: Trying to come up with a counter-example. Let's come back to that. Trying to make the DCMI database palatable to the Shapes WG.

Karen: Other problems?

EricP: Saw things I interpreted as duplicates. May not b e marketable to draw distinction btw compact concrete syntax and concrete syntax for constraints. I think that is getting at separating general framework from language for expressing constraints.

Karen: Thomas, this DC group is primarily looking at DC use cases, which is actually a minority (10%??) of the database. How willing are you to work with Shapes WG on requirements not related to ours.

EricP: Will focus on the DC part and make sure I understand them. Want to provide an alternative view of requirements to the Shapes WG.

Karen: I believe the requirements can be tagged differently - maybe just add a tag.

Thomas: We have two requirements hierarchy in parallel. We can add an alternative hierarchy, and user interface shows it.

Karen: Would we have both hierarchies or just one?

Thomas: To start, both in parallel, then link together when we have agreement between the two groups, we could delete the old one.

Karen: Eric, do you feel that changing some wording of names of the requirements and how they are described would be desirable?

EricP: Yes, started to do that.

Karen: Me too. On Number 26. http://lelystad.informatik.uni-mannheim.de/rdf-validation/?q=R-26-DATA-PROPERTY-DOMAIN

example of proposed replacement

EricP: This is a good example of "Pattern A or Pattern B". Trying to figure out the recipe for nice compromise versus helping someone quickly getting their head around it.

Karen: Even though I have steeped myself in RDF, "disjoint properties class specific" not immediately clear.

EricP: What do these look like in a validation context? If you see this and that, something is broken.

Karen: Many lack examples. Saying you can't have exactMatch/relatedMatch with same value.

EricP: In OWL, you say they have disjoint domains.

Karen: Different requirements for object properties and data properties. May be redundant. May be possible to make statement. Choice between A and B.

EricP: Discrimination between object and data properties in OWL largely uninteresting because we will mirror between the two anyway. OSLC resource shapes: "what the default value is" - could be a literal or IRI. Distinction between object/data properties is OWL-specific.

Karen: Possible that single function could test both. I see some here - would be nice to distill down. From the 24 down to smaller number seems possible. Good thing to do?

EricP: Vote yes.

Karen: In a sense, we are moving from use cases to requirements to solutions, and sometimes multiple requirements can have a single solution?

EricP: That's a good way to summarize it.. If there's something that's got equivalent data properties, we want to say just "properties" without losing fact that it previously made a distinction. Could fall back. Or annotate it.

Karen: DC requirements - could generalize. I have been going through.

EricP: Increases the odds that they will be covered by Shapes WG.

Karen: Have we given you what you need? How flexible are we willing to be? (Rhetorical) You could come back to us with suggestions, etc.

EricP: Ideally, just one database.

Karen: We may need to learn each others' points of view in order to mesh things. One task I will take as action. In some cases, if we had considered use cases beforehand... A comment box will open up under each.

Want to talk about the validation sessions in Austin. Alot of interest in validation, but we ended up concluding that we are talking about different things. Two emerging themes:

  1. people who need to validate existing data (Europeana receives from many providers)
  2. BIBFRAME viewpoint: creating an application profile that constraints data creation and 
      quality control at the point of creation.

These overlap, but have differences. Tom: different slant on validation; many people made the point that validating the data can be counter productive if it's binary: yes, no. There's a need for use of shapes to evaluate quality of the data on a scale, and results in a data quality report that gives feedback to data providers. Resistence to the idea of calling it validation - we did come up with some other terms: "communication, not validation"

EricP: Notion of validation is theoretical: "Here is a document of what we are expecting". Not just driving interfaces.

Karen: Need to mark validations in terms of adding in "messages" to [data providers].

Adrian: We added to our application profile - overlap with Hydra community? http://www.w3.org/ns/hydra/spec/latest/core/

Karen: DPLA folks also need something that will give their API users an idea of what they will receive.

Adrian: Not just what they will receive (which is not covered in Hydra Core vocabulary - rather, operations you can perform), but I have not dived that much into it. Might use in our application profile. I think there is alot of overlap.

Karen: Recently had a meeting. Corey was there. We can ask him how he thinks this fits. [Adrian: This actually is another "Hydra" in the repository world (https://wiki.duraspace.org/display/hydra/The+Hydra+Project ).]

Karen: They are trying to be kind to providers. Need way to express range of responses. One to five stars? If changes are needed to wording, am willing.

EricP: Trying to figure out consensus process needed within DC...?

Karen: This group is able. But do not have strong sense of what group thinks.

ACTION: All (in DC group) to comment on DC use cases and requirements. 

 ShExC: my:UserShape { ( foaf:givenName LITERAL , foaf:familyName LITERAL ) | foaf:name LITERAL }

ACTION on ALL: read and comment on DC UCases and Requirements

Notes from DC2014

  • Two sessions on validation - very well attended
  • Two emerging themes:
    • validating existing data (e.g. data aggregators - DPLA, Europeana)
    • structuring data creation and constraining values


Next Steps: 

   DO NOT ADD INFO OR VOTES HERE. THIS IS FROZEN. ACTIVE VERSION NOW AT 
   http://etherpad.wikimedia.org/p/dcmi-ap-rdf-28-10-2014

PROPOSAL: add a "+" by items you think we should consider; add your name to a task you are willing to work on Let's try this format: [x,x] (add your x in the brackets [Joe, Mary] (add your name in the brackets)

This is an uncensored round-up of ideas about next steps for this group. Many/most of these have come up during hallway discussions at DC2014. Add any others that come to your mind.

  • Look at and comment on all of the DC use cases and requirements. [x,x,x] [Karen]
  • Go through remaining case studies and add use cases and requirements to requirements database [] []
  • Compare requirements and capabilities of the DSP; what's missing from the DSP? is anything in DSP not needed? [x, x,x, x, x] [Thomas]
  • Read through the other case studies and see if there are any requirements that we haven't noted yet [] []
  • Create an ontology for the DSP. Is this useful? is it possible? [x] [] (kc: can't imagine that this could be done except with CWA)
  • Develop a light-weight AP as a core (a la' BIBFRAME profiles; this follows Eric Miller's proposal on Thursday afternoon that a simiple basis and then "cascading APs" similar to cascading style sheets that allow people to get into greater levels of detail and validation. [x, x,x, x] []
  • Develop DSP/OWL2 patterns for some/many common cases [x,x, x] [Karen,Thomas]
  • Definition of an RDF application profile [x, x,x,x, x, x] []
  • Create a few light-weight APs that people can use as examples/templates [x] []
  • Implement an automatic vaidation of each constraint expressed using the redefined DSP [x] [Thomas]
  • Go through remainder of requirements according to Eric's recommendations [x] [Thomas]
  • Go through remainder of requirements classification according to Karen's and Eric's recommendations [x] [Thomas]


Questions: These are questions that we need to discuss. Please put your [x] by those you consider to be the MOST IMPORTANT. Add others that you think of.

  • Is our goal to define a core for validation? [x, x,x, x]
  • Is our goal to fix the DSP?
  • Is our goal to create a standard for application profiles [x]?
  • Can we create a model AP [x]?
  • Can we create an input form for APs?
  • Do we want to add something related to data quality? Align requirements with some kind of data quality categories [x]
  • Do we want create errors messages corresponding to the validation requirements
  • How do we want to document the intentions of our application profiles? (Task from the charter: "Best practices for documenting the intention behind application profiles") Note that this work could bring a template re-usable by the whole DCMI community. It comes back to the idea How to document AP? [x,x]