- From: Brian McBride <bwm@hplb.hpl.hp.com>
- Date: Thu, 11 Sep 2003 13:29:25 +0100
- To: Dan Brickley <danbri@w3.org>
- Cc: w3c-rdfcore-wg@w3.org
Fixed up version for scraping. B 2003-09-05 RDFCore WG meeting (60 mins) Agenda: http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003Sep/0074.html Transcript: http://www.w3.org/2003/09/05-rdfcore-irc.html swebscrape:N3:python:http://www.w3.org/2001/sw/RDFCore/scripts/minutes2n3.py date: 2003-08-29 Roll call: Dave Beckett Dan Brickley(scribe) Jan Grant Graham Klyne Brian McBride (chair) Eric Miller Patrick Stickler Jos De Roo Jeremy Carroll Dan Connolly Pat Hayes Frank Manola Regrets: Mike Dean Review agenda: AOB: - status of mimetypes - status of jang's test case (re intentional datatypes) (we covered former not latter) Next telecon: 12 Sep 2003 1000 Boston Time for 60 minutes - danbri to chair - dave to scribe 5. Minutes of last telecon: http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003Sep/0003.html (2003-08-29) Approved. 6. Confirm status of completed actions: all Done. 7: Confirm Status of Withdrawn Actions Noting that Dave Beckett _did_ review Primer, these are marked withdrawn/done. 8: Doc Publishing status Specs are on their way to /TR/ labelled Sept 05. ericm: am hoping to see http://www.w3.org/TR/ reflect these ... all editors did a great job getting pubrules ready continuation of 2003-08-29#6 jang remove xmlsch-02 test cases. jang: 'they reflect our current position' ...ws test cases back at pt where ws counts and isn't processed... a ' 1 ' isn't a valid integer ...i'd rather hang onto these tests. brian: we discussed this before ...and decided to remove so jang you've held off as wg decision not clear...so let's leave as continued. jang: ..also, i created 2 test cases, intentional test case... 2 are in the test case but marked as pending @@ note completed actions, 2003-08-01#2 daveb sync with aaron on macintosh file type 2003-08-29#2 jang check for/create if nec the xsd:string-entails 9: Doc Publishing - script for cross references discussion of AOB re Mimetypes spec. gk: current doc has just expired brian: we had mail back ffrom Larry Masinter DanC: did we call for review in ietf-types gk: usually the call comes after the ID DanC: but we've done one before. did we do a call before? Brian: yes, we did. DaveB: yes, its in their archives DanC: so it isn't finished but we've started the process DaveB: ietf-types posting by aaron 2003-july-24 http://eikenes.alvestrand.no/pipermail/ietf-types/2003-July/000073.html gk: some changes needed following the existing review ACTION: gk to check with aaron on status of the rdf mimetypes draft gk: I offered to take it over last time... he seemed ok continuing the task then. brian: anything else on doc publishing? aside... ...i did hear a view expressed of dissapointment in progress we'd made. ...to me that's saying the glass is 10% empty not 90% full. we've come a long way getting through the LC work this year. significant progress, even if not quite where we hoped to be. jjc: with hindsight we should have published editors drafts during LC period brian: also re doc publishing... ...idea i had in mind was that all docs in shadow could be crosslinked, linkchecked, and then write a script to do the substitutions. ...also would save Peter and others time danbri: it would've made link checking easier this time em: scripting would've made sense DanC: don't do anything to encourage ppl to read editors drafts ...whatever is convenient for the wg is great. danbri: it'll indirectly benefit them as /TR/ publishing won't be such an ordeal. jjc: we have at least 3 more pubs ahead of us frank: folks like webont have close interest DanC: pls don't make that mistake... they're outside, they should learn our work via /TR/ brian: script seems like a good idea ACTION: danbri to investigation production of script for fixing up internal references danbri: "I'll see what I can do in a week, might give the ball back if not as easy as hope" note: editors to freeze their shadow-TR work until danbri has framework in place this week... 10: heads up re TAG rdfURIMeaning-39 and public-sw-meaning DanC: history... meeting in Cambridge tech plenary ...decided to take out social meaning, which we're just now publishing...SW CG was supposed to do something ...we asked tag to make an issue ...he made a request time passed ...tag adopted issue but busy, said 'well get to it evnetually' ...meanwhile a mailing list came out of budapest bof ...i'm supposed to set up some kind of a meeting ...patH has already done that ...others i assume want to be there: timbl, danbri... brian: basically there is now a mailing list for discussion of social meaning issue DanC: it would be in order for this wg to delegate someone danbri: is there any expectation this'll impact on rdfcore's rec track ambitions? ...or just a disucssion list DanC: both/either seem possible brian: a delegate... any volunteers? danbri, pat: interested in participating, but not sure re representing the group. pat: does 'delegate' mean representing group's view pat: i'm willing to volunteer so long as group gives me reasonably clear instructions brian: pat, your initial brief is to keep the wg informed DanC: also tell the social meaning anything they need to know factually about what's in the docs RESOLVED: to appoint PatH as RDF Core representative to \ public-sw-meaning, to provide factual information about RDF Core drafts\ and to keep the RDF Core WG informed of progress in that forum. 11: xmlsch-02 jjc: talking to dave reynolds about this... (and re poss of withdrawing the comment)... (so we owe him a reply to indicate we're not acting on it). his actual comment was buried in an implementation report. ...we should draft something to explain to him what we're now doing, and why. daver's report: http://lists.w3.org/Archives/Public/www-rdf-comments/2003JulSep/0076.html ericm: Regarding Danc's point re keeping social meaning group updated to previous M&S and current RDFCore work in this area - http://lists.w3.org/Archives/Public/public-sw-meaning/2003Sep/0001.html JosD: we also had same comments... ...3/4 of tests are not succeeding ...i u/stood that last week it was decided to obsolete test cases ...these things are not ideal several impl reports re test cases... ...either impls are wrong or test cases are wrong brian: summary of current situation? jang: we've remove the 'fudge' compromise wording... ...to remove the test cases themselves is to avoid the issue ...there either is, or isn't, an intereop problem. jjc: daver says this could be fixed in jena...[...] jjc: in conversaion, dave now seems to prefer current behaviour as most useful approach. ...not convinced we should fix the impls jang: thing w/ dealing w/ just the test case ...it's a legit LC question to say 'what is answer to this tc brian: orig when we went to LC1 we said 'spaces not allowed' ...but we got feedback saying 'tats not what we do' ...so we went for laxer compromise ...but then feedback from pfps and others said 'dont be so lax' ...so we're back where we were brian: two ways to be precise...one way is 'whats in graph must be in lex space of datatype'. ..'whats in the graph is a string, which when processed (...) is in lex space of datatype'. DanC: latter would require impls to pick up knowledge they normally get as a matter of course. patrick: i'm v v uncomfortable... where we incl ws processing in lex to value. ...several reasons. ...an app may choose to support xml schema datatypes. ...but not be an xml processor nor have those libraries handy .we're telling them they need to do something more than what datatypes are. a pandora's box. ...not just ws processing. ..current tools happy saying 1.0 int is a perfectly ok typed literal <- scribe missed detail of point. patrick: ...any lex form that an rdf processor can coerce into suitable form is ok...this seems sloppy, heuristic. ..shouldn't use tools in context not meant for. DanC: folks would read the xml schema specs, find the datatypes and that'd be enough... ..but if our specs ref xml schema and xmls says do ws processing [missed detail] patrick: ws processing is only defined in xml schema gk: meaning of spaces e.g. in " 3 "^^xsd:integer should be clearly undefined. jang: we are chartered to ... (re special ref to xml schema) gk: as i said in recent email, approach i'd suggest... follow approach that says meaning of a typed literal only when the lex form is in lex space of the datatype but not get into q of what happens when that isn't so, would allow processors to do w/s processing to make inferences that went beyond what core expects. jjc: i find patrick's args fairly compelling one extra point, .would introduce a new nromative ref on xml schema pt1. currently our only normative refs are on pt2 DanC: xml schema part 2 normatively cites part 1 anyway DanC: request a straw poll My latest position described at: http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003Aug/0348.html jjc: other thing came up when discussing datatyping... ...we wanted our datatyping mechanism general, not just w.r.t. xml schema datatypes. danbri: 2nded jang: we wouldn't have to have extra text if xsd folk said the rdf mapping is ... pat: we should be careful about doing xsd's job for them ...similar to the issue re xml literature normalisation ...could say the graph syntax requires spare ws to be rejected ...but impls could store in non-normal form danbri: sounds like softwre engineering in a w3c speca pat: we already do that re normalisation patrick: reason for ws processing is cleaning up variations ....clear from xmls spec that [mssed pt] brian: i don't beleive alternative is any less precise ...i started this re 'does anyoen wish to propose a change to current situation?' ...anyone need a straw poll? [none] ...is anyone willing to propose a change? gk: yes. to be explicit re saying meaning of a typed literal is when lex form is in lex space of the datatype (various): already do so gk: in which case i'm happy jjc: gk is correct, we are precise path: semantics require that an illformed literal isn't in val space brian: does it say it doesn't denote a literal gk: ' 3 ' isn't in lex space ..[missed] DanC: ah, you're saying ' 3 ' wouldn't be explicitly treated PatH: that would remove datatype clashes JosD: looking at xsd:string... it'd be valid as a string DanC: " oops! there goes all the value of these things!" ie. as PatH points out that this would remove datatype clashes so you couldn't observe inconsistencies ...this would undercut many benefits to users. (discussion of whether it is in lex space) JosD: ws facet on primitive datatypes -> remove wss brian: i think i hear an action that we need to verify our interpretation of the xsd spec ...patrick, would you want to do this? DanC: we have a status quo brian: gk was going to propose a change ...would be good to know if ' 3 ' *is* in the lex space gk: If ' 3 ' *is* in the lex space of xsd:int, then the value would be clear: same as '3'^^xsd:integer... that is, I propose my changte regardless jjc: we have an approved test case that says it isn't; if jos has new evidence pls submit to the list josd: fair, i'll take an action ACTION: josd to send msg re accuracy of the ' 3 ' test case 12: Datatype subclasses brian; some discussion on list DanC: The meeting noted that the WG owes Reynolds a response ...resolution 'datatype A is subclass of B "only if you/we say it is"' (ie. same as normal subclassing; taking out the extentional subclassing that we had left in in error) path: i'm happpy jang: we have test cases for this already path: specs published today will have that in them jjc: I propose the semantics of rdfs:subClassOf on datatypes as in the 5th Sept Working Draft danbri: 2nded connolly: abstain [no other abstentions.] So RESOLVED. 13: RDF and I18N (skipping 13 for now) 14: Outstanding comments ( DanC: jos, http://www.w3.org/TR/xmlschema-2/#integer 3.3.13.1 Lexical representation clearly specifies the lexical space, and there are no spaces in there. (scribe note: re prev item?)) jjc: i have a draft of a response i could circulate DaveB: from email he sent, he asked that we don't require nfc for xml literals ...but we changed things since january ...new draft no longer says that. jjc: says lex forms must be (this re Concepts) jjc: concepts requires lex forms to be nfc, incl. xml literal DaveB: ok in that case he is correct this is not in syntax doc jjc: we don't say it explicitly. lots of things we don't. path: 2 things he raised. internal consistency issue. also he makes a suggestion... DaveB: yup was just doing pt 1 jjc: we could do it the way he says ...that is, to produce warnings on plain literals tat are not in nfc ...we would need to talk w/ i18n guys about what they thought brian: do we need to think about what answer to this is? DaveB: i18n's best practice rec'n is ifc jjc: charmod encourages rejection of non-nfc data ACTION: jjc to prepare a response to peter on charmod re \ http://lists.w3.org/Archives/Public/www-rdf-comments/2003JulSep/0283.html [discussion of status of pfps comment on sectin 6.4 of concepts:] http://lists.w3.org/Archives/Public/www-rdf-comments/2003JulSep/0282.html gk: Concerning % in URI's, my last comment: http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003Sep/0055.html jjc: no response yet. ...i prefer 'no bytes to change' ...seen suggestion we add a note about this issue ...at one point i thought hard about this text... the closer this text is to what others have written, happier i am. gk: a note would be in order ACTION: jjc to respond to peter on %'s in URIs re \ http://lists.w3.org/Archives/Public/www-rdf-comments/2003JulSep/0282.html \ including a test case. brian: hmm shouldn't uri guys do the test case ...though we have the foo and bar test cases (test case in mailing list thread) DanC: best response, "In case not clear in Concepts, here is test case" The meeting closed.
Received on Thursday, 11 September 2003 08:55:32 UTC