See also: IRC log, previous 2008-10-21
RESOLVED to accept minutes of the last telecon
next telecon in 2 weeks; 18 Nov
ACTION: Ben review RDFa Use Cases and propose transition to Group Note [recorded in http://www.w3.org/2008/09/30-swd-minutes.html#action02] [CONTINUES]
ACTION: [DONE] diego propose resolutions to remaining recipes issues [recorded in http://www.w3.org/2008/10/14-swd-minutes.html#action02]
-> [Recipes] proposed resolution for remaing issues [Deigo 2008-11-03]
Tom: let's wait for Diego and Jon to be at a telecon before taking up those proposals
ACTION: [CONTINUES] Ralph/Diego to work on Wordnet implementation [of Recipes implementations] [recorded in http://www.w3.org/2008/01/22-swd-minutes.html#action20]
ACTION: [CONTINUES] Guus to look at OWL documents for review [recorded in http://www.w3.org/2008/10/21-swd-minutes.html#action10]
Tom: I believe we resolved last telecon to close several issues per msg 222
Sean: we were waiting for responses from the commentors
<Guus> [my phone is out of power, sorry]
Antoine: it might confuse the commenter if we close an issue before getting their response
<aliman> http://lists.w3.org/Archives/Public/public-swd-wg/2008Oct/0287.html
-> Alistair's review of 23 Oct issue proposals
Alistair: can we resolve a batch of issues as I propose in 0010 ?
Antoine: issue 134 should be included in your batch
<aliman> PROPOSED: to resolve issues 140, 141, 146, 133, 134, 144, 145, 149, 150,
<aliman> 152, 162, 160, 171, 172, 178 and 180 (part 1) as described in
<aliman> http://lists.w3.org/Archives/Public/public-swd-wg/2008Oct/0287.html
Antoine: I've read each one and am satisfied with the proposal
Sean: I'm happy with Alistair's proposal
Antoine: for issue 160 I proposed to add an invitation to Doug to post something but OK to proceed
Alistair: in order: 133, 134, 140, 141, 144,
145, 146, 149, 150, 152, 160, 162, 171, 172
... I propose to agree on the response to the comment
Sean: if the commentors agree with our response then our resolution here is to close or pospone the respective issue
RESOLVED respond to issues 133, 134, 140, 141, 144, 145, 146, 149, 150, 152, 160, 162, 171, 172, 178, and the first part of 180 per http://lists.w3.org/Archives/Public/public-swd-wg/2008Oct/0287.html
ACTION: [CONTINUES] Guus and Jeremy to give concrete implementation examples of the use of rdfs:label w/ SKOS [recorded in http://www.w3.org/2008/10/07-swd-minutes.html#action10]
ACTION: [DONE] Antoine to propose revised answers for issues 181-185 [recorded in http://www.w3.org/2008/10/21-swd-minutes.html#action01]
<GuusS> pls continue my action wrt Issue 186, will be completed this week
Antoine: I sent these proposals last week
-> ISSUE-181 new draft response
-> ISSUE-182 new draft response
-> ISSUE-183 new draft response
-> ISSUE-184 new draft response
-> ISSUE-185 new draft response
ACTION: [CONTINUES] Guus to propose answer for issue 186 [recorded in http://www.w3.org/2008/10/21-swd-minutes.html#action02]
ACTION: [DONE] Sean and Alistair to send answers wrt. the editorial issues resolved on 21-10-08 [recorded in http://www.w3.org/2008/10/21-swd-minutes.html#action07]
ACTION: [DONE] Sean and Alistair to send answers wrt. the editorial issues resolved on 21-10-08 [recorded in http://www.w3.org/2008/10/21-swd-minutes.html#action07]
Sean: see a slew of email on 22 October
<TomB> http://lists.w3.org/Archives/Public/public-swd-wg/2008Nov/0010.html
<aliman> http://lists.w3.org/Archives/Public/public-swd-wg/2008Oct/0270.html -> draft response on 151
-> issue 151; skos:member definition
Alistair: none of the commentors have demanded
a range but Jeremy has noted that there is an effective range
... I propose to not explicitly define a range
<GuusS> Ii;ve made progress in reviewing OWL docs, and talked to Ian at ISWC about timing SWD comments
Alistair: I can live with either approach (defining or not defining)
Antoine: I'm rather in favor of defining a range
<Antoine> http://lists.w3.org/Archives/Public/public-swd-wg/2008Oct/0290.html
Sean: Antoine has arguments for including a range, not seeing arguments against it
Alistair: the argument against is to leave flexibility
Antoine: in the case of collections, I think we gain from adding constraints
Sean: we've included ranges in other places, so
why the need for flexibility here?
... for consistency in the text, make it clear that collections are
collections of concepts
Alistair: the original document did not say
"collections *of concepts*"; it only said "collections"
... there are other cases of flexiblity; e.g. no domain for skos:inScheme
... we've not chosen to have domains and/or ranges for everything
Tom: coherence of specs, coherence of data all sound good but I don't think anything is harmed by leaving it unspecified
Ralph: I hear Antoine saying it would be useful
PROPOSED: we define the range of skos:member as the union of skos:Concept and skos:Collection
RESOLUTION: we define the range of skos:member as the union of skos:Concept and skos:Collection
Alistair: I'll redraft and send the response
<TomB> http://lists.w3.org/Archives/Public/public-swd-wg/2008Oct/0282.html
-> issue 180; PFWG: skosxl:Label class
Alistair: this is about the extensibility of
the vocabulary
... PFWG would like to extend the xl:Label class to be able to specify labels
in other modalities
... e.g. in other markup languages; MathML, etc.
... currently we require that every instance of xl:Label have a plain literal
form
... should we relax this restriction, e.g. from "exactly one [plain literal
form]" to "at most one"?
Tom: I prefer solution 1, our current solution
Alistair: saying "at most one" would still permit "dumbing-down"
Antoine: do both really support dumbing-down?
Alistair: if there is no plain literal form then there are no entailments
Antoine: so SKOSXL might not provide data that is compatible with standard SKOS tools
Alistair: correct, but the PFWG scenarios do not provide data useable by standard SKOS tools and we wouldn't want those tools to dumb-down
Antoine: I prefer option 1; live with the
current XL data model
... this is consistent with our resolution on symbolic labels, which is
related
<TomB> +1 with Antoine - go with option 1
Ralph: I suspect that if we keep the restriction and folks find good reason to violate it the world won't fall apart :)
Alistair: I may hold you to this at some point in the future :)
Antoine: I can see a use for more than one resource form attached to a label
RESOLUTION: retain the current XL data model; make no change to the restriction on xl:Label
-> issue 181; Non Assignable Concepts
-> ISSUE-181 new draft response [Antoine 2008-10-22]
Antoine: this is about what might be allowed to
be introduced in concept schemes
... there was a requirement that we dropped
... we discussed this in issue 48 and dropped the indexing
... I propose a practice to solve the issue in specific cases
... I suggested to Michael to consider proposing a practice
Alistair: I'm happy with Antoine's response
Tom: I'm happy with the response as drafted
Antoine: the problem here is to attach classes
to concepts
... would look a bit like indexing
<TomB> ISSUE-182 new draft response
Antoine: I propose to make no change but again suggest a practice that could be used
Alistair: could we say that this be resolveed
within a community of practice without giving specific practices?
... Michael is effectively proposing some extensions
... could we say that we agree these are important areas and that we look
forward to proposed practices from the community?
... we look forward to seeing this requirement addressed by third-party
extensions
... noting that Michael's suggestions might be good candidates for such
third-party extensions
Antoine: so use the word 'extension' explicitly in the response?
Alistair: yes, this requirement is out of scope
for SKOS but can be dealt with by extensions
... be more positive; we acknowledge that this is an important requirement
Tom: could have boilerplate text, as this comes up in a number of cases
Alistair: yes, I've tried to be consistent in the language I use
Antoine: I'd be happy for Alistair's help in drafting the language of the response
Antoine: I just need to reformulate the last paragraph of the responses for issues 181 and 182
RESOLUTION: close issue 182 without changing the specification
-> issue 183; Class-Topic relationships
-> ISSUE-183 new draft response
Antoine: this was a case of a classification
scheme and a concept scheme co-existing
... I suggest this is an unusual use case and that we not try to adapt the
SKOS standard to handle this
... and again note a possible practice for using SKOS classes and concepts,
suggesting Michael use that practice if it is useful
Alistair: I try to word my responses to avoid
stimulating a long conversation
... try to elicit a "yes, I can live with the Group's decision" response
Antoine: I can extract the essential details
Tom: sounds like we agree on the substance, though
Antoine: I felt that this commentor really wanted to be convinced that a solution could be found
Tom: shall we leave it to Antoine's discretion?
Alistair: sure
-> issue 184; Notation and prefLabel overlap
<TomB> ISSUE-184 new draft
Antoine: Michael objected that skos:notation
wouldn't handle the case
... I gave an example of using private notations
... so the response is long just to illustrate the solution
Alistair: the core of the response is that we acknowledge the utility of the case but that it's out of scope for SKOS
Antoine: however, SKOS can do what he wants
-> issue 185; Order in Classification Systems
<TomB> ISSUE-185 new draft response
Antoine: the commentor wanted a way to
distinguish order of children
... my proposed response is that we did not have a use case for this and that
ordering is difficult to express in RDF
... an alternative is to use ordered collections
Alistair: we could also refer to a previous
issue where we resolved that capturing all of the information one might want
to display is out of scope
... some parallel coding might be necessary
Antoine: have we discussed ordering for systematic display?
Alistair: not, but we agreed that SKOS does not have to capture all the information needed for a systematic display
RESOLUTION: we accept Antoine's proposed responses for issues 181, 182, 183, 184, and 185 with stylistic adjustments at Antoine's discretion
Alistair: so Antoine will post the responses to the commentor when he's ready
[adjourned]