jc: spanish arch in quay st would not let him in: would appreciate it if wg participants would not go there. Gavin Mckenzie sends regrets - ill --SE taskforce-- pt: mostly admin rather than technical areas: - promotion of the 2 notes out of draft - potential futures for the TF post feb - 1st note - ontology-driven architectures, fairly high-level - we feel close to completion; has had review, from Ben, mike, david (mike/david 1st version only) - sufficient review? jc: does not feel comments have been suitably addressed (read it on plane) - main issues are to do with tone and style. - 1st objective "to enthuse..." - not an appropriate objective. W3C notes inform, describe, not enthuse danbri: sees no problem with a note enthusing jc: agree, but does see a problem with a note that's a sales pitch - stylistic... danbri: setting out to enthuse W3C notes - sees no problem - important to get the tech used - education and outreach valid. - more concrete is if it fits with the charter etc (but not closely read) dbooth: read but no written review (yet) - will send later. - interesting research area. clear impression speculative and research rather than best practice - "wouldn't it be nice if..." gs: q - 2nd note is in a similar spirit, similar audience but more concrete and more technical detail - more acceptable? evan: a comment: objective of 2nd note is more to inform - easy transition from OO programming to OWL. Also some "wouldn't it be nice..." dbooth: my comments apply only to 1st, not read 2nd - objectives sound good jc: was happy with the second documemt gs: main problem with 1st is non-tech nature and no clear best practices behind it. 2nd doc is more down to earth. danbri: are there dependencies between the documents? could just one come out (given limited time) pt: no dependencies really gs: could the 2nd document go first? (have to rename it ;) danbri: perhaps the 1st document could go through SWIG guus: what is david woods's view on both notes? 2nd has more consensus for publishing in the group (with some editorial changes) dw: would tend to support that position - has read both documents but not in last few weeks guus: no consensus about this - 2 people say this dw: published doc in near term should be the 2nd andreas: university network is down. All we can do is wait...the university has been notified. Could take 1-8 hours. ralph: no particular comments, echo danbri's remarks - primer - person listed as editors who have not joined the wg - Holger - he needs to join the wg (he represents an affiliate) jeffpan: Ian horrocks has agreed to ask permission of the group to sign him up guus: he just has to fill in a form, no need for permission - he actually has 2 options ACTION: jeff pan to make sure he gets signed up Guus: primer - who is willing to comment on its current state? holger is the main editor. Evan: not been heavily involved in that paper pt: can commment editorially. All comments recieved have been fed in to the document. Do we need to appoint formal reviewers? guus: approint 2 reviewers outside the tf jc volunteers ACTION: js send review comments on SE Primer guus: some people listed who've not had much input - Mike and Evan - take this discussion offline jc: be good to be consistent between document for acknowledgements dbooth offers - but is same member as jc guus: proposes date of 25 Nov mike: cannot review by then ACTION elisa: review primer jc: 2 sreenshots - protege and altova semanticworks - implicit endorsement of these 2 products. protege is open source, no policy problem with that if we're ok as a group with implicitly endorsing it. But the other might be an issue if it's a commercial product? Personally if a product would prefer it not to be there ralph: the more important problem may be a copyright question - would have to check if there's a policy question ACTION ralph: check if there's a formal policy issue wrt implicit endorsement mike: thinks screenshots are important for informational reasons guus: but also gets outdated, would prefer not; prefer reference to tools pages danbri: thinks not necessarily an endorsement (contrasting product with a free thing) pt: takes us back to difference in style between 2 notes. What's the appropriate mechanism to make it real? ralph: phil and danbri are persuasive, and that's the position I will take internally ACTION pt: to check the copyright on the screenshots evan: 2 screenshots to show that the paper was not endorsing one specific product. issue of how many to include. Could include swoop instead. Looking for advice on which way to go. mike: use well-known open source ones (protege and swoop) and then mention commercial products guus +1 danbri: include suggests to other fora e.g. SWIG ACTION danbri: draft a bit of text pointing to SWIG fabian: include all these tools in ADTF page? pt: gets asked quite a lot: where are the tools: so to make it 'real' list more commercial products. Prefers listing products to 'endorsing' through screenshots dwood: still have to read to deeply into the document (the primer) to find the rationale for producing the document. If a product list then it should be complete, otherwise implicit negative endorsement. pt: reference to an externally maintained list prefered...? guus: an issue for the editors -> take offline - suggest address issue of screenshots before review jc: will send comments on the version just read ACTION: phil to make sure that an email is sent to the list about how the primer document will handle the listing of products guus: can put it on the agenda for 28th Nov to publish before end of the year ralph: will not be able to make 28th meeting jc: one last comment on implicit endorsement - there is an apprenidix listing tools - seems relevant. guus: move to ODA document - lots of effort, gone through review - are we going to continue this work? evan: one way forward to move it to a swig document - seems appropriate for that group dbooth: thinks it would be more appropriate ralph: what would the SWIG do with it? - if they can publish it we can publish it too. dbooth: doesn't represent 'best practice' and we are best practice group - the document is still in the research stage, speculative, does not demonstrate the value yet. danbri: hard to say that any document represents any collective will or consensus of such an amorphous group. Calendar one has lots of collaboration, lots of meetings, mailing list etc. So I was comfortable with this. It is in scope for SWIG but would like some evidence of wider participation, not sure how. Happy also to publish it in SWBP pt: stylistic points are fair. doc intended not to be research; content is aimed to be an intro to people who don't know about this area. Jeff: after f2f, checked with experts, did find some evidence pt: tf feels it's quite mature; not clear what to do with it now. guus: q of how much w3c endorsement IG and WG publication means - SWIG seems more appropriate - would like it to be published danbri: calendar was at end of n years of discussion; this paper is more like the start of a discussion. As swig chair can start mailing list threads; would be happy to have it published in SWIG tf: how long to get to publishing? guus: expect some discussion in mailing list; not consensus but revised version should reflect comments. tf: my preference would be to achieve note status asap jc: would prefer not to publish it, sorry to be blunt danbri: not good enough for a discussion paper? jc: perhaps as a workshop position paper - imo not appropriate for SWIG or SWBP note danbri: please everyone be polite on mailing list: rudeness discourages participation guus: read it on plane and big step forward from previous version, and important topic ralph: agrees with guus; would like it to be published; a good q if it's 'technical' or not dbooth: would like it published, just not in SWBP pt: is the proposed idea acceptable form POV of TF? ..yes - start review cycle in SWIG ACTION: phil/danbri to see how to proceed with discussion in the SWIG ACTION: jc send some more constructive comments guus: topic - future plans for this TF pt: TF members believe much more work to do - one more paper in area of composite identification plannned, not written yet - e.g. 2+ IFPs used together to provide identification - technical note Al: very important work, could be a 'best practice' danbri: was discussed at tech plenary. frustrating not to be able to use mulitple IFPs and langauge tags. Possibly rules work? because may start soon. jc: work in DL on this? jeff: yes - 2002, Ian Horrocks [scribe missed a few refs] danbri: not sure there's a best practice here because owl DL doesnt allow object properties as IFPs jeff: well known work here guus: interesting, tech problem, work has occured already in this area brian: doesn't seem to be a SE problem strongly; be good to see some work on it. guus: comes from the database community so is very relevant to SE although it is a more general problem pt: nothing else we've formally discussed; but appears to be a need for a community in this area in W3C. brian: doesnt seem that it needs to be in W3C pt: seems natural because the W3C technologies in this area jc: room for a WG reviewing RDF/OWL specs in this area - maybe this multiple keys thing would end up here guus: gueses not enough issues there danbri: various bugs / issues gradually accumulating, rather hard and not very exciting. evan: just to document these important issues perhaps? guus: seems outside scope of the SE tf -> take to discussion later today danbri: depending on the future of any future rules group, product would look like RDF 2...happy to wait for this guus: thank you phil for moving this forward - we have some consensus on the direction of the two documents. ---end SE TF-- --XML schema datatypes TF-- jc: the main issue is to do with equality of typed literals that come from different branches of the XMl schema datatype hierarchy e.g. zero apprears in a number of places - float, double, decimal 0 int = 0 decimal, but the rest from some points of view they are not comparable or all the same - question is which view to take - prev version - 3 positions - now 2 positions; editors' option - all the same - rationale - easier for the end user - feedback from HP - too hard to implement; Jena team expressed preference that zero as float, double, decimal should all be different - easier to implement. - in TF discussion held last night, evan made a separate point: taking the more conservative position that they were all different is less prone to error - also we noted that the note could also say that datatype properties would also have range specified to avoid these sorts of confusions jeff: the other half of evan's coment was that it was good to let the user decide if equal or not jc: yes, there was the observation that possible to write a sparql query - (section 3.5) example does an xpath equals that does the conversion as required; so can use sparql to compare the different values even if they are regarded as unequal dbooth: literals only or computeed values? e.g. a plugin or something jc: literals only dbooth: comment some more on Hp's opinion on the implementation problems? jc: e.g. we wanted to index by the value rather than the lexical form in jena - for efficient looksups you needed to know what to put in as the key inn the index - in the case where 0,0,0 are all the same -> rounding errors make a consistent key very tricky. - rounding errors are diferent depending on iof treated as a double, decimal or float guus: 0 is a special case I think; it is in maths; other cases are more compelling jc: paper uses 1.3 as example because of the rounding errors - quite consistent accross platforms because it's defined in xml schjema datatypes guus: idea: treat everything except 0 as diffrerent? jeff: leave it to the application; also we'd like to see peoples' preferences before going into details. jc: another option is *not* to make a decision at all - just leave the note with the 2 examples but not decide at this stage. dbooth: this issue of rounding errors is a well-known issue in computer science. This provides some reasonable basis for assumption that people will understand this difference pt: application point to be made: definition of precision is important, or wouldn't be useing a language of this precision danbri: often people from non-CS background will be writing queries etc pt: it's very important to explain the problem query even if not a solution (yet) jc: it's possible to address the well-known problem in the application layer, whichever decision is made - depending on the decison made get different entailments. (see 3H) jeff: we could provide a solution: make them all different; introduce more equality predicates for use by applications e.g. any literals with the same lexical form then have the same value. jc: possible to treat these the same in one application and differently in aother - that doesn't resolve the question of whether there's a logical entailment. And this seems to be in scope. "sameas" guus: the answer to 'sameas' is 'no' mathematically speaking pt: rule-based polymorphic typing is fine... evan: concern is cases like examples where 39.99999 is equal to 40. So that's wrong - 40 is a count so rounding rules are different. So would prefer to leave it to the application. pt: what about open systems where you encounter this for the first time? jc: addressed by having a range on the property. better than nothing. danbri: dependency on sparql? not to finish befire sparql. jeff: no dependency - example. jc: non-normative document so can have dependencies on non-normative documents dbooth: it's approx 1.3 but actual value is not benjamin: with respect to a range it is sameas jc: would like to make the decision here in the meeting. jeff: option 1: everything is different option 2: new predicate aldo: what is the intended use of the assignment to float or double etc? - try to insulate the naive user from making errors danbri: very sw architecture; is this an addendum to rdf core work? jc: non-normative but there is a status issue guus: if ever new OWL/RDF wg these sorts of notes will be considered jc: imo any future group may overturn it but would be unlikely to do so. jc: straw poll wording Example 3H: the premise triple eg:car eg:enginesizeinlitres "1.3"^^xsd:decimal does / does not entail / leave it to applications to decide eg:car eg:enginesizeinlitres "1.3"^^xsd:float all possible entailments will hold, not just some of them benjamin: the entailments being true don't necesarily entail the premise al: can I have a different sparql equals operator - a lexical one and a value one? jc: I believe so guus: be good to check this; and if it's not possible we should comment on last call. jc: a "D" entailment according to the RDFS semantics. Not OWL DL entailment. Could get similar owl things... straw poll: does 0 does not 9 applications 12 ralph: worries about interop if left to applications jc: is not happy brian: is there a difference between these two? jc: with does not then there's a formal entailment; in that case the application deciding would have to negate that entailment ACTION: jc explain non-montonicity and interoperability issues by email guus: more discussion required; very valuable piece. ---end XSD datatypes discussion--