Contents

DCMI RDF AP Task Group

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

Meeting date: Nov 25, 2014

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

Etherpad: http://etherpad.wikimedia.org/p/dcmi-ap-rdf-25-11-2014

Attendees: Thomas, Karen, Valentine, Antoine, Evelyn, Corey, Stefanie

Regrets: Adrian, Miika

1. Admin - Next calls

- Dec 9 - Dec 16 - Jan 6

option for BOF at SWIB: http://swib.org/swib14/programme.php -> find a time to discuss unclear wording w/ Stefanie, Karen, Valentine, Evelyn.

tutorial "RDF Application Profiles in Cultural Heritage"

Evelyn: we have a call tomorrow. Kai cannot be there. We have to find replacement especially on validation

Karen: I have a slide on this.


2. Use cases and requirements

Action: Valentine and Stefanie to send a list of requirements with unclear names

ONGOING: will be worked at SWIB

Action Karen: check why Requirement 1 not included in EricP's list; what is requirement E08

ONGOING: we have to see whether we include it. We can do it after work on our requirement.

completing case studies: - http://wiki.dublincore.org/index.php/CSC has been progressed by Miika (Main use cases defined) - other cases waiting completion -- http://wiki.dublincore.org/index.php/KIM-recommendations -- http://wiki.dublincore.org/index.php/RFC-6906-Profiles

Perhaps we will not get the last two ones. We've got plenty between the ones we have already and the ones at W3C.


3. Report on use cases and requirements

Action All: Comments on first deliverable (use case and requirements)

-> postpone until the discussion on UC and R themselves has progressed?

RESOLVED: we postpone work on report until the discussion on merging/naming of DC requirements is finished.

4. Coordination with W3C Shapes group

F2F meeting in February.

Karen: I prefer to write up an email periodically.

Thomas: what is the time of the call?

Karen: Thursdays at 2 Eastern Time, 8pm Central European

Antoine: we are still looking for a second representative.

5. Possible requirement merges

https://etherpad.wikimedia.org/p/requirements_analysis

Process: https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=DC-ARCHITECTURE;704b0413.1411


R-75 Minimum Qualified Cardinality Restrictions on Object Properties http://lelystad.informatik.uni-mannheim.de/rdf-validation/?q=node/82

R-78 Minimum Qualified Cardinality Restrictions on Data Properties http://lelystad.informatik.uni-mannheim.de/rdf-validation/?q=node/85

R-81 Minimum Unqualified Cardinality Restrictions on Object Properties http://lelystad.informatik.uni-mannheim.de/rdf-validation/?q=node/88

R-84 Minimum Unqualified Cardinality Restrictions on Data Properties http://lelystad.informatik.uni-mannheim.de/rdf-validation/?q=node/91

RESOLVED: Remove word "restrictions'


R-76 Maximum Qualified Cardinality Restrictions on Object Properties

R-79 Maximum Qualified Cardinality Restrictions on Data Properties

R-82 Maximum Unqualified Cardinality Restrictions on Object Properties

R-85 Maximum Unqualified Cardinality Restrictions on Data Properties

RESOLVED Remove word "restrictions"

RESOLVED: we keep qualified and unqualifed distinct

RESOLVED: we merge object and data properties

Karen, Valentine, Antoine: we don't have them as DC reqs, but they might be there already in fact, and overlap with existing DC Reqs.

[discussion on merging exact, minimum, maximum]

ACTION: Thomas to merge the cases

Matching to Use Cases: UC-Europeana-18: Presence of language tag http://lelystad.informatik.uni-mannheim.de/rdf-validation/?q=node/392

Corey: can we create a requirements that says 'should'?

Thomas: I think we have a requirement 'recommended properties' --> should be used

Karen: Quoting Tom J. from Austin -- Different levels of requirement. Degrees: "Important", "Should", "Good to have", etc. --> requirement 'validation levels'

Corey: strong requirements will be rare in DC world

Stefanie: EDM has some.

Corey: I like the idea of validation profiles for different use cases

Antoine: we can remove the 'validation level' from the requirements about data patterns. E.g. remove 'restriction' from R-75.

Should we specific allowed validation levels?

Karen: we should stay flexible. It's at level of DSP

Antoine: we might have DSP-level requirements in our list

Karen: yes, we'll have to check these.


R-90-EXISTENTIAL-QUANTIFICATION-ON-DATA-PROPERTIES http://lelystad.informatik.uni-mannheim.de/rdf-validation/?q=node/110

R-86-EXISTENTIAL-QUANTIFICATION-ON-OBJECT-PROPERTIES http://lelystad.informatik.uni-mannheim.de/rdf-validation/?q=node/105

definition: there must be a specific relationship to instances of specific classes example: ObjectSomeValuesFrom( :fatherOf :Man ) recommendation: existential quantification on properties [Thomas] if you have an instance of a class, e.g. father of son, must have at least one relationship with type "man"

Antoine: is it the same as R-75 with the minimum set to 1?

Thomas: yes, but it Requires reasoning.

Stefanie: periodicals and volumes; every volume must have a relationship to periodical These are OWL constraints

Corey: if you want to use OWL, use this..... in the DC requirements

Karen: Hoping to keep DC requirements simple. OWL Docs available if people want to move into OWL. Would be interested in seeing if entire DC set could be done in RDF-S; avoid OWL complexities.

RESOLVED: we keep them, but we link them to the "related" DC requirement (e.g. R-90 and R-78), and we encourage use cases to refer to the DC requirements unless strictly needed.

Karen: these things are different between OWL and RDF so we need to be careful. Need a grounding in description logic to understand OWL2. Large risk of misleading implementers.

Karen: we need examples for the requirements, that are testable with Thomas' tool.

RESOLVED: merge R-90 and R-86


R-91-UNIVERSAL-QUANTIFICATION-ON-DATA-PROPERTIES http://lelystad.informatik.uni-mannheim.de/rdf-validation/?q=node/111

R-87-UNIVERSAL-QUANTIFICATION-ON-OBJECT-PROPERTIES http://lelystad.informatik.uni-mannheim.de/rdf-validation/?q=node/106

definition: if a property is used then this property is only pointing to instances of specific classes (e.g ObjectAllValuesFrom( :hasDog :Dog ) --> someone having a dog must have :hasDog relationships to dogs if theres are :hasDog relationships)

recommendation: universal quantification on properties [Thomas]

Karen: Do we have use cases that can only be satisfied in this way?

Stefanie: we could look at use cases that are not yet linked to requirements.

RESOLVED: merge R-91 and R-87


R-93-DIFFERENCE-BETWEEN-CONSTRAINTS-ON-OBJECT-AND-DATA-PROPERTIES http://lelystad.informatik.uni-mannheim.de/rdf-validation/?q=node/113

+ 1 for deleting this requirement [Thomas]

RESOLVED: delete R-93


R-95-POSITIVE-DATA-PROPERTY-ASSERTIONS http://lelystad.informatik.uni-mannheim.de/rdf-validation/?q=node/115

R-94-POSITIVE-OBJECT-PROPERTY-ASSERTIONS http://lelystad.informatik.uni-mannheim.de/rdf-validation/?q=node/114

recommendation: positive property assertions [Thomas]

Do we have use cases that can only be satisfied in this way?

Thomas, Antoine: this is stating that some statement has been made

RESOLVED: merge R-95 and R-94