minutes20150203
Meeting date: Feb 3, 2015
Etherpad: http://etherpad.wikimedia.org/p/dcmi-ap-rdf-03-02-2015
Attendees: Thomas Baker, Karen, Antoine, Corey, Kai, Evelyn, Valentine, Thomas Bosch, Stefanie
Regrets: Lars
Discussion of use cases and requirements
http://lelystad.informatik.uni-mannheim.de/rdf-validation/
https://etherpad.wikimedia.org/p/requirements_analysis
process for requirement merges - see https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=DC-ARCHITECTURE;704b0413.1411
New page for clean list: http://wiki.dublincore.org/index.php/RDF_Application_Profiles/Requirements
ACTION: Karen to complete new list of Reqs it as much as possible and call others to contribute --ONGOING
Karen: still needs to completed. E.g. point back to the database.
... Current description, title, number
... also 'action'. What is needed more?
Corey: 'action' should be included in 'description'
Karen: R-91 shows a difference
Antoine: I get the point
Karen: and explaining what to do with the issues - signal an error
Antoine: we could have it in the wiki, especially if it's not yet in the DB
Karen: do we need other things
Corey: not sure we should specify for signaling errors
Tom: many of the things are test. Anything beyond this may refer to the realm of applications.
Corey: for R-98 describing what the test is, is ok
... for other requirements saying what to do with signals could be too far
Karen: in w3c there's also a confusion between the language and the application of the language.
... e.g.: 'classes are disjoints' vs 'what to do once classes have been detected'
Corey: typically UC stop at the point of what you want
... one set of things to do when an error is detected
Karen: this puts a nice boundary for what we would have in our requirments
... we would have the descriptive part
Corey: +1
Karen: ok so we should be as descriptive as possible
... later W3C will develop the technology that implements this.
Tom: are there any requirements that can't be conceptualized as tests/checks (if the data matches the condition)
Karen: conceptually that's the case.
... but it's not necessarily how we've defined them
... e.g. R-210 doesn't have much of a test
... I think my 'actions' are your 'tests'
... do we need them here?
Tom: we should be clear about what's testable
Karen: description in the DB are all over the place
... we could have a unified approach in the wiki
Valentine: can't the test be expressed in the UC, not the requirement?
... it was a bit how we wrote them
[
looking at UC-Europeana-2 http://lelystad.informatik.uni-mannheim.de/rdf-validation/?q=node/338
and then UC-11 http://lelystad.informatik.uni-mannheim.de/rdf-validation/?q=UC-11-WRONG-PROPERTY-DOMAINS
]
UC-Europeana-2 says a lot about 'what if ...'
Stefanie: UC-11 says: 'do the test'.
... do we need this in the UC or Req?
Valentine: this was Corey's point : UC are more application-specific
Evelyn: it really depends on the application, what to do
... send a warning, correct the error, etc
Corey: when writing UCR, we should be application neutral
... but do we want to have a way for authors of AP to specify what the desired behavior is?
Karen: ok. But as DC do we want to go at this level?
Tom: I'm influenced by DSP and Sing. Framework
... DSP: define templates to match for data
... SF: stuff around it
... R-216. Is it a requirement for the language?
Karen: we declared it out of scope but there might be others here to question
Tom: general question/style
... requirement be expressed as concise sentences
... e.g R-32 (which is deprecated). use verbs '
Karen: for others we have this. for example 'check validity of IRIs'
Karen+Tom: the name of the requirement says what it is.
Karen: it's good to change them in the wiki, do it later in the DB
Tom: R-49 is good "Property occurs once per language tag"
Tom: ok I can do this
Karen: requirements to remove?
... the ones covered by cardinality R-68, R-69, R-70
Stefanie: agree
R-30 and R-32
Antoine: R-32 should be out. Pb with the DB
R-171 and R-171bis
Karen: still undecided
Karen and Tom re-formulating
Corey: I've got a case for thumbnail. Case is that the thumbnail has not disappeared
Tom: check the Http result codes (or a range thereof)
... related to unit testing - testable conditions
Corey: back to the boundary of the AP
... some stuff (checking the dimension of a JPG) may be externalized
Antoine: do this need to stop us? We can still postpone the two later.
Karen: W3C people asked if it was out of scope.
... they are still assuming a closed view
Antoine: so we keep them?
Karen: R-171bis is quite good
... R-171 needs a better definition
Tom: these are requirements for language?
Karen: this is what we're trying ot get at
Tom: req for a language could be such that an application could use the language for validate.
... e.g. 'specify the resource type'.
Karen: e.g. 'specify two properties as being disjoint' would work.
Tom: isn't disjoint too OWL?
Karen: disjoint existed before.
ACTION: Tom to review new list of Reqs, see whether the definitions make sense. Start after Karen has finished a first section --ONGOING
Antoine: Tom, is it ok with you? Enough input?
Tom: alright. I'll give input before next call.
Karen: anyone got time to copy the descirption from the DB into the wiki
Stefanie: I can try to do it
ACTION: Stefanie to copy-paste the descriptions (not the actions)
Karen: it would be great to have a list of requirements before the W3C meeting
Coordination with W3C Shapes group - role of DCMI group
charter: http://wiki.dublincore.org/index.php/RDF_Application_Profiles/Charter
W3C draft requirements list: https://www.w3.org/2014/data-shapes/wiki/Requirements
email: https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=DC-ARCHITECTURE;7d388645.1501
Karen editing W3C Data Shapes use case document
ACTION: Stefanie & Antoine to interlink DCAP Reqs with W3C Reqs and send result to W3C WG, after Karen and Tom have compiled the list of requirements
ACTION: put Thomas' analysis of BF on wiki
Admin - Next calls
2015-02-17 - Karen not available - at the W3C F2F - Tom also can't make it
ACTION: Corey to send a Doodle poll