minutes20140916
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
- examples (formalized if possible)
- 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:
- one is analysis requirements and expressivity
- 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:
- Collected case studies, use cases (All wiki case studies are in scope, but they won't be worked out fully in time.)
- Requirements from the database used by our application profiles
- Short database description or description of the requirements collection?
- 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.