See also: IRC log
<Ralph> Previous: 2008-06-24 http://www.w3.org/2008/06/24-swd-minutes.html
Guus: This is the last scheduled telecon
PROPOSED to accept minutes of the last telecon: http://www.w3.org/2008/06/24-swd-minutes.html
RESOLUTION: to accept minutes of the last telecon
Ralph: Nothing we particularly need to talk about
<Ralph> meeting record: 2008-06-26 RDFa telecon
Ralph: On schedule for August proposed rec
Guss: We need to schedule a meeting for about that time.
<scribe> ACTION: [PENDING] Ben to prepare draft implementation report for RDFa (with assistance from Michael) [recorded in http://www.w3.org/2008/01/22-swd-minutes.html#action14]
Guus: what's the progress on getting the Note published?
Jon: I have updated the Status paragraph but didn't get a chance to send the notification
... Ralph should look at it
... Diego found some additional errors in the example document, which I'll fix right after the meeting
<scribe> ACTION: Jon and Ralph to publish Recipes as Working Group Note [recorded in http://www.w3.org/2008/06/10-swd-minutes.html#action03] in http://www.w3.org/2008/06/10-swd-minutes.html#action03] [CONTINUES]
<scribe> ACTION: [DONE] Diego to propose minimum RDFa metadata set for WG deliverables. [recorded in http://www.w3.org/2008/06/24-swd-minutes.html#action16]
[recorded in http://www.w3.org/2008/06/24-swd-minutes.html#action16]
Diego: see -> http://lists.w3.org/Archives/Public/public-swd-wg/2008Jun/0104.html "adding metadata with RDFa to W3C TR" [Diego 2008-06-29]
<scribe> ACTION: [PENDING] Ralph/Diego to work on Wordnet implementation of Recipes [recorded in http://www.w3.org/2008/01/22-swd-minutes.html#action20]
Guus: realistic timescale?
Elisa: almost done, just need to validate
... should have by next week
Guus: we may start reviewing between telecons, but will have to see how that works out
Elisa: several people have found the doc to be valuable
... we were going to include some recommendation about the SKOS namespaces
... but will figure that out once we've started reviewing
Guus: Antoine sent email on ISSUE-84
<Ralph> Proposal to postpone ISSUE-84 ConstructionOfSystematicDisplaysFromGroupings [Antoine 2008-07-01]
Antoine: considering that issue-84 is too complex to deal with in the time available
... issue-84 is borderline wrt SKOS application and I propose to postpone
PROPOSED: postpone ISSUE-84, reason given in message 0001 of July 2008
<Ralph> +1
RESOLUTION: postpone ISSUE-84, reason given in message 0001 of July 2008
Ralph: I'll update the issue list right now, no action needed
Guus: looking at ISSUE-86
SeanB: action on me and Alistair to compose some text, Alistair has seen
... suggestion is to follow practices from CoolUris and include in Appendix
... proposed resolution is to make no requirements but recommend authors should follow the recipes and CoolUris
Guus: ISSUE-72, ISSUE-73, ISSUE-75
aliman: just sent a mail suggestion some positions for each
... for issue-72, we make no statement
... for issue-75 suggest that we don't assert any property chains for exact match
<Ralph> exactMatch issues: ISSUE-72 ISSUE-73 ISSUE-75 [Alistair 2008-06-24]
aliman: issue-73, when we say related, we're saying there's an associative relationship, and from that perspective it's worth stating that they're disjoint
<aliman> http://lists.w3.org/Archives/Public/public-swd-wg/2008Jun/0097.html -> suggestions for exactMatch issues
Antoine: from the pint that we've already asserted semantics for matching properties
... I was afraid that Alistair's position was a step backward
... I don't have a strong objection but am uncomfortable
<Ralph> current specification of skos:exactMatch
Antoine: I support exactMatch disjoiint with related but not broadertransitive
aliman: i could live with not saying that exactmatch is not disjoint with any other property, but that users should check
edsu: no opinion about this
aliman: one of the difficulties is that we don't have any obvious use cases
Guus: that means we should follow the least commitment strategy
aliman: that means that we should say nothing formally on any of these issues
Antoine: would really like to make exactmatch transitive
Daniel: What are the arguments against saying transitive
<Ralph> We currently say "[skos:exactMatch] is typically used to indicate that two concepts are sufficiently similar that they can be used interchangeably in an information retrieval application."
aliman: making no statement allows people to draw their own conclusions
... if we _say_ that its transistive then we specify that you're drawing conclusions across mappings
Daniel: it would seem that you would want that to be transitive
aliman: I've never looked at the data, so that was my reluctance
Daniel: if there was another semantics for exactMatch then we should have another property
Ralph: I agree
edsu: but of course this may map across a number of concepts
... if it's transitive then there's bound to be drift
Daniel: exactMatch has a specific semantics that would seem to require transitivity
SeanB: if you make the explicit statement that they're transitive, then you have the possibility of rendering errors
... given the "sufficiently similar" wording
<Ralph> aliman: exactMatch is more for a specific application to use rather than a general statement
Daniel: then we need a different property
... exactmatch implies exact
Ralph: why don't we have a different property "similarMatch"
aliman: I can see both points of view
Guus: I can see Daniel's point that it needs to be transitive
SeanB: but "sufficiently similar" isn't exact enough
aliman: there may be assertions across mappings that requires careful checking of data
Daniel: exactmatch need to be exact
aliman: but this isn't an exact world
... these shouldn't ever be used in concept schemes
Ralph why not similarMatch
Daniel: How about nearlyExactMatch
<Ralph> Tom: "closeMatch"
Ralph: closematch
<Antoine> +1 with not changing the name
Guus: unless we have strong reasons I'd rather not change the name
many variations bandied about
Ralph: ok with exactMatch as long as there's an addition that exact == close to
Guus: this is why we're not using owl:sameAs
aliman: this is an issue of quality of exactness of match
Guus: propose to not change the name but add wording
<Ralph> PROPOSE: keep the name "exactMatch" but add a sentence saying that "exact" in this context means "sufficiently similar to" and not "identical to".
aliman: transitivity is just one entailment
<Ralph> PROPOSE: keep the name "exactMatch" but add a sentence saying that "exact" in this context means "sufficiently similar to" and not "identical to" and this relation is not transitive.
SeanB: seems like there's an inconsistency when you say woolily similar, but then say it's transitive, then you introduce the opportunity to compound errors
Guus: reluctant to change the name because it's already been deployed
<ed> Ralph++
Guus: who would be in favor of "closeMatch"?
aliman: these things should be so similar that you can swap em
<Ralph> I prefer "closeMatch" but would not object to keeping the name with the fuller explanation
SeanB: do you have to qualify the map
Guus: change the wording of exactmatch to say that it is sufficiently close and not transitive
Ralph: why would you feel that a transitive exact is better than owl:sameAs
<seanb> ++1 for what Antoine is saying
<aliman> ++1
Antoine: owl:sameAs comes with additional formal semantics that don't apply here
SeanB: what we're trying to represent here is application behavior, and very different from sameAs
Guus: straw poll
<Ralph> I don't feel a need for _both_ transitive exactMatch and also closeMatch
Guus: exactMatch is transitive
<Ralph> -1 to both transitive exactMatch and close
<seanb> This appeals to me as a solution, but I'm not a system developer :-)
Guus: introduce closeMatch as subproperty of exactMatch that is not transitive
Ralph: not sure if there's a use case to have both
Guus: typically exactmatch would be 1 to 1
aliman: we have no use cases for mapping across vocabularies
... not sure if it's a lack of use case or lack of data
... I can live without exactMatch
Daniel: why can't we have both
... wouldn't this represent a good compromise
aliman: if we keep both then closeMatch can't be a subproperty
<aliman> i was wrong, exactmatch could be a sub-prop of closeMatch
Alistair agrees with SeanB that this isn't necessarily so
<Ralph> I can live with both transitive exactMatch and closeMatch
Daniel: I can live with the last proposal of 2 properties, whether one is a subproperty or not
all agree with 2 properties
PROPOSED: ISSUE-72 is resolved by 1) adding to the skos data model a property "closeMatch" which is not transitive. 2) add to skos data model that exactMatch is transitive
<aliman> PROPOSED: ISSUE-72 is resolved by 1) adding to the skos data model a property "closeMatch" which is not transitive. 2) add to skos data model that exactMatch is transitive
<Ralph> +1
seconded Daniel
RESOLUTION: ISSUE-72 is resolved by 1) adding to the skos data model a property "closeMatch" which is not transitive. 2) add to skos data model that exactMatch is transitive
Guus: reference editors please add wording for this
... leave it to them to figure out subproperty relationship
... but first want to have it right in the reference
<scribe> ACTION: Alistair and Sean to propose text to implement the resolution of issue-72 [recorded in http://www.w3.org/2008/07/01-swd-minutes.html#action05]
Guus: issue-73...
<Ralph> ISSUE-73 ExactMatchDisjoints
aliman: think this changes now and we can take a stronger position
PROPOSED: issue-73 is resolved by skos:exactMatch is disjoint with skos:broaderTransitive and skos:related
Alistair seconds
RESOLUTION: issue-73 is resolved by skos:exactMatch is disjoint with skos:broaderTransitive and skos:related
Guus: last issue, issue-75
... property chain axioms
<Ralph> ExactMatchInclusions
SeanB: my inclination is to not do this, but could go either way
Guus: don't see any need to define this here
... I'm happy with the proposal that for the moment there are no property chain axioms
Antoine: I could support this
Guus: Close this issue by asserting that there are no property chain axioms until there is evidence to support such axioms
... would be useful to include the rationale
PROPOSED: Close Issue-75 by asserting that there are no property chain axioms until there is evidence to support them
<Ralph> PROPOSED: Close ISSUE-75 by asserting that there are no property chain axioms as there is no evidence yet to support them
Antoine seconds
RESOLUTION: Close ISSUE-75 by asserting that there are no property chain axioms as there is no evidence yet to support them
<Ralph> ISSUE-86
SeanB: We haven't yet closed ISSUE-86
sean reads text of email
Ralph: "makes no requirement" is not as strong as "strongly suggests"
seanb: happy to strongly suggest
Ralph: I'd prefer "does not require but strongly recommends"
<ed> Ralph++
<Ralph> PROPOSE: Close ISSUE-86 with and Appendix saying "URIs are used to identity resources of type skos:Concept and skos:ConceptScheme. The SKOS Reference does not require specific behaviour when dereferencing those URIs. It is, however, strongly recommended that publishers of vocabularies follow the guidelines for Best Practice Recipes [REF] and Cool URIS [REF]."
sean seconds
RESOLUTION: Close ISSUE-86 with and Appendix saying "URIs are used to identity resources of type skos:Concept and skos:ConceptScheme. The SKOS Reference does not require specific behaviour when dereferencing those URIs. It is, however, strongly recommended that publishers of vocabularies follow the guidelines for Best Practice Recipes [REF] and Cool URIS [REF]."
Guus: planning of telecon: 22July and another a week later
... 22 July for SKOS candidate recommendation, the other for RDFa
<seanb> I am definitely not here on the 22nd July
seanb: not available 22 July
aliman: one more week would be better
<Ralph> [I'm at risk during August]
Guus: like to have reviewers no, version available for review bu August
... happy to review reference
... chairs will look at this and be intouch
... editors please start implementing the changes
<scribe> ACTION: [PENDING] Ed to investigate what text could be added to primer re. concept co-ordination [recorded in http://www.w3.org/2008/04/22-swd-minutes.html#action02]
<scribe> ACTION: [PENDING] Guus to write primer text re: broaderGeneric and equivalence w/r/t subclass [recorded in http://www.w3.org/2008/03/18-swd-minutes.html#action08]
<scribe> ACTION: [PENDING] Alistair to check the old namespace wrt dereferencing [recorded in http://www.w3.org/2008/05/06-swd-minutes.html#action03]
<scribe> ACTION: [PENDING] Antoine and Ed to add content to Primer about irreflexivity [recorded in http://www.w3.org/2008/05/06-swd-minutes.html#action06]
<scribe> ACTION: [PENDING] Alistar to update the history page adding direct link to latest version of rdf triple [recorded in http://www.w3.org/2008/06/17-swd-minutes.html#action01]
<scribe> ACTION: [DONE] Editors of the Use Cases to clean up the lists of requirements in light of resolutions [recorded in http://www.w3.org/2008/05/07-swd-minutes.html#action02]
see http://lists.w3.org/Archives/Public/public-swd-wg/2008Jun/0093.html
<scribe> ACTION: [DONE] Antoine to propose that we postpone ISSUE 84. [recorded in http://www.w3.org/2008/06/24-swd-minutes.html#action10]
<scribe> ACTION: [PENDING] SKOS Reference Editors to specifically flag features at risk for Last Call. [recorded in http://www.w3.org/2008/06/24-swd-minutes.html#action17]
<scribe> ACTION: [PENDING] Sean to draft response to comment about namespace. [recorded in http://www.w3.org/2008/06/24-swd-minutes.html#action12]
<scribe> ACTION: [PENDING] Sean to post comment to OWL WG re annotation requirements. [recorded in http://www.w3.org/2008/06/24-swd-minutes.html#action06]
<scribe> ACTION: [PENDING] SKOS Reference Editors to propose a recommended minimum URI dereference behaviour [recorded in http://www.w3.org/2008/06/24-swd-minutes.html#action11]
ADJOURNED