Contents

DCMI RDF AP Task Group

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

Meeting date: Nov. 11, 2014

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

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

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

Attendees: Lars, Stefanie, Adrian, TomBaker, Antoine

Regrets: Mark M


0. Admin - Next calls:

- Nov 25

- Dec 9

- Dec 16

- Jan 6

Wanting to complete tasks more quickly: Karen & Antoine have discussed trying to make meetings more "Working Meetings".

Discussed possibility holding some 2-hour meetings.


1. Action items carried over from previous calls:

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

Karen: Add W3C accepted requirements comments to db as comments on existing requirements [DONE]

All: Comments on first deliverable (use case and requirements) [close off? stefanie]

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

someone??: complete these case studies:

http://wiki.dublincore.org/index.php/KIM-recommendations

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

http://wiki.dublincore.org/index.php/RFC-6906-Profiles


2. Discussion of use cases and requirements

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

First section: list of possible merges

All of these suggest merging of requirements that are identical for data and object properties.

Create a list of requirements with unclear names


"*" marks DC requirements

Thomas's list of merges (for data and object property requirements)

The ones in bold are also on the list that follows this one, by Karen

"*"R-10-DISJOINT-DATA-PROPERTIES (http://lelystad.informatik.uni-mannheim.de/rdf-validation/?q=node/17)

R-9-DISJOINT-OBJECT-PROPERTIES (http://lelystad.informatik.uni-mannheim.de/rdf-validation/?q=node/16, not in DC reqs)

--becomes: disjoint properties, on R-10

"*"R-11-DISJOINT-DATA-PROPERTIES-CLASS-SPECIFIC http://lelystad.informatik.uni-mannheim.de/rdf-validation/?q=node/18

R-12-DISJOINT-OBJECT-PROPERTIES-CLASS-SPECIFIC http://lelystad.informatik.uni-mannheim.de/rdf-validation/?q=node/19

what I meant with these requirements is that properties are only disjoint within some context which can be a class for example. Therefore, I won't merge them with R-10 and R-9. [Thomas]

We could rename them as R-X-CONTEXT-SPECIFIC-DISJOINT-PROPERTIES [Thomas]

ericp: global, or constraint on a particular class; context-sensitive disjoint properties


"*"R-26-DATA-PROPERTY-DOMAIN http://lelystad.informatik.uni-mannheim.de/rdf-validation/?q=R-26-DATA-PROPERTY-DOMAIN

"*"R-25-OBJECT-PROPERTY-DOMAIN http://lelystad.informatik.uni-mannheim.de/rdf-validation/?q=R-25-OBJECT-PROPERTY-DOMAIN

make sure that property foo is of domain X

a: make sure that foo has type X arc on it

b: invoke all of the constraints associated with X

both need to be added to DC requirements (find use case)

find an example to add

Corey's (contrived) example: Consider a graph that has a property with domain "Motion Picture", you now can infer that the subject is a Motion Picture. If you then have a requirement elsewhere in the AP that says "Motion Pictures must have Producers", you know to apply that requirement.

Relates to UC-5?


"*"R-35-DATA-PROPERTY-RANGEhttp://lelystad.informatik.uni-mannheim.de/rdf-validation/?q=R-35-DATA-PROPERTY-RANGE

"*"R-28-OBJECT-PROPERTY-RANGE http://lelystad.informatik.uni-mannheim.de/rdf-validation/?q=R-28-OBJECT-PROPERTY-RANGE

find an example to add


R-5-EQUIVALENT-DATA-PROPERTIES http://lelystad.informatik.uni-mannheim.de/rdf-validation/?q=node/12

OWL EquivalentDataProperties

R-4-EQUIVALENT-OBJECT-PROPERTIES http://lelystad.informatik.uni-mannheim.de/rdf-validation/?q=node/11

EquivalentObjectProperties*

Two or more properties that are equivalent in their semantics, and can be interchanged without changing the meaning of the graph

--R-?? add to DC requirements; connect to at least one use case


R-53-NEGATIVE-DATA-PROPERTY-CONSTRAINTS http://lelystad.informatik.uni-mannheim.de/rdf-validation/?q=node/60

R-52-NEGATIVE-OBJECT-PROPERTY-CONSTRAINTS http://lelystad.informatik.uni-mannheim.de/rdf-validation/?q=node/59

Becomes negative property constraints

if you have instances of a specific class, you do not have certain properties

Evelyn: we have these in our use cases: often properties that we do not allow

R-?? - connect that to DC use cases

Does this then duplicate DC use cases that we already have, but have given different names to? If so, do we keep both, with a "same as"?


"*"R-64-SUB-DATA-PROPERTIES http://lelystad.informatik.uni-mannheim.de/rdf-validation/?q=node/71

R-54-SUB-OBJECT-PROPERTIES http://lelystad.informatik.uni-mannheim.de/rdf-validation/?q=node/61

if you have a specific property for an individual, then this must have a super property to another individual

ericp: this is inferential? tb: or explicit

R-64 = UC Europeana 10 (http://lelystad.informatik.uni-mannheim.de/rdf-validation/?q=node/379)? ACTION: Evelyn will check

R-65-FUNCTIONAL-DATA-PROPERTIES http://lelystad.informatik.uni-mannheim.de/rdf-validation/?q=node/72

R-57-FUNCTIONAL-OBJECT-PROPERTIES http://lelystad.informatik.uni-mannheim.de/rdf-validation/?q=node/64

kc: punt to cardinality - do not add to DC requirements

? does cardinality actually cover the same range?

corey: there can only be one father resource associated with this person resource

... functional property means can occur any number of times, but all occurrences represent same thing

Karen example: FRBR expression can only express one work. If there are multiple things, you assume they are the same.

We will run into this when we get into merging bib data. This is the use case we would want for functional properties.

Evelyn: in EDM, you have requirement to have only one title, but you can have same title in different language

ericp: can't use this for that inference,

Not a DC Requirement at this time


4. AOB

make a longer call to discuss requirement merging and naming?

Agreed to keep to current schedule, but determine after next meeting if we need to add another meeting. Some agreed to a longer meeting. May need to poll.

An added meeting in early December would conflict with SWIB. Possible BOF at SWIB to discuss particular issues, since many active members of the group will be there.