W3C

- DRAFT -

Provenance Working Group Teleconference

12 Jul 2012

Agenda

See also: IRC log

Attendees

Present
pgroth, +1.661.382.aaaa, Luc, Satya_Sahoo, jcheney?, Paolo, Curt_Tilmes, +1.518.276.aacc, tlebo, +1.818.731.aadd, CraigTrim, sandro, Dong, khalidBelhajjame, stain
Regrets
Simon_Miles, Tom_DeNies
Chair
Luc Moreau
Scribe
James Cheney, jcheney

Contents


<trackbot> Date: 12 July 2012

<Luc> Scribe: James Cheney

<pgroth> do we have a scribe?

<jcheney> I volunteered...

<CraigTrim> I am aaaa

<jcheney> scribe: jcheney

Admin

Minutes: http://www.w3.org/2011/prov/meeting/2012-07-05

<GK> zakim ??p17 is me

Luc: Suggest postponing approval until next week

Paul: Fine

Subtopic: Actions

http://www.w3.org/2011/prov/track/actions/open

Paulo has not done 98,97

<pgroth> i continue to be a bad person

Curt: will do action Zakim Zakim 101 after LC releases

pgroth: will do action pgroth 102 later

Curt: will do action 101 after LC releases

Release of documents

Luc: Many reviews in. Are any outstanding?
... No? Thanks to all reviewers.

<pgroth> +1 to all the reviewers

Luc: A number of technical issues raised, most resolved now. They are:
... Mapping between prov-o and prov-dm
... raised by Graham
... Tim noted that there are hyperlinks showing the mapping
... Luc suggested a table suggesting the mapping

<Luc> http://dvcs.w3.org/hg/prov/raw-file/default/model/prov-dm.html#prov-dm-to-prov-o-and-prov-n

Luc: table is at end of document
... Graham, comments?

<sandro> (if you follow the URL, then press enter in the URL bar, you should get the table. at least I do in firefox)

GK: Table seems to do the job, modulo editorial (post LC) issues

<satya> Are these cross-references between documents or mappings?

GK: regarding Tim's comments, the hyperlinks cannot be dereferenced on paper
... not clear that they're links unless reading on screen

<tlebo> @GK, I've rephrased it to "alternate as in <a>prov-dm</a>"

GK: table does it better because it shows where single DM concept maps to multiple terms in PROV-O

<tlebo> +1

<tlebo> +q

tlebo: Rephrased links to DM within cross-sections in irc above
... Is rephrasing more natural?

<tlebo> as in http://aquarius.tw.rpi.edu/prov-wg/prov-o#wasEndedBy

GK: Need to look, but don't thikn it's a blocker.

<pgroth> so it's editorial

<tlebo> sure, it's not a blocker.

Luc: Can always refine this post LC
... Is this addressed?

GK: Yes

<satya> Agree - but I think this table should be called cross-references rather than mappings

<tlebo> +1 to rename "mapping"

satya: This is helpful, but should call it a cross-reference table to avoid connotations of "mapping"

<tlebo> "alternates" :-)

<pgroth> it's titled "Mappings to PROV-O and PROV-N"

<GK> @satya - I tend to agree - "cross reference" is more neutral

Luc: Satya, can you review and come back with comments?

<tlebo> bad naming "Table 8 ◊: PROV-DM Mapping to PROV-O and PROV-N"

satya: Yes

Next issue: Security section, raised by Graham

subtopic: Security section, raised by Graham

GK: There are security considerations in multiple places, should be brought together
... so they're easy to find and review

<tlebo> -1 in Rec, +1 as Note.

GK: prov-dm seems to be the appropriate place, with cross-references

Luc: Should this be done before LC?

GK: Beneficial for it to be in LC, collecting what we already have.

Luc: Security is mentioned in PROV-AQ, but some of it is irrelevant to DM. Do we need more?

GK: No, but it should be there in the document to attract feedback on security

tlebo: Surprised this is coming up just before LC, with no discussion over past year

<pgroth> +q

GK: Should have raised sooner, but did not see big picture
... also W3C has different culture about security
... but for provenance it is more important

pgroth: reasonable to make a section in PROV-DM intro that addresses security

<Luc> @pgroth not in intro, but as section at end of document

<Curt> Does the security section really change the specification, or is it more editorial/discussion? If so, could that be added even after LC?

pgroth: Graham is saying we should put it in core document to ensure it is seen/raises issue

Luc: Answering Curt: put it in before LC so we get feedback.

<GK> @curt it can be changed later, but my point is that by having it in last call reviewers will be prompted to think/comment about this.

tlebo: Better suited as best practice rather than part of spec

<zednik> +1 to security in best practices

tlebo: but if there is existing narrative that can be added in that is ok too

Luc: RDF concepts doesn't discuss security
... why needed in DM?

GK: Need may be too strong
... but because of specific role that provenance plays in establishign trust, worth drawing attention to security considerations

<tlebo> @GK, but we're not IETF, we're W3C.

GK: was looking at elements of IETF process where every spec must mention security
... because many problems can arise
... not part of w3c culture but should be more so in future

<Paolo> but, what are these security considerations? I think I miss the point

<tlebo> "good thing to think about" suggests Note.

<Paolo> wrt DM I mean

<stain> sorry I am late

<Luc> See http://dvcs.w3.org/hg/prov/raw-file/default/model/prov-n.html#media-type (section 6) subsection security considerations

jcheney: qustion: is it normative or informative?
... observation: provenance isn't magic fairy dust, we should make this clear

Luc: informative probably ok, Graham?

GK: informative probably OK
... if others feel this is unnecessary, will back off, but wanted to raise it

Luc: How about if we take security considerations from prov-n and prov-aq and transplant to prov-dm.

<pgroth> fine with me

GK: Works for me.

<tlebo> tyep it out?

Luc: Any objection/discussion?

zednik: We aren't developing communication protocol, so security feels out of scope
... like SKOS
... security should not block or even necessarily be part of a note

<GK> @stephan security considerations apply to data as well as protocol - hence they appear in media type registrations

Luc: plese read sectionlinked on IRC

<tlebo> Security considerations is there to suit IETF, that's the only reason it is there.

Paolo: Reading section, still unclear what is going on. Agree with stephan that security seems out of scope
... Can be part of Prov-AQ, but seems like a disclaimer: don't necessarily trust data expressed in this vocabulary.
... Seems like this goes without saying.
... Didn't see it earlier, don't see what it says

hook: Security considerations seem domain specific
... not always needed but within earth science, security is a consideration

<stain> http://www.w3.org/TeamSubmission/turtle/#sec-mediaReg has a very similar section

hook: agree with stephan that it is domain specific and not part of vocabulary

sandro: Sympathetic to claim of being patronizing - have wanted to say something that tries to be useful
... Could say less, or that considerations are domain specific or out of scope

<Paolo> sorry maybe it's just me not being familiar with the W3C / IETF culture but I find this is out of our scope

<stain> but I think that is mainly part of the IETF registration.

<tlebo> security in http://dvcs.w3.org/hg/prov/raw-file/default/model/prov-n.html#media-type and ONLY in http://dvcs.w3.org/hg/prov/raw-file/default/model/prov-n.html#media-type (to suit IETF)

Luc: We should have it for media type registration no matter what

<Paolo> if it's a req, then so be it, but... can we remove phrasing like "inferences of potential medical treatments would likely require different trust than inferences for trip planning."

<stain> I would also propose to leave it in the PROV-N registration as it is.

<stain> hehehe, yes

pgroth: Need to leave it in PROV-N, could draw attention to it in email announcements.

<stain> Paolo: that's stolen right from the Turtle spec!

pgroth: with pointer to where it is

sandro: could say this is a building block for security, not claim that it is secure itself

<pgroth> @stephan that's not right

<pgroth> that's in prov-aq

zednik: Need to look at media type section, but talking about security we can just leverage existing security specifications

<pgroth> were not talking about it here

zednik: why can't we use common mechanisms

<Paolo> @Stian that's no justification, right? copy and paste bad paragraphs doesn't make them better :-)

Luc: already says that; just says "use common methods/common sense"

<pgroth> arg

<GK> It is.

<GK> in PAQ

<pgroth> it's in PAQ and PROV-N now

<stain> Paolo: so we can refine it - removing other things like IRI overlap concerns sounds like "This is not an issue in PROV-N" - but really PROV-N has almost all the same issues as Turtle

zednik: Then seems sensible to put it in PAQ which deals with transmission

Luc: Asked for feedback on this section last week.
... Looks like there is not a consensus to move this to prov-dm
... any objections?

<pgroth> yes

<tlebo> +1, stays where it is.

Luc: (to keeping as is)

<Paolo> I am not opposing moving it BTW -- but I now realize I have comments on the content, which I will raise

GK: Given lack of support, not pushing for it

Luc: Can add something later; this is informative anyway

Subtopic: Collection membership

<pgroth> charset?

Luc: At f2f3 decided to move dictionaries to note, keeping collection and membership.
... interpreted this as keep "membership" as it was

<GK> @paul - re charset - I now have a recommendation from Ned Freed to always require charset=utf-8 parameter - forwarded to list.

Luc: to align with PROV-O, this would require making membership qualified and supporting n-ary membership
... Tim updated ontology to fit (Membership subtype of Influence)
... But at f2f3 it was not agreed that membership is a derivation or influence

<tlebo> POI: the prov-o terms involved: EmptyCollection, CompleteCollection, IncompleteCollection, qualifiedMembership + Membership

Luc: Several solutions were explored (see agenda)
... Only workable option at this point seems to be binary membership
... as suggested by some reviewers

tlebo: related terms are as above
... what should we do with them?

Luc: proposal would be Collection, EmptyCollection, and hadMember relating collections to entities

<stain> one collection to one entity

pgroth: This doesn't mean that we can't have something more complex when we move to dictionary, if desired

<tlebo> so, we have ONLY: Collection, hadMember, and EmptyCollection (and nothing else)

pgroth: Interpreted f2f3 resolution as "we want a simple collection/membership"

<tlebo> +1 #pgroth that was my impression - keep it simple, no qualification

tlebo: That seems fine.

<tlebo> @luc, easier to remove than to add.

Luc: Any opposition?

Paolo: Not opposition, but set notation can be syntactic sugar for binary membership. We should avoid tight coupling between prov-n and prov-o

<stain> @Paolo, right, without the attributes/id of the membership we don't need the entity sets in PROV-O (as there is no qualification)

<tlebo> @paolo, not sure I follow, if it influences how prov-o should look, please let me know.

<Luc> accepted: we have ONLY: Collection, binary hadMember, and EmptyCollection

<Paolo> @tlebo: no it doesn't it's all fine -- I just thought hadMember(c, {...}) is acceptable syntax that is compatible with the binary nature of hadMember

<Paolo> not bih deal

subtopic: character set optional parameter

GK: Commented on media type registration in prov-n
... overtaken by events, due to new rfc changing rules on text media type registrations
... rules changing to deprecate US ASCII being default, and avoid default charsets

<stain> latest response from http://www.ietf.org/mail-archive/web/apps-discuss/current/msg06676.html says

<stain> Then my suggestion would be to make the charset parameter mandatory, with the only legal value being utf-8. The alternative would be to omit

<stain> it and specify utf-8 as the default, but as I said, that's not likely

<stain> to interoperate well.

GK: asked IETF and response is (Ned Freed) for PROV-N, safest thing to do is always require a charset parameter set to UTF-8
... least likey to cause compatibility problems

<sandro> GK, what's the RFC?

<sandro> (interesting news, makes sense)

<Luc> charset — this parameter is mandatory. The value of charset is always UTF-8.

<stain> @sandro: RFC 6657 - see that mail archive link

Luc: Are we OK that this text will be adopted?

<stain> +1

GK: Yes

<Luc> ACCEPTED: charset — this parameter is mandatory. The value of charset is always UTF-8.

Luc: This concludes technical issues. Any others?
... Proceed to votes.

sandro: For LC, please add name of organization after vote (one vote per organization)

<pgroth> and can chairs vote?

<sandro> (yes, chairs can vote)

Luc: Do people have objections to the four proposals on agenda?

<stain> @khalidBelhajjame are you going to vote or me?

<Luc> PROPOSED: publish PROV-DM as Last Call Working Draft

<satya> +1, IE

+1 (University of Edinburgh)

<pgroth> +1 VU University Amsterdam

<sandro> +1 (W3C)

<GK> +1 (Oxford U)

<zednik> +1 (RPI)

<Dong> +1, Univerisity of Southampton

<Paolo> +1

<khalidBelhajjame> +1 (University of Manchester)

<Curt> +1 (NASA)

<hook> +1 (IE)

<Luc> +1 (university of Southampton)

<Paolo> +1 (Newcastle Uni)

<dcorsar> +1 (University of Aberdeen)

<pgroth> southampton twice!

<stain> DUPLICATE ORG - +1 (University of Manchester)

<pgroth> :-)

<khalidBelhajjame> @Stian, I think you can also vote, I don't think we have one vote per instituion, or is it the case?

<Luc> ACCEPTED: publish PROV-DM as Last Call Working Draft

<Luc> PROPOSED: publish PROV-O as Last Call Working Draft

<satya> +1, IE

<pgroth> +1 (VU University Amsterdam)

<Curt> +1 (NASA)

<GK> +1 (Oxford U)

<khalidBelhajjame> +1 (University of Manchester)

<zednik> +1 (RPI)

<stain> +1 (University of Manchester)

<dcorsar> +1 (University of Aberdeen)

<Dong> +1, Univerisity of Southampton

+1 (University of Edinburgh)

<sandro> +1 (W3C)

<hook> +1 (IE)

<Luc> +1 (University of Southampton)

<Paolo> +1 (Newcastle Uni)

<Luc> ACCEPTED: publish PROV-O as Last Call Working Draft

<Luc> PROPOSED: publish PROV-N as Last Call Working Draft

<khalidBelhajjame> +1 (University of Manchester)

<satya> +1, IE

<Luc> +1 (University of Southampton)

<pgroth> +1 (VU University Amsterdam)

<GK> +1 (Oxford U)

+1 (University of Edinburgh)

<stain> +1 (University of Manchester)

<Curt> +1 (NASA)

<zednik> +1 (RPI)

<Dong> +1, Univerisity of Southampton

<sandro> +1 (W3C)

<dcorsar> +1 (University of Aberdeen)

<hook> +1 (IE)

<Paolo> +1 (Newcastle University)

<Luc> ACCEPTED: publish PROV-N as Last Call Working Draft

<Luc> PROPOSED: publish PROV-Primer as Working Draft

<Dong> +1, Univerisity of Southampton

<sandro> +1 (W3C)

<GK> +1 (Oxford U)

+1 (University of Edinburgh)

<khalidBelhajjame> +1 (University of Manchester)

<Curt> +1 (NASA)

<stain> +1 (University of Manchester)

<satya> +1, IE

<pgroth> +1 (VU University Amsterdam)

<stephenc> +1 (legislation.gov.uk)

<dcorsar> +1 (University of Aberdeen)

<zednik> +1 (RPI)

<Luc> +1 (University of Southampton)

<hook> +1 (IE)

<Paolo> +1 (Newcastle University)

<Luc> ACCEPTED: publish PROV-Primer as Working Draft

<Paolo> clap clap clap

<sandro> +1 round of applause :-)

<pgroth> congrats everyone

Publication date

Luc: Simon is ready, PROV-DM mostly ready. PROV-O?

<pgroth> +q

tlebo: Producing valid HTML and most links confirmed. A few hours work.

Luc: Cannot publish next week, but can request for pub following week.

pgroth: If we make request this week, good because next week we should work on blog/announcement for LC

<pgroth> yes

Luc: Publication Tuesday July 24, make request today?

<Luc> accepted: publication date is July 24

sandro: confirms this is not a transition request. Only formal step is need to post to chairs@w3c.org

Luc: On day of publication?

sandro: right after is probably best so that links wokr
... right after is probably best so that links work

Luc: Review period, hoped at f2f3 to release by end of july and review period ending mid-september.

<Luc> 2012-09-12???

Luc: Suggest september 12?

pgroth: Think this will cause pushback. What about the 18th? Let people have 3 weeks in not-August

sandro: 18th is reasonable too

<Luc> accepted: end of review 2012-09-18

pgroth: Looking for volunteers to write intro blog posts on last call, particularly updates

<Luc> +1 on prov-dm

pgroth: Will write overview post but would be helpful especally for prov-o

<Luc> +1 on prov-n

<tlebo> @pgroth I'll add it to our agenda for Monday.

<khalidBelhajjame> @pgroth, when do you need that?

<pgroth> by the publication date

<pgroth> july 24

<khalidBelhajjame> @pgroth, thanks

<pgroth> no

pgroth: would like by 24th so that blogs & twitter can happen at same time

<Luc> http://www.w3.org/2011/prov/wiki/Tracking_Public_Comments

Managing public comments

<tlebo> I like process ;-)

Luc: Paul wrote tracking policy with input from Tim

pgroth: Have already seen that some comments start discussion, which overwhelms commenter with different responses
... Luc or nominated member to raise an issue on appropriate product, list issue on tracking public comments page, acknowledge issue to reviewer
... Start talking about it on wg mailing list, telecon etc.

<Luc> @sandro: is there a timeliness requirement for response?

pgroth: If questions raised for reviewer, contact them and ultimately respond to commenter

<Luc> @pgroth: can we nominate a member directly ;-)

pgroth: Only concern - is this too heavy on one person?

<pgroth> agree on the url

<pgroth> i'll update the wiki

GK: when acknowledging receipt, include link to issue page

<sandro> @luc nothing formal except we need the responses done before the next transition.

<Zakim> GK, you wanted to say rather than just the issue number, provide full link to issue page (maybe that's what is meant)

Luc: sandro, is there a timeliness requirement

sandro: We are supposed to be, but only requirement is have to be done by next transition

<GK> Isn't there a thing of asking the requester if their isssue has been addressed?

Luc: Polite to acknowledge, but don't have to conclude too quickly?

sandro: Would be polite to indicate if it takes more than a month

<Zakim> tlebo, you wanted to ask sandro about public-prov-comment@w3.org 's responses to WG members posting to it.

tlebo: List responds back to us thanking us for comments. Should we avoid responding to the comments list?

sandro: OK to ignore response and move on.

Luc: Put issue number in response so that issue raiser will be indexed properly

<sandro> (that is, okay to delete the email autoresponse from the list)

<Zakim> GK, you wanted to ask Isn't there a thing of asking the requester if their isssue has been addressed?

Luc: At some point need to go back and ask if issue addressed.

GK: Process used to require confirmation that raiser believes it's been addressed

sandro: Confirms that we need to record whether responder was satisfied

<pgroth> added

sandro: f yes, green box on final report
... if no, need to discuss on transition document
... need to track this.

Luc: Add this to process?

pgroth: Already done
... Does tracker track public-prov-comments?

sandro: no, not sure if it can

<GK> (would subscribing the main mailing list to public comments achieve this?)

Luc: can we nominate a non-chair member?

<tlebo> -1 to anyone

pgroth: It could be anyone in the group, subsequent discussion led by someone specific.

<GK> How about a rota of (say) pairs of people

<tlebo> too likely to fall on the floor (someone else will do it syndrome)

pgroth: Happy to do it until august,then we need someone else since I'm on vacation

<pgroth> is anyone here in august?

<GK> (I don't yet know my availability)

<Paolo> off most of August, sorry

<tlebo> @pgroth can we list the person responsible and their timeframes on the wiki?

<pgroth> sounds good tim

<tlebo> that gives us 2 weeks to find an Auguster.

<pgroth> will do

Luc: suggest wiki page with availability

<GK> (Would be happy to be one of (say) two people who look out)

<pgroth> I have to go catch a train

<pgroth> congrats everyone

<pgroth> really good result

<tlebo> http://www.w3.org/2011/prov/wiki/Tracking_Public_Comments - new section

<tlebo> bye bye

<pgroth> +10 to the editors

<tlebo> off for a beverage! yeah LC!

Luc: will handle rest of agenda next week; adjourned

<Paolo> byes

<GK> Bye

<Dong> bye

trackbot, end telcon

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.136 (CVS log)
$Date: 2012/07/12 16:10:01 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.136  of Date: 2011/05/12 12:01:43  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/suggestions/suggests/
Found Scribe: James Cheney
Found Scribe: jcheney
Inferring ScribeNick: jcheney
Scribes: James Cheney, jcheney
Default Present: pgroth, +1.661.382.aaaa, Luc, Satya_Sahoo, jcheney?, Paolo, Curt_Tilmes, +1.518.276.aacc, tlebo, +1.818.731.aadd, CraigTrim, sandro, Dong, khalidBelhajjame, stain
Present: pgroth +1.661.382.aaaa Luc Satya_Sahoo jcheney? Paolo Curt_Tilmes +1.518.276.aacc tlebo +1.818.731.aadd CraigTrim sandro Dong khalidBelhajjame stain
Regrets: Simon_Miles Tom_DeNies
Agenda: http://www.w3.org/2011/prov/wiki/Meetings:Telecon2012.07.12
Found Date: 12 Jul 2012
Guessing minutes URL: http://www.w3.org/2012/07/12-prov-minutes.html
People with action items: 

[End of scribe.perl diagnostic output]