Contents

DCMI RDF AP Task Group

http://wiki.dublincore.org/index.php/RDF_Application_Profiles

Meeting date: Oct 28, 2014

Meeting link: https://meetings.webex.com/collabs/#/meetings/detail?uuid=MEPQL0H3FJIDJB3D2ENNUCM2VH-JV0D&rnd=348706.37980

Etherpad: http://etherpad.wikimedia.org/p/dcmi-ap-rdf-28-10-2014

Attendees: Adrian, Karen, Valentine, Antoine, Corey, Kai, Stefanie, Lars, Evelyn

Regrets: Mark M

1. Coordination with W3C RDF Data Shapes WG

Report from first W3C Shapes working group meeting [Karen]

https://www.jiscmail.ac.uk/cgi-bin/webadmin?A1=ind1410&L=dc-architecture#33

TPAC meeting: Oct. 30-31, Santa Clara, CA http://www.w3.org/2014/11/TPAC/

  • day 1: general discussion
  • day 2: discussion requirements
  • DCMI is participating in W3C WG
  • Karen will attend Oct 30-31 (and take copious notes)
  • Next RDF AP meeting (Nov. 11) - Report back and discussion about what this means for us

charter: http://www.w3.org/2014/rds/charter

discussion list: http://lists.w3.org/Archives/Public/public-rdf-shapes/

W3C task group has been instantiated; will be meeting at W3C Technical meeting. http://www.w3.org/2014/11/TPAC/

Karen: DCMI will have official representation at the W3C WG. I will go to the F2F

  • Eric said that that the first day will be general discussion
  • the second day will be devoted to look at our requirements
  • So we need to determine what our direction is going to be
  • What we contribute to the DC community.
  • We're up in the air
  • In the meantime we have to think about what we want to do
  • Questions?

Kai: makes things easier in some ways; can have influence on the results.

  • who should be part of this group?
  • Thomas is too busy. And being part of a W3C WG means quite some work.
  • On the other hand if they want to use the database it would be useful if he officially says that he cannot do more than maintaining the DB.

Karen: I can represent but a second person would be very welcome

Kai: especially given the interest we have in their work.

Karen: anyone interested please contact Antoine and I

Kai: Thomas could have a role, but it would be better if it wasn't an official commitment

[Corey asks if DCMI is member of W3C]

Karen: that's being worked on

Corey: will they re-use the DB we work on?

Karen: yes

Corey: maybe we'll get comments from them! This would be great

Antoine: what's the status of

http://www.w3.org/2014/10/rdfvalreqs/#R3 ?

Karen: it's Eric's attempts to look at the requirements in his own way

  • it isn't an attempt to replace our DB.
  • a desire for playing around with the requirements in a more flexible way than Drupal.

Karen: these are things we'll try to work out at the F2F this week.

  • I'll send a lot of notes!

2. Next step: Create an RDF ontology for the DSP. (Kai)

Karen: it's a topic from DC14

  • an RDF ontology to help develop test cases.

Kai: DSP is still a working draft.

  • Need to be able to serialize DSP in RDF.
  • RDF Version of it, using RDF Schema to start
  • Things (in DSP) can still be removed, missing, worked on.

Kai apparently volunteered!

Kai: the start is straightforward: translating the DSP in RDF. Putting it somewhere public so that people can comment.

Karen: DSP in RDF would make it easier to create test cases

3. Commenting and analyzing use cases and requirements (Karen)

Table of Case Studies and their analysis status:

http://wiki.dublincore.org/index.php/RDF-Application-Profiles#Use_Cases

New features in requirements DB:

  • See list of requirements that includes comments
  • See latest edits

examples:

http://lelystad.informatik.uni-mannheim.de/rdf-validation/?q=requirements/requirements-comments

http://lelystad.informatik.uni-mannheim.de/rdf-validation/?q=tracker

Karen: people have started to comment on use cases and requirements

Evelyn has made comments

Evelyn: sometimes we have a specific requirement on one hand.

  • on the other hand we try to generalize them
  • it's confusing, how far we should go in each direction.
  • Some requirements look like broader terms of others.
  • Some requirements look like broader terms of others.

Karen: this is a question to keep in mind while looking at requirements.

Evelyn for example http://lelystad.informatik.uni-mannheim.de/rdf-validation/?q=node/424

this is a very general requirement.

Karen: we have a sort of hierarchy.

  • we may have to do clustering.
  • If we consider 'core' (as in 'Dublin core') we may produce a core of patterns to present to users.

Evelyn: i agree it would be useful to have an additional view

  • that people can understand the granularity of requirements.
  • On the other It would make it easier to compare requirements and use cases if we have details.
  • Broad requirements would have manu UCs linked to them. Even several UCs of a same case study

Karen: it sounds like there is a possibility to look for generalizable use case.

Antoine: middle-out approach? With typical requirements that can be either generalized or specialized?

Karen: yes, and we'd need to find a way to indicate the level.

Evelyn: we need to work on the classification.

Antoine: Karen it would be good to see what the W3C people think

Karen: hopefully it will come out. This is already what Eric start to say. I will make sure to ask if it doesn't.

Evelyn: it could be good if we could see the latest comment in the display.

Kai: if you think something would enhance the DB, please tell!

(starting to go through reqs at http://lelystad.informatik.uni-mannheim.de/rdf-validation/?q=requirements/requirements-comments)

Karen: we don't have a 'comment' view that's only for the DC comments.

Requirement 1 has no comments. Also not included in Eric's List. Karen will check

Req 10: we could merge data and object property

Evelyn, antoine: agree.

Difference between data and object property is also in other requirements. If we do not find a reason for this difference between object and data properties, we could merge the requirements

Req 100: General Q, that will prob come up at W3C meeting: How do our requirements fit with existing RDF functoinality. OWL & Inferencing, SPIN & SPARQL as examples.

Karen: Quotes Kai often as saying "may not be heading toward one way of validation, but using the validation that works best for our data."

Kai: Some people already using specific systems shouldn't be told to change. Can't tell them, "use something different." Needs to allow flexibility for Tool / Language cho

We should be able to highlight the specificities of each language and let people decide what they want to use. We can use DSP to at least define things from a more abstract level.

Can we mix constraint languages? (question in Thomas dissertation)

Karen: EricP shows examples specifiying requirements and the routine used to validate those. We could use this way of expressing things.

Kai: what do you mean by requirement then? For me it is still a constraint. We need a formal way to define a constraint.

Eric, can you post the link to the shapes demo that you showed me?

http://www.w3.org/2013/ShEx/FancyShExDemo?schemaURL=Examples/Issue-simple-annotated.shex&dataURL=test/Issue-pass-date.ttl

Index of examples: http://www.w3.org/2013/ShEx/Examples/

example failure http://www.w3.org/2013/ShEx/FancyShExDemo?schemaURL=test/Issue-js-test-date-triple.shex&dataURL=test/Issue-fail-date.ttl&colorize=1

Validating an "issued" shape. Validation failing because, in schema there's callouts validating that issue date & modified date are in the right order

Call-outs are to semantic actions in other languages. This is calling out to sparql to test that reproduced on is less than reported on:

 %sparql{ ?s ex:reportedOn ?rpt . FILTER (?o > ?rpt) %}

Kai: Formulation of constraints should be part of the data model. Intuitively understandable (but "intuitive" is subjective)

- Extensibility is already covered in two requirements: R-106 (Extensible Constraint Language : http://lelystad.informatik.uni-mannheim.de/rdf-validation/?q=node/137 ) & R-112 (Extensible Constraints: http://lelystad.informatik.uni-mannheim.de/rdf-validation/?q=node/143 )

- In Eric's exmaple, the Schema is the documentation.

Q from Karen: Do we need a "more human facing" language than that schema language?

Kai sees this as what we mean when we talk about DCAPs. Doesn't specify the technology to be used.

Kai: Perhaps comments still needed

Eric: First example has comments: http://www.w3.org/2013/ShEx/FancyShExDemo?schemaURL=Examples/Issue-simple-annotated.shex&dataURL=test/Issue-pass-date.ttl

Kai: Concern about code and comments getting out of sync if they are maintained separately.

Corey: shex can contain comments; worry about extensions because those could be in different languages and how can you document them?

Kai: when you move from your schema to code, you can't explain to humans.

Eric: there will always be something outside of your core expressivity; find the line between complexity and human expressivity

irc.w3.org#shapes to follow read-only onThurs & Fridyay

w3 rules will not, for example, compare dates - so we have higher expressivity requirements than w3 is likely to meet.

4. UCR-Deliverable

Are there comments left for the first the deliverable?

Comments from Karens Mail (Oct 1, 2014) on EDM use cases:

Suggestion to change wording.

Now:

1. Some EDM classes imply the use of properties. If the class is used these properties should be used.

2. EDM provides a list of mandatory properties per classes. However, there are some conditions on certain classes requiring the use of at least one of the mandatory properties."

Better:

1. Certain EDM properties are required when there is a subject that is an instance of a particular class."

Note: The comments affect use case descriptions in the database. Should we move the discussion there so that those who have written the use cases can change the wording?

Note from Evelyn that Comments on the deliverable should be in by end of October

Karen sends an mail to remind people to comment

Finalisation by next week

5. Next steps

ONGOING: indicate which next steps you think are important, and which you are willing to work on.

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, x, x] [Karen, Evelyn]
  • Go through remaining case studies and add use cases and requirements to requirements database [] [] (Antoine: is it the same as ' read through other case studies' below?)
  • Compare requirements and capabilities of the DSP; what's missing from the DSP? is anything in DSP not needed? [x, x,x, x, x, x] [Thomas] [Karen]

( Informal list being created at: http://wiki.dublincore.org/index.php/RDF_Application_Profiles/DSPanalysis#DSP_for_RDF

  • Read through the other case studies and see if there are any requirements that we haven't noted yet [ x, x] [Karen has started]
  • 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, x] [Karen,Thomas]
  • Definition of an RDF application profile [x, x,x,x, x, x, x] []
  • Create a few light-weight APs that people can use as examples/templates [x] [] (Antoine: is it more than 'develop a light-weight AP'?)
  • Implement an automatic vaidation of each constraint expressed using the redefined DSP [x, x] [Thomas]
  • Go through remaining of requirements according to Eric's recommendations [x] [Thomas] (Antoine: is it different from the two first bullets?)
  • Go through remaining of requirements classification according to Karen's and Eric's recommendations [x, 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, x]
  • Is our goal to fix the DSP? (Antoine: I think all the work currently happening goes a long way at identifying possible flaws of DSP and identifying solutions to meet the same requirements than DSP in the RDF world, which is a first step)
  • Is our goal to create a standard for application profiles [x,x]? (antoine: perhaps we would position ourselves as working on 'best practices' first: e.g. how to use ShEx/SPIN/whatever to represent typical constraints in APs)
  • 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,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,x]