Contents

DCMI RDF AP Task Group

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

Meeting date: Sept 16, 2014

Meeting link: https://meetings.webex.com/collabs/meetings/join?uuid=M7UN20T9GO54WPVQ2QKW762XXY-JV0D

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

Attendees: Karen, Tom Johnson, Valentine, Antoine, ThomasB, Tom Baker, Adrian, Stefanie, Evelyn, Kai

Regrets: , Corey

Agenda:

Tutorials

DC2014 Austin (October), half day: Tom, Stefanie, Kai, Thomas, Karen (coordinating)

outline at: http://wiki.dublincore.org/index.php/RDF_Application_Profiles/dc2014

one of the goals is to get people up to speed for Special Session (facilitated by Mark M): http://dcevents.dublincore.org/IntConf/index/pages/view/rdfAP

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

Karen: we have agenda, slides to start from

Valentine: I have shared slides with Stefanie.

Karen: you can post them to the list

Valentine: so far 17 persons registered. Great!


SWIB14 Bonn (Dec): Kai Eckert, Valentine Charles (Lieke Ploeger, Evelyn Dröge, Dominique Ritze, Antoine Isaac)

PM, generally 4h30

Perhaps involving Thomas (for practical stuff w/ a validation tool), Stefanie is also there

TBD after DC tutorial

Gathering requirements

requirements database: http://purl.org/net/rdf-validation

Progress report on DM2E/DDB/Europeana cases

merging of use cases, continuing the discussion from last call

http://etherpad.wikimedia.org/p/dcmi-ap-rdf-19-08-2014

Need to sort out terminology/understanding ACTION: Stefanie to send on the list 5 reqs she understands, and 5 that she doesn't.

DONE

Stefanie: problems: no definition, or requirements that seem the same

Requirements I think I understand


R-1-UNIQUENESS-OF-URIS

In my opinion it says that the the validation process must be able to check wether all URIs are unique.


R-68-REQUIRED-PROPERTIES

I think this means that the validation process must be able to check wether all properties, that are mandatory for the description of an instance of a class, exist. E.g. the use of the property edm:type is mandatory describing instances of the class edm:ProvidedCHO


R-28-Object-PROPERTY-RANGE

I think it means that the validation process must be able to check wether the value used as an object of a triple is an instance of a class that is allowed to be used in the range of the property of the triple. E.g. ex:myBirthday edm:occuredAt ex:myTelefon is not valid because the range of edm:occuredAt ist edm:TimeSpan and my telefon is not an instance of the class edm:TimeSpan.


R-72-RECOMMENDED-PROPERTIES http://lelystad.informatik.uni-mannheim.de/rdf-validation/?q=node/79

I guess this means that the validation process must be able to check wether properties, that are recommended for the descripion of an instance of a class, exist. But there is no description or definition of this requirement, so I can only guess.


R-45-Literal-Value-Range

Means that the validation process must check wether the value used as an object of a triple makes sense.


Requirements I don't understand


R-25-OBJECT-PROPERTY-DOMAIN http://lelystad.informatik.uni-mannheim.de/rdf-validation/?q=node/32 and R-26-DATA-PROPERTY-DOMAIN http://lelystad.informatik.uni-mannheim.de/rdf-validation/?q=node/33

I'm not really sure I understand this right. In my opinion the requirements say that the validation process must be able to check wether the value used as an subject of a triple is an instance of a class that can be used with the property of the triple. E.g. ex:myTable edm:begin ex:20thCentury is not valid because the edm specification says that edm:begin can only be used to describe instances of the class edm:Agent or the class edm:TimeSpan and my table is neither an agent nor a time span. But ex:myNiece edm:begin "1995" is valid, because my niece is an edm:Agent.

So if this requirements demand the validation of the domain, I need only one requirement and if not, what does they mean?


R-76-MAXIMUM-QUALIFIED-CARDINALITY-RESTRICTION and R-78-MINIMUM-QUALIFIED-CARDINALITY-RESTRICTION

I guess it means that the validation process must be able to check wether the occurence of properties describing an instance of a class correspond to the allowed occurence of this property describing one instance. I think R-76 talks about the repeatability of the property but I'm not sure where the difference is between R-68-REQUIRED-PROPERTIES and R-78-MINIMUM-QUALIFIED-CARDINALITY-RESTRICTION. And I can only guess what they mean because as in R-72 a definition or description is missing.


R-46-CONSTRAINING-FACETS and R-35-DATA-PROPERTY-RANGE

I don't understand the difference between these two requirements. Both say that it is necessary to check the literal value that is an object of the triple. Or not?


Problem with repetition at

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

ACTION: Thomas to check the bug.

Antoine: after the fix is fixed, then we should fix the DC requirements as identified by Valentine and Stefanie, we should ignore the non-DC ones

Stefanie: maybe after we can check the others

ACTION: Valentine and Stefanie to send a list of unclear requirements

Adrian: we should have examples in RDF,

Tom: for implementing, I'm going to second the request

Antoine: that may fall in my action on adding examples (formalized)

Adrian+Tom: ok

Adrian: but an easy example should help. Maybe not EDM.

Tom: a non-validating graph in Turtle.

Antoine: it will be hard to find a non-validating example for a requirement on recommended props

Tom: yes we might need several levels

Antoine: checklist for requirements

  1. examples (formalized if possible)
  2. defintion in natural language (avoiding abbrevations)


R-25 and R-26 look the same

Stefanie: same constraint

Antoine: for some constraint language it makes a difference whether the constraint is applied to OP or DP

Stefanie: example would help.

ACTION: chairs to ask on mailing list for shepherds for other cases, especially

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

http://wiki.dublincore.org/index.php/OER-world-map

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

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

Karen: we're going into a great deal of detail about EDM - maybe it would help to step back and look in the general sense

Antoine: still wondering whether we've got the aim right. Difficult to ask people to do something if we don't have clear examples

Karen: we can still ask. does the work on OWL/DSP from Thomas connect to the database

Thomas: for now there's no connection

Kai: I think there is relation between the two lines of efforts:

  1. one is analysis requirements and expressivity
  2. the other is more technical: expressing one constraint language in another language

Non-functional requirement on being able to validate constraints.

Antoine, Kai: we are now retro-engineering the requirements that guided the design of constraint languages like OWL, DSP, across languages.

Kai: we could extend Thomas' tool, a web-based implementation

Thomas: if you have data, you need one constraint to check

Adrian: AP in OWL for OER worldmap prototype: https://github.com/hbz/oerworldmap/blob/master/oerap.ttl <- I tried this with some data in the validator. It didn't work immediately. I will contact Thomas on how to make it work.

ACTION: Adrian and Thomas to solve the issue for the OER case for a demo during the next call.


Scope discussion: relation between the TG work and previous AP work

http://dublincore.org/documents/profile-guidelines/

http://dublincore.org/documents/dc-dsp/

http://dublincore.org/documents/singapore-framework/

Karen working on DSP in relation to RDF/OWL

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

Comments on it here and on the page would be welcome.

Demo by Thomas on what has been done with DSP in SPIN:

http://purl.org/net/rdfval-demo

Relation between DSP, OWL(2), SPIN, SPARQL, ShEx

All these languages overlap to a large degree, it's interesting to express the constraints that cannot be expressed in one language or another.

For each requirement one should be able to express the constraint in a constraint language.

ACTION: Antoine to send an email to the list suggesting to record example in constraint languages in the database.

ACTION: Antoine to do it for two easy examples and two hard ones, from Stefanie's list, and put it on the wiki.


First deliverable

From the charter: "Report on the current state, based on use cases gathered - first draft September 2014"

Suggested scope of the deliverable:

  1. Collected case studies, use cases (All wiki case studies are in scope, but they won't be worked out fully in time.)
  2. Requirements from the database used by our application profiles
  3. Short database description or description of the requirements collection?
  4. Links to the case studies on the wiki, case studies, use cases and requirements in the database

ACTION: Kai to find out what template is precisely needed

Kai: no template, but in the end all deliverable that need to be citable are created as pages on the DC site, just as the DC specs.

for drafts we should use the wiki. Use revision URL when citing in email, etc.

We still have ot find a place, to distinguish between formal specs and community publications.

Will be discussed in Austin

Evelyn: I will start in the wiki

Antoine: possible?

Evelyn: yes.


Coordination with W3C RDF Data shapes WG

[running item - nothing for this week, but keep in agenda]

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

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

AOB

Kai: join us in Austin! It will great.