Meeting of the DCMI RDF Application Profiles Group

June 10, 2014

Present: Karen, Antoine, Mariana, Tom, Stefanie, Evelyn, Diane, Gordon, Stuart, Corey, Adrian

Contents

Discussion on draft charter

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

Scope

Questions: What do we mean by RDF AP? Do we expect the result to be expressed in RDF? Or is this profiles for RDF data?

Gordon: I expect the AP to be in RDF and machine-readable

Adrian: +1

Karen: RDF doesn't allow to represent everything

Tom: +1

Mariana:+1

Stefanie: if we talk about XML validatation we need XML data

Karen: are we documenting AP and validating data

Antoine: I think RDF expression would be desirable

Karen: it seems we have consensus: machine-actionable is desirable, if we can do it in RDF then it's good

Antoine, Stefanie: +1

Agreed: must be machine-actionable.

Gordon: validation is really needed ... the validation rules should be at least encapsulated in RDF

Karen: we should try it soon and see if there are issues

Diane: Agreed. And if there are issues we should documented ... there won't be one solution anyway to express all this. Validation is not the only rationale

Karen: the w3c is going to officially convene its group on validation ... the DC group on AP has another component than validating, ie. documentation ... this aspect may not be part of the w3c work

Corey: Worth noting that the ShEx work, including charter formulation, is happening here: http://lists.w3.org/Archives/Public/public-rdf-shapes/

Tom: if everybody agrees it's about RDF data: everybody agrees it's about patterns validation/matching?

Antoine, Gordon, Karen, Mariana: +1

Some issues, for the future:

  • other organizations working in the same area: W3C (will soon have a working group)
  • focus: how much on validation rules, how much on documentation?

Karen: what is our key contrib?

Diane: documentation is important for our community. Documentation precedes data creation. How you decide what your data will work with, how you will develop your data design, and how you will document those decisions.

...The intellectual part of deciding what you're going to do. Expresses INTENTION. Karen: are we working on existing data or making decision on what data to be created is to look like?

Gordon: agree. Diane and I are working on what an RDA record could look like

... it's another use of an AP

... not expexted to act on existing linked data, but to express an intention. An AP should allow a user of the element set/dataset to know the uses envisaged by the publisher.

... This is expressed in the Singapore framework

Karen: you could have different APs working on the same data [Karen is that right?] [yes] Gordon: notion of 'core' so that people can exploit a dataset and elements e.g. RDA has core elements (properties), a subset of all RDA elements. Some elements are core when applied to specific types of resource. So we need an AP for core elements and another AP, based on the first, for core "if" elements, and so on.

Diane: documentation is the only place where you can express intention.

mariana: right!

Adrian: Expressing constraints in a machine-readable way and expressing your intention can go hand in hand. I'd like to have a machine-readable AP that works as documentation for human readers when expressed as HTML/RDFa.

Tom: If one looks at an AP as a set of patterns, could imagine having multiple APs for the same data providing multiple "views". For example, "strict" views of conformance and "relaxed" views. Multiple APs can provide different views of same data, e.g. a strict view for data creation, a relaxed view for users who wish to be more experimental. 

  ACTION: Antoine suggests to add "# Best practices for documenting the intention behind application profiles" as an area of work.

--DONE

Karen: Leaving charter vague is probably good. We're already getting into the actual work here, which we should try to turn into TG Tasks. 

  ACTION: Add patterns to one para.

  ACTION: Fix last sentence.

--DONE

Mariana: do we define in the charter what a RDF AP is?OK that is the first task :-)

Adrian: It could also be about presenting data/creating a web form, where things like presentation order of elements are important or indicating API endpoints to be queried for input into a specific field. (Haven't seen this in the charter. Is it out of scope?)

Antoine: I would expect this from the cases. I wouldn't rule it out, not fit in in advance in the charter either.

Related work

Tom: in related work, should we add Bibframe profiles? 

  ACTION: Add Bibframe profiles to groups to coordinate with. http://www.loc.gov/bibframe/docs/bibframe-profiles.html

Karen: I thought Bibframe was doing an application profile

Stefanie: Bibframe is in our cases

Tom: there is mechanism in Bibframe for creating APs, see http://www.loc.gov/bibframe/docs/bibframe-profiles.html

Karen: anyone with relationships w/ Bibframe so that we can invite them?

Stefanie: I'll talk to Reinhold and Lars

Lars is already in the group - it's about whether DNB wants to be a 'bibframe channel for this group'

Adrian: Why does Bibframe develop its own approach in the first place? They could work with us in this group. (I guess they needed profiles for building the Bibframe editor (http://bibframe.org/tools/editor/ ) and just went along...)

Gordon: You mean, like ISBD and RDA, who are working with our group?

Diane: you want an official bibrame connection? Or an informal, working connection would be good?

Tom: we should take what we can get :)

Antoine: there will be the DC14 special session organized by Mark - it would be a good opportunity

Karen; we will have other contact opportunities though - e.g. Ivan Hermann ... we should use the wiki so that we always things to show

Tom: I'm part of the data coordination group for W3C. DCMI work is always on the agenda there

... there will be someone representing the w3c work at the special session in Austin

Tom can be our liaison to W3C work.


Future tasks

Karen: now the aim will be to come some concrete tasks

... I suggest Antoine and I come with proposals for the group to discuss

... have more specific tasks than what the charter says.

Stefanie: we're still working on the 'requirement' table. This brings with specific needs.

Evelyn: it's on Google doc, we can put it on the wiki.

EDM validation rules and requirements (Europeana, DM2E, DDB): https://docs.google.com/spreadsheet/ccc?key=0AoN3jJ2PToabdFZDTzJmS2hNUHBMUTBHMzgzMmI5dEE&usp=drive_web#gid=0

Antoine: suggests to spend time looking at concrete cases and the requirements in the coming calls.

Adrian: I put requirements from our use case here: http://wiki.dublincore.org/index.php/OER-world-map#Draft_RDF_application_profile_.26_requirements_for_an_RDF_AP (see also https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind1405&L=DC-ARCHITECTURE&F=&S=&P=13277 )

Antoine: yes we need to refer to it from the wiki and spend time expliciing requirements from it It's already on the wiki, so in theory, we should come back to it soon :)

Adrian: Great. I'd be happy to work on an overview of requirements, indicating the use cases that name the different requirements and looking at existing approaches whether they meet the requirements. As indicated in my mail to the list, I am not sure about the terminology. It would be a good outcome if the group created some shared terminology that can easily be picked up by others. (I see some problems there with some existing DC terminology. ;-)

Use cases: add BIBFRAME

ACTION: comparison chart for DSP (Karen); look at SWAP and ISBD. (See if this was background for Matthias' tool)

Antoine: maybe not DSP as a use case per se

Evelyn: something to compare the use case needs to.

Stefanie: do we have real data based on DSP?

Mariana: DSP does not defines data....describes the AP patterns and constraints...

Karen: we have two APs based on it.

Antoine: approaching the end of the call

... in the minutes we noted several actions on the charter

... it's ok if we publish the charter after these actions? 

  [GENERAL AGREEMENT]

Antoine: call ended, next one in two weeks, same day same time.