13:15:56 RRSAgent has joined #swd 13:15:56 logging to http://www.w3.org/2008/05/06-swd-irc 13:17:55 Antoine has joined #swd 13:18:17 Guus: charter extension has been approved 13:18:29 RESOLVED to accept minutes http://www.w3.org/2008/04/29-swd-minutes.html 13:18:31 ... schedule should go as on the agenda 13:19:04 Topic: SKOS Scoping 13:20:09 Ralph has joined #swd 13:20:15 zakim, who's on the call? 13:20:15 sorry, Ralph, I don't know what conference this is 13:20:16 On IRC I see Ralph, Antoine, RRSAgent, Zakim, edsu, TomB, cgi-irc, JonP, ed, aliman, Clay, Guus, vit, seanb, berrueta 13:20:18 zakim, this is swd 13:20:18 ok, Ralph; that matches SW_SWD()9:00AM 13:20:20 zakim, who's on the call? 13:20:20 On the phone I see [LC], ??P5 13:20:27 zakim, p5 is Sean 13:20:27 sorry, Ralph, I do not recognize a party named 'p5' 13:20:31 zakim, ??p5 is Sean 13:20:31 +Sean; got it 13:21:05 zakim, LC has Antoine, Guus, Ed, Alistair, Clay, Tom, Jon, Simon_Spero 13:21:05 +Antoine, Guus, Ed, Alistair, Clay, Tom, Jon, Simon_Spero; got it 13:22:19 Feature: Notations 13:22:42 Alistair: this feature is about support for codes for identifying concepts 13:22:53 ... mostly in classification schemes 13:23:10 ... It is widely used. 13:23:55 ... Guus: you're thinking about Iconclass or DDC 13:24:08 s/... Guus:/Guus:/ 13:24:22 Alistair: one pattern is to use prefLabel with a specific tag 13:24:36 ... proposed by Jakob 13:25:03 ... a second is to have another SKOS relation, like skos:notation 13:26:26 Simon: some concepts have multiple notations 13:27:07 Antoine: I prefer Jacob's proposal for prefLabel 13:27:26 -> http://lists.w3.org/Archives/Public/public-swd-wg/2008Jan/0211.html Jacob's proposal 13:27:34 Clay: we've used that as well 13:28:01 Antoine: likers Jakob Voss proposal (prefLabel) 13:28:38 Alistair: does anyone have motivation for leaving it out? 13:29:02 Ralph: how hard is it to use? 13:29:31 ... the thing I don't like about Jakob's proposal is that it is a whole new syntax 13:30:06 Ralph: literal value would have structure that is peculiar to SKOS 13:30:38 ...Jakob proposes to embed language information in literal, 13:30:49 Guus: would be normal to define datatype for it 13:32:03 AntoineI has joined #swd 13:32:20 Ralph: actually Jakob made a typo 13:32:32 ... so I'm more comfortable with it now 13:33:33 Alistair: do we spend more time on it? 13:33:54 Guus: I think we can do this with guidelines, it should not affect the voc 13:34:09 ... it's worth supporting 13:34:19 Feature: (Subject) Indexing 13:34:53 i/Ralph: actually/scribenick: AntoineI 13:35:30 scribenick: TomB 13:36:00 Antoine: about links to resources - existing vocabulary like 13:36:17 ....skos:subject - or do we prefer to delegate to other vocabularies, like 13:36:19 Topic: (Subject) Indexing 13:36:22 ...dublin core? 13:36:29 -> http://alimanfoo.wordpress.com/2008/05/06/semantic-web-deployment-final-face-to-face/ blog post about this meeting 13:36:50 Antoine: reason for removing - bc can be supported by other vocabularies 13:36:57 ...dc:subject might be appropriate 13:37:11 ...other argument for removing: these links are not part of the inherent meaning of a subject 13:37:33 -> http://www.w3.org/2006/07/SWD/track/issues/77 issue-77 SubjectIndexing 13:38:07 Simon: in classical knowledge organization, concepts defined by the documents they index 13:38:17 Antoine: an "extensional" view. 13:38:44 Simon: dc:subject is polluted 13:38:53 Guus: seems to be outside the scope of SKOS 13:39:09 ...if you have a thesaurus of artist names, will be typically dc:creator 13:39:27 ...My preference is to drop completely. 13:39:44 Simon: In MARC, diff btw authors and creators and people who are subjects, 13:39:57 ...though stored in similar authority records... 13:40:59 Guus: leave this out of scope. 13:41:14 Edsu: could still reference old vocabulary 13:41:27 Ralph: likely to mix old and new vocabularies. 13:42:23 Guus: low on the priority list. 13:42:43 ...only problem is deprecation. 13:42:52 Feature: Symbol (Image) Labels 13:42:58 scribenick: AntoineI 13:43:20 Alistair: dates back from the beginning of SKOS 13:44:01 -> http://www.w3.org/2006/07/SWD/wiki/WashingtonAgenda/SkosPriorities Evolving list of priorities 13:44:42 Antoine has joined #swd 13:44:52 scribenick: Antoine 13:45:01 Simon: has anyone implemented it? 13:47:00 AntoineI has joined #swd 13:47:09 scribenick:AntoineI 13:47:10 Feature: Mapping Between Concept Schemes 13:47:30 Guus: It's not an option to drop it 13:47:49 ... almost everyone who uses SKOS I know use it 13:48:48 Alistair: so it goes top in the priority list 13:49:04 Feature: Labels as Resources 13:49:21 Guus: it belongs to the top of the list 13:50:18 Feature: Label Relations 13:50:39 Guus: I thought it was with the previous one 13:50:52 ... the main discussion should be: 13:51:01 ... there are solutions on the table 13:51:23 ... we should make sure what their status is: part of SKOS? notes? 13:52:13 Alistair: so this goes in scope 13:52:27 Feature: Reference Semantic Relation Specialisations (broaderGeneric etc.) 13:52:44 Alistair: these were previously defined in the non-core part 13:52:57 ... people may want to use it 13:53:05 ... but they raise problems 13:54:00 Simon: this goes straight at the difference between KOS and ontologies 13:55:12 ... it has been defined in terms of what you want to get back when you search 13:56:24 ... if they don't have a clear meaning in SKOS... 13:57:19 Feature: OWL Imports 13:57:41 Alistair: do we leave the door open to use it, or do we ignore it? 13:58:43 Antoine has joined #swd 13:58:49 Guus: an editorial item (Primer), not normative 13:58:55 Guus: my proposal is to show examples of owl imports in the Primer but not normatively describe it in the Reference 13:58:57 scribenick:Antoine 13:59:20 Sean: concerned we understand consequences 13:59:38 Guus: problem where we need to know provenance of triples 14:00:03 Antoine: would leave this to annex, with OWL-related problems 14:00:04 Antoine: I'd even omit from the Primer, as owl:imports doesn't solve the problem that people want 14:00:17 Sean: if you remain completely silent on it, people will use it 14:00:25 Sean: if you don't say anything, people will use it anyway 14:00:27 ...point out issues 14:00:46 ...issues = unexpected consequences 14:00:49 Alistair: if we focus on the consequences of using it 14:00:55 ... it could be ok 14:01:20 Guus: the primary use case is the provenance 14:01:36 ... in case the vocabulary is spread in different files 14:01:47 ... owl:import is an option 14:02:06 Sean: but you still need external mechanisms to give the provenance if your vocabulary comes from several places 14:02:25 Guus: If you have namespace document, "provenance of this triple is this graph" - simple mechanism 14:02:39 Alistair: you would use to prevent duplication of triples 14:03:00 Guus: if you use this graph you should consider this graph as well 14:03:13 Guus: it requires some joint action 14:03:22 Guus: Sean and I can work this out 14:03:27 ... I'm happy to work on it with Sean 14:03:30 Sean: OK 14:05:08 AntoineI has joined #swd 14:05:15 scribenick:AntoineIs 14:05:23 scribenick:AntoineI 14:05:35 Feature: SKOS Imports 14:06:29 ACTION: Guus and Sean propose some owl:imports text for Primer 14:07:26 Antoine has joined #swd 14:07:35 RESOLVED: SKOS Imports low priority 14:07:37 scribenick: Antoine 14:07:43 Feature: Coordinated Subject Indexing 14:09:56 simon: it's used 14:10:51 q+ 14:11:16 Antoine: the Mapping use case uses this 14:12:39 AntoineI has joined #swd 14:14:30 Sean: composite indexing strays into OWL territory 14:15:32 Guus: I was supposed to write a resolution to postpone this issue - 14:15:38 ...that is the most likely outcome 14:15:50 i/Guus: I was/scribenick: TomB 14:15:56 ...depending on time, could come up with OWL examples... 14:16:01 ...but I consider risky. 14:16:04 I have made the request to generate http://www.w3.org/2008/05/06-swd-minutes.html Ralph 14:16:14 ...If there are examples of using OWL, we could point that it. 14:16:18 ...the most we could do. 14:16:22 rrsagent, please make record public 14:16:43 ...OWL: you have a concept that consists of .... 14:16:48 Meeting: SWD Face-To-Face 14:16:52 Chair: Guus, Tom 14:16:57 ...need to explain how that relates to OWL union 14:17:04 Agenda: http://www.w3.org/2006/07/SWD/wiki/WashingtonAgenda 14:17:19 zakim, list attendees 14:17:19 As of this point the attendees have been Sean, Antoine, Guus, Ed, Alistair, Clay, Tom, Jon, Simon_Spero 14:17:29 Alistair: Now clear how to say, in OWL, "this is about sideeffects of aspirin' 14:18:03 i/Guus: charter extension/scribenick: Antoine 14:18:10 ...you can bundle into new unit, use that.... 14:18:43 Guus: if it is still a battle, then definitely out of scope 14:19:00 I'd like to see it out of scope. 14:19:03 ...would welcome text from, say, LC. 14:19:14 ...but late to introduce into vocabulary 14:19:16 I think it's rather late to try and define such a semantics 14:19:20 Edsu: out of scope 14:19:56 Feature: XML Literal Notes 14:20:17 Alistair: would be nice to have clear pattern but could live without 14:20:37 Guus: can't you standard RDF facility for this? 14:20:52 Alistair: documentation property as related resource description 14:21:13 ...could give content type 14:21:26 ...but no clear requirement in Use Cases and no mature proposal 14:21:34 ...so out of scope 14:21:53 Feature: N-Ary Thesaurus patterns 14:22:56 Antoine: related to coordination 14:23:13 ...if we had a solution to this, would have solution for coordn 14:23:24 Alistair: this is not a link between descriptors 14:23:44 Alistair: propose this be out of scope. 14:24:18 Antoine agrees. Would like it to be in scope, but no time. 14:25:01 http://www.w3.org/2006/07/SWD/wiki/WashingtonAgenda/SkosPriorities 14:26:14 Agenda item: SKOS Technical DIscussion 14:26:35 Technical item: SKOS Namespace 14:26:38 Antoine has joined #swd 14:27:42 -> http://lists.w3.org/Archives/Public/public-swd-wg/2008Apr/0047.html Re: Deprecated SKOS Vocabulary [Sean 2008-04-09] 14:28:14 -> http://lists.w3.org/Archives/Public/public-swd-wg/2008Apr/0114.html Draft SKOS Schema [Sean 2008-04-29] 14:28:22 -> http://www.w3.org/2006/07/SWD/wiki/SkosDesign/RdfSchema 14:29:03 summary of namespace issues is on that page 14:29:53 Guus: fact that it is not OWL-DL is not the issue 14:30:06 Guus: annotation property is the only thing that's keeping this from being OWL-DL 14:30:23 ... the only thing of any substance 14:30:29 ses has joined #swd 14:30:45 Sean: OWL 2 will cover this 14:31:06 ...what do we do in interim? Publish one schema which is DL, one that is not? 14:31:28 ...I have an OWL Full schema. Useful to have that recorded somewhere. 14:31:39 s/property is/properties are/ 14:31:56 I have made the request to generate http://www.w3.org/2008/05/06-swd-minutes.html Ralph 14:32:01 Guus: Given that we are in transition state, publish this as currently is. 14:32:35 Sean: though the schema we publish will be DL, but we will be declaring ObjectProperties. 14:32:53 ....we can publish an OWL-DL schema, but usage will push people into OWL Full. 14:32:59 Regrets: Quentin_Reul, Diego_Berrueta 14:33:14 Guus: We don't publish OWL-DL schema. Publish as is. 14:33:24 ...otherwise, people inclined to use differently. 14:33:34 +1 for not restricting our schema to OWL-DL 14:33:43 ...differences have nothing to do with computational complexity, etc. 14:34:35 RESOLVED Publish RDF schema as is (OWL Full) 14:35:03 Alistair: with rdf:list - just leave this range triple out of schema 14:35:32 ...we have said the text of the reference will be normative 14:35:51 ...we have already said that the RDF schema might not capture everything normative. 14:36:20 Sean: almost some inconsistency - things allowed into schema and not allowed. 14:36:32 ...if we publish the schema as is, some triples make it OWL Full. 14:37:02 ...Some stuff is OWL Full for annotation purposes - can ignore. 14:37:36 ...If we don't put in rdf:list, slightly inconsistent. 14:37:46 Guus: provide recipe for making OWL-DL. 14:38:09 ...OWL 2 will come up with something that makes this necessary. 14:38:25 Sean: Arguments for keeping it out - OWL 2 will probably solve - 14:38:32 ...but makes for complicated story. 14:38:55 Guus: Smaller story to tell about making DL-compliant. 14:39:47 ...Include rdf:list triple, keep OWL Full. 14:40:04 GuusS has joined #swd 14:40:55 * 14:40:55 A: Keep old namespace, don't include deprecated vocab. 14:40:55 * 14:40:55 B: Keep old namespace, include deprecated vocab (and mark as such) 14:40:55 * 14:40:57 C: Define new namespace, with only new vocab. 14:41:04 scribenick:Antoine 14:41:42 Sean: I proposed the B option, did not really like A 14:41:58 ... my preference goes for C though 14:42:21 http://www.w3.org/2006/07/SWD/wiki/SkosDesign/RdfSchema 14:42:38 http://lists.w3.org/Archives/Public/public-swd-wg/2008Apr/0032.html 14:42:49 thread on deprecated vocabulary 14:43:23 Simon: if the semantics of old and new SKOS are incompatible, A and B are not tractable 14:43:32 Alistair: not necessarily true 14:43:57 Guus: people have tools that upgrade their vocabulary 14:44:23 ... it would be confusing not to upgrade the namespace, actually 14:44:52 Jon: is there a strong argument for sticking to the old namespace? 14:45:20 Guus: people using the old namespace would migrate without problem 14:45:40 Alistair: I agree with creating a new namespace 14:46:15 Guus: anyway as long as the old namespace is there, nothing is made incoherent 14:47:17 Ralph: new tools may want to acknowledge the latest document but still to do things with the old one 14:47:42 Guus: that's actually an argument in favor of having old and new separate 14:48:08 Jon: in the metadata registry, there is a casacading effect 14:48:28 ... some dependencies that are difficult to track 14:49:53 Guus: if people are happy with the old namespace, we can' prevent them to use it 14:53:49 Antoine has joined #swd 14:54:04 scribenick: Antoine 14:55:30 Antoine has joined #swd 14:55:38 scribenick:Antoine 14:56:00 Guus: I wrote a list of difference between DAML and OWL 14:56:08 s/difference/differences 14:57:19 Guus: PROPOSE to create a new namespace 14:57:45 Guus: PROPOSE that either the Reference or the Primer say something about the differences 14:58:39 -> http://www.w3.org/TR/2005/WD-swbp-skos-core-guide-20051102/ "Old" SKOS WD 14:58:52 Tom: what about the redirections from the SKOS URL to the most recent WDs? 14:59:15 Ralph: there is indeed a redirection 14:59:43 ... from the old WD to the new one (by the 'latest version' link 14:59:51 ...) 15:00:57 Ralph: we made a new "Latest Version" URI for the current SKOS: "http://www.w3.org/TR/skos-reference/" 15:01:39 ... and we redirect the old "Latest Version" URI http://www.w3.org/TR/swbp-skos-core-spec 15:01:39 Antoine: for the moment the URL of latest version of the old Guide redirects to the Primer 15:03:48 Ralph: we could have the Guide redirect to a page linking to Guide *and* Primer 15:05:06 ACTION: Ralph compost intermediate pages for http://www.w3.org/TR/swbp-skos-core-spec and http://www.w3.org/TR/swbp-skos-core-guide/ to inform readers of the paths to the old and new SKOS documents 15:05:49 benadida has joined #swd 15:06:04 s/compost/sompose/ 15:07:02 RESOLVED to have a new namespace 15:07:06 s/compost/compose/ 15:07:50 ACTION: Alistair to check the old namespace wrt dereferencing 15:08:44 Ralph: I propose /2008/05/skos 15:09:05 Guus: your document will be on this space 15:09:13 s/your/Sean's 15:09:48 Alistair: which receipe are we going to use for publishing the document? 15:10:15 Do you mean hash/slash etc Alistair? 15:10:25 Guus: it's a very clear receipe, the document is small 15:10:43 oops...:-) 15:10:51 Alistair: receipe 3 15:11:02 Jon: 3 is fine 15:12:26 Alistair: the HTML de-referencing could point to the Reference doc 15:12:47 Guus and Ralph: we're surprised when we see this 15:13:20 Guus/Ralph: expect to see screen-friendly version of RDF schema 15:13:28 ...not a document like Reference 15:13:44 Antoine has joined #swd 15:14:01 Alistair: I could write a small HTML from the quick access table 15:14:22 Guus: in OWL there was an appendix that played this role 15:14:28 s/was/is 15:15:00 Ed: I would argue for using as a summary what can be found in the Reference 15:16:32 Alistair: what if you have three documents: one HTML doc, one HTML table, and the schema 15:17:13 http://www.w3.org/TR/2008/WD-skos-reference-20080125/#related 15:17:50 Ralph: at the end the SKOS recommendation should consist of one document 15:17:58 ... in the 'print' sense 15:18:27 Sean: the OWL documents were published as a bundle of documents 15:19:48 Antoine has joined #swd 15:20:11 Alistair: the problem is that an HTML 'first page' would not be W3C-labelled 15:20:19 scribenick:Antoine 15:21:16 Ralph: I think I prefer the duplication 15:22:02 Guus: let's let the editors decide 15:23:13 rrsagent, please draft minutes 15:23:13 I have made the request to generate http://www.w3.org/2008/05/06-swd-minutes.html Ralph 15:24:00 s/sompose/compose/ 15:25:20 ACTION: Sean and Alistair to send a file for the namespace 15:26:06 PROPOSE: http://www.w3.org/2008/05/skos# for the namespace URI 15:26:28 -- RESOLVED 15:26:58 RESOLVED : http://www.w3.org/2008/05/skos# is the namespace URI 15:27:00 rrsagent, please draft minutes 15:27:00 I have made the request to generate http://www.w3.org/2008/05/06-swd-minutes.html Ralph 15:27:49 s/RESOLVED :/RESOLVED:/ 15:27:52 rrsagent, please draft minutes 15:27:52 I have made the request to generate http://www.w3.org/2008/05/06-swd-minutes.html Ralph 15:27:53 -Sean 15:28:42 Clay has joined #swd 15:33:48 +??P5 15:33:51 -[LC] 15:33:53 +[LC] 15:33:58 zakim, ??P5 is me 15:33:58 +seanb; got it 15:39:12 zakim, LC is Clay 15:39:12 +Clay; got it 15:40:01 Technical Item: Related Irreflexive? Broader Irreflexive? Broader Cycles? (Issues 68, 69, 70) 15:40:31 Guus: the new OWL spec will contain primitives 15:40:40 ... to represent these characteristics 15:40:59 ... it's potential an easy addition to the semantics 15:41:24 ... my proposal is that we focus on the features allowed by OWL 2 15:41:58 Alistair: three questions: 15:42:33 ... are broader/related reflexive? are there cycles in broader? 15:43:03 ... last condition = "is broaderTransitive irreflexive?" 15:44:35 Tom: how about the OWL/SKOS patterns that a strict data model would prevent? 15:45:01 Alistair: most KOS users would have the 3 properties irreflexive 15:45:28 ... some that map OWL properties to SKOS properties would not be allowed 15:50:16 Antoine has joined #swd 15:50:27 scribenick: Antoine 15:52:35 Alistair: I can see value in saying yes to all 3 questions 15:54:41 Guus: We could still have brooderGeneric subproperty of rdfs:subClassOf 15:55:16 ... or have broaderGeneric as a subproperty of both broaderTransitive and rdfs:subClassOf 15:55:47 Alistair: we could still say that most tools should check these conditions 15:56:16 3.1 Hierarchical relationships 15:56:17 Dextre Clarke defines a hierarchical relationships as one “assigned to a pair of terms when the 15:56:17 scope of one of the terms totally includes (is broader than) the scope of the other.” (Dextre Clarke 15:56:17 2001, p. 42) 15:56:17 Milstead confirms that total inclusion is the key criteria: “[The part-whole relationship] only has 15:56:18 to meet the test of always being true, just as with the other hierarchical relationships.”(Milstead 15:56:19 2001, p.60) 15:56:37 Sean: if you have statements in the SKOS reference about irreflexivity 15:56:42 ... that's quite strong 15:56:53 Both in Bean and Green 15:57:11 Sean: my inclination would not to have these assertions 15:57:44 ... given that the definitions of the relations there are quite "whooly" 15:58:10 Tom: could we have them in the non-normative part (rule of thumb) 15:58:47 Sean: in that case I would prefer to have rule of thumb in the documents again 15:58:51 ``Elsewhere in this volume examples are given which demon- 15:58:51 strate clearly that the application of the hierarchical relationship 15:58:51 in actual thesauri is frequently not nearly as rigorous as the stan- 15:58:51 dards recommend. An operation may be subordinated to a phys- 15:58:52 ical entity, or a subordination that does not always apply may 15:58:52 be treated as hierarchical. It is very tempting to do this, and it 15:58:54 is easy to make the argument that a user who wants everything 15:58:56 on the broader subject would expect information on the narrower 15:58:58 subject to be included. However, actual development experience 15:59:00 has repeated ly demonstrated that extending the criteria for hier- 15:59:02 archical relationships is fraught with dangers. Any attempt to 15:59:04 define broader criteria (rather than just deciding on the relation- 15:59:06 ships ad hoc) runs into problems. . . . Unless a better, rigorously 15:59:08 definable substitute can be found, it is preferable to stick with the 15:59:10 provisions of the standard. 15:59:12 Jessica Milstead'' 16:00:14 Jon: there are potential spaces where it could be important to be reflexive 16:00:26 ... in order to keep the vocabularies in SKOS 16:01:12 Simon: about synonyms 16:01:40 Alistair: we would not use broader and narrower to define synonyms 16:03:53 Antoine: I could live with broaderTransitive being a reflexive closure over broader 16:04:06 ... but still disallow cycles 16:04:49 Tom: how would the reference say that? 16:05:44 Guus: Ralph mentioned that subClassOf is reflexive so as to model equivalence 16:05:56 ... when it could not be modelled without subClassOf cycles 16:06:36 Guus: how about asymmetric? 16:06:55 Alistair: asymetric is subsumed by antisymetric 16:07:35 ... so I did not ask the question 16:09:10 Will be back in about 1.5 hours..... 16:09:15 Enjoy lunch! 16:09:20 -seanb 16:19:16 -Clay 16:19:18 SW_SWD()9:00AM has ended 16:19:19 Attendees were Sean, Antoine, Guus, Ed, Alistair, Clay, Tom, Jon, Simon_Spero, seanb 16:19:58 seanb has left #swd 16:55:47 ses has joined #swd 17:18:26 SW_SWD()9:00AM has now started 17:18:33 +[LC] 17:19:29 TomB has joined #swd 17:20:02 zakim, lc has Antoine, Guus, Clay, Alistair, Simon_Spero, Ed, Barbara_Tillett, Tom, Ralph, Jon 17:20:02 +Antoine, Guus, Clay, Alistair, Simon_Spero, Ed, Barbara_Tillett, Tom, Ralph, Jon; got it 17:20:13 scribenick: edsu 17:20:19 Clay has joined #swd 17:21:03 ses has left #swd 17:21:38 ses has joined #swd 17:21:41 aliman: i'm reluctant to take the strong position to normatively say that they are irreflexive, but am open to providing some advice how you might want to check 17:22:07 Ralph: it might be helpful to actually provide the triples, which could be added to a checker 17:22:18 JonP: would be useful 17:22:51 guus: i think (like transitivity) you should mention it in reference 17:23:34 Ralph: we don't want to have stronger level of constraint in the normative version of skos 17:24:20 aliman: there are notes on this in the reference 17:28:40 PROPOSED: to resolve skos:related, skos:broader and skos:broaderTransitive are not normatively irreflexive 17:29:21 for ISSUE-68, ISSUE-69, ISSUE-70 17:29:50 seanb has joined #swd 17:30:01 Associative relationships are *defined* as being relationships which aren't hierarchical 17:31:34 ACTION alistair and sean to write a note about irreflexivity to Reference 17:31:37 Sean, any objections or comments on the proposal on the table? 17:31:46 What's the proposal? 17:32:01 ACTION: alistair and sean to write a note about irreflexivity to Reference 17:32:01 "PROPOSED: to resolve skos:related, skos:broader and skos:broaderTransitive are not normatively irreflexive" 17:32:31 GuusSchreiber has joined #swd 17:32:48 s/write a note/add a note/ 17:33:29 Ralph: seconds 17:33:36 s/Ralph:/Tom:/ 17:33:39 This is ok with me -- I preferred the less restrictive solution 17:34:27 RESOLVED: to resolve skos:related, skos:broader and skos:broaderTransitive are not normatively irreflexive 17:34:45 +??P3 17:34:48 -[LC] 17:34:48 ACTION: antoine, ed to add content to Primer about irreflexivity 17:34:49 +[LC] 17:35:12 zakim, ??p3 is SeanB 17:35:12 +SeanB; got it 17:36:00 Topic: Technical Item: Labels as Resources, Label Relations (Issues 26, 27) 17:36:31 GuusSchreiber: this was raised at our very first f2f 17:36:44 ... every vocab owner has a use case for this 17:36:56 ... we have the current proposal in the reference and primer 17:37:08 ... there is the XL proposal on the table 17:37:20 ... is it ok to say the XL proposal has met with general approval? 17:37:41 ... I want to postpone the discussion of whether XL should be part of the REC or not 17:38:08 ... I like how prefLabel has a deeper semantic meaning in XL 17:38:33 JonP: I agree 17:39:12 GuusSchreiber: lets talk about the different patterns, what should happen to the current pattern in the reference, the n-ary pattern 17:39:23 ... I think we'd like to have one preferred pattern 17:39:40 ... my view is that the XL pattern is the most intuitive one 17:39:48 aliman: which of the 3? 17:39:55 GuusSchreiber: the binary one 17:40:27 ... I think it's the most natural ... having one in the Primer namespace and one in the XL namespace is confusing 17:40:45 aliman: your preference is to move all three patterns into the XL namespace? 17:41:29 s/Primer namespace/Primer document/ 17:42:12 GuusSchreiber: my preference is to have support just for binary relations, but can live with other views 17:42:38 aliman: my preference is to have all label relations in XL, and in XL to have all three options, with no preferences 17:43:01 ... with n-ary you can have more than two labels in a relation, and provide context to relationships 17:43:23 ... it's not clear to me which of these three is going to be generally appropriate 17:43:47 GuusSchreiber: we have the use cases, where the binary pattern is sufficient 17:44:00 ... why do you need the context? 17:44:52 aliman: RDA (Resource Description and Access | Recommended Daily Allowance) 17:44:57 controlling for Polysemy is what controlled vocabs are for 17:45:02 GuusSchreiber: but everything gets a URI 17:46:02 ... the only way to solve this is to go the full wordnet route: semantics, sense and word form 17:46:14 ... if we just have concept and label this is what we have to work with 17:46:33 Extracting dot/A/B/Abduction_(Canon_law).dot 17:46:33 Extracting dot/A/B/Abduction_(Logic).dot 17:47:00 aliman: implicit in the decision you will make is your decision to model thins using binary relations 17:47:10 s/thins/things/ 17:47:24 ... there are consequences to these decisions 17:48:15 GuusSchreiber: we should give preference to how easy it is to learn 17:49:05 ... and the use cases are covered largely by binary relations 17:49:47 aliman: we don't know enough for saying "here's the pattern" -- i feel more comfortable saying "we've just started exploring this space, here are three options for you to consider" 17:50:12 GuusSchreiber: but the binary solution is the simplified version 17:50:29 ... after they understand that they may encounter further complications 17:51:48 aliman: I can capture the relationship between WHO and World Health Organization without introducing new classes of resources 17:52:21 ... i find n-ary simpler, work with literals that have clearly defined identity semantics 17:53:10 GuusSchreiber: i gave both patterns to my 25 students, and they wrote down their own examples with the binary pattern, and it took them 1/2 an hour to understand the n-ary relation 17:53:53 ... if you are forced to think of them as blank nodes, it's difficult 17:54:05 berrueta has joined #swd 17:54:13 aliman: it's not clear that 1 of the 3 should be held up as the_one to use 17:54:14 RDF is hostile to N-tuples 17:56:31 (Think about how much easier RDF provenance/trust would have been if there n-tuples) 17:56:36 Ralph: I'm with Guus, 80/20, binary relations solves maybe 80% of the cases, it doesn't feel as though the importance of adding the extra vocabulary for the n-ary is known 17:57:01 aliman: i'd like to see what people use in practice 17:58:21 Ralph: it seems that I could say someone is mislabeling things if RDA is shared 17:59:15 GuusSchreiber: lexical resource community have gone through this, which is why we have the 3 types in wordnet 17:59:34 ... how often to we really get into this difficult situations 18:00:05 aliman: we don't know, it's not obvious that binary is simpler in the long run 18:01:34 TomB: one reason i'm inclined to Guus' view on this, are that I don't understand how that literals involved in an n-ary relation, relate back to the concept associated in that relationship 18:01:59 Murphy carefully distinguished between lexical relation and relations between the denoted concepts 18:02:12 Murphy - Semantic Relations and the Lexicon 18:02:51 Label relationships must be the former 18:02:52 http://lists.w3.org/Archives/Public/public-swd-wg/2008Mar/0083.html -> Tom's comments 18:04:28 GuusSchreiber: if people who are experts on SKOS, how are we going to make it clear to users 18:04:50 aliman: i'm more than happy to do what the consensus of this room is 18:05:32 GuusSchreiber: i think we need to keep an explicit door open 18:06:13 (the screen rises, and exposes no whiteboard) 18:14:36 Clay has joined #swd 18:18:56 aliman: i've drawn two examples up: the top is the n-ary relation, and the bottom is the binary relation 18:19:19 TomB: it's not the way I pictured it 18:19:45 seanb - do you want a picture of the flipchart? 18:25:07 we're looking at 8.5 in the Reference 18:25:28 GuusSchreiber: i have strong preference for non foo/bar examples :) 18:28:09 seanb: http://www.flickr.com/photos/inkdroid/2470890333/ 18:29:06 JonP: http://www.flickr.com/photos/inkdroid/2470890303 18:29:35 s/seanb:/seanb,/ 18:30:39 What about gendered and plural terms? 18:31:03 f.sg / m.sg / m.sg / m.pl ? 18:31:15 lexical relationships (between words) 18:31:25 GuusSchreiber writes down the binary relation rdf/xml example 18:34:51 aliman: the use cases are covered by both n-ary and binary relations 18:35:31 ... you get context with the literals 18:36:03 GuusSchreiber: it's more accepted principle that Strings don't have identity 18:36:13 aliman: but in rdf that's not true 18:36:20 GuusSchreiber: just speaking about how people model 18:36:35 ... if you need to give identity to a string you give it an identifier 18:37:01 aliman: but you don't give identity to a string, you give it to the resource 18:37:19 GuusSchreiber: there's nothing like uniqueness of strings, they just replicate like numbers 18:37:26 "RDA 18:37:34 "RDA" == "RDA" 18:38:50 With xl, labels aren't strings, they're objects 18:38:57 aliman: when you get into the xl label class you get into the modelling where you have to make decisions 18:39:00 That have literal values 18:39:19 a.value = "RDA" , b.value = "RDA" 18:39:30 (equals a b) but (not (eq a b)) 18:40:07 aliman: you and antoine have come to a different intuitive understanding of what this xl class is used for 18:40:46 Antoine: if we define this understanding/consensus then we're ok 18:42:10 GuusSchreiber: if someone wants to have two RDA labels in the same concept scheme it won't be a problem because they'll have different URIs 18:45:26 JonP: if we substitute literals for terms ... 18:46:35 ... one of the reasons i haven't done import into the registry, is because the vocabs consist of terms, and relationships between terms, global concepts, scheme specific concepts, how to do that in a purely literal way 18:47:05 aliman: can you provide an example? 18:47:08 GuusSchrei has joined #swd 18:47:11 JonP: synonyms, antonyms 18:47:38 ses: relationships between the words, not between the meanings of the words 18:49:37 Tom: i would support making a decision for the binary relation 18:50:24 Ralph: i don't have a handle on the use cases to see if n-ary is needed 18:50:26 Found it hard to follow everything. 18:50:37 My impression is that there is no clear front runner based on use cases. 18:50:57 DO we know what the costs of making the "wrong" decision are at this point?? 18:50:57 Antoine: i can't make a strong argument 18:51:49 cred: the binary relation seems a little simpler 18:52:36 ses: they can all reduce to the other, since users shouldn't be exposed to rdf it should be hidden in the same way -- go for the binary because rdf is going to make it ugly anyway 18:52:52 Tom: i feel like i don't really understand the issue of identity of literals 18:53:26 Ralph: i think that's a red herring, in each case we have an instance of a label 18:53:41 aliman: in n-ary literal xl label doesn't occur at all 18:54:18 Ralph: i think n-ary literals is a bad idea 18:54:40 literals can't be subjects 18:55:25 JonP: has no preference, but is deeply suspicious of n-ary relations between literals (Tom and Ralph) 18:56:04 Tom: there are communities who want to associate annotations with lexical label relations 18:56:20 aliman: i'm not saying i prefer one over the other, they all have unexplored consequences 18:56:34 the subject, which is an RDF URI reference or a blank node 18:56:43 (from RDF Concepts) 18:57:09 GuusSchreiber: i think Ralph's point is that this is potentially dangerous territory 18:57:17 If they all "have unexplored consequences", this seems dangerous to make any choice. 19:00:32 TomB: the question is to have two variants or one 19:00:44 ... 1) whether to adopt XL approach 19:00:57 ... 2) how many variants 19:01:12 ... 3) is it in scope for the reference or a note 19:01:43 GuusSchreiber: we could be in a non-normative section of the reference 19:02:04 aliman: we just need to make it clear that XL is optional 19:02:14 +1 for alistair's comment 19:04:25 There's always room for an XXL 19:04:51 we have to think about the actual namespace name 19:05:02 and we have to think of the actual vocabulary in that namespace 19:05:23 the label relations stay the same 19:05:55 scribenick cgi-irc 19:06:12 scribenick: cgi-irc 19:06:47 scribenick: edsu 19:08:05 scribenick: Ralph 19:08:12 Ralph++ 19:08:39 Can't make that kind of restriction in OWL 1 (card on annotation) 19:08:40 Alistair: rdfs:label is a built-in; what are the consequences of adding a [local] cardinality constraint on a built-in? 19:08:43 Guus: good point 19:09:18 ... in the current OWL-DL, yes, Alistair is right; you can't make this sort of restriction 19:09:24 Sean: yeah, agree -- can't do it 19:09:30 ... unclear whether OWL 2 will relax this 19:09:50 ... it may be possible but I wouldn't want to rely on it for SKOS-XL 19:09:57 ... there's a notion of annotation spaces in OWL 2 19:10:10 ... the idea is to define or provide semantics for reasoning within the annotation space 19:10:12 Are Skos labels not really annotations then? 19:10:19 ... it will be richer than the annotations in OWL 1 19:10:30 They're the first class objects for a controlled vocab language. 19:11:42 In many ways, they are the resource 19:11:48 Guus: can postpone the decision [on xl:literalForm vs rdfs:label] 19:12:37 FWIW I added XML examples of two label relations pattern to http://www.w3.org/2006/07/SWD/wiki/WashingtonAgenda/LabelIssues which is included in http://www.w3.org/2006/07/SWD/wiki/WashingtonAgenda 19:12:44 ACTION: Sean to write a proposal to indicate to OWL WG our requirements for annotation properties 19:14:16 PROPOSED: to accept sections 3, 4,6 of the 14 April -XL proposal and the vocabulary defined there 19:15:45 PROPOSED: to accept sections 3 (xl:Label), 4 (Preferred, Alternate, and Hidden xl:Labels), 6 (Binary Relations Between Instances of xl:Label) of the 14 April -XL proposal and the vocabulary defined there 19:16:21 no objections 19:16:26 RESOLVED: to accept sections 3 (xl:Label), 4 (Preferred, Alternate, and Hidden xl:Labels), 6 (Binary Relations Between Instances of xl:Label) of the 14 April -XL proposal and the vocabulary defined there 19:16:53 ACTION: Guus and Alistair write text for Reference indicating understanding of a possible need for future patterns 19:17:08 s/patterns/patterns for n-Ary label relations/ 19:17:51 PROPOSED: Include label relations in SKOS Reference as OPTIONAL and NORMATIVE 19:18:23 PROPOSED: Include XL section 3, 4, 6 in SKOS Reference as OPTIONAL and NORMATIVE 19:18:42 s/section/sections/ 19:19:02 RESOLVED: Include XL sections 3, 4, 6 in SKOS Reference as OPTIONAL and NORMATIVE 19:19:26 PROPOSE: http://www.w3.org/2008/05/skos-xl# as XL namespace 19:21:31 RESOLVED: Use http://www.w3.org/2008/05/skos-xl# as XL namespace URI 19:21:44 Tom: note 2 advantages: 19:21:48 ... 1 resuse of prefLabel, etc. 19:21:56 ... 2 explicitly OPTIONAL 19:22:12 ... 3 makes it easy to spot a document instance that uses XL 19:33:57 The librarian of congress just brought in a magnum of bolly 19:34:05 in my mind 19:37:01 Clay has joined #swd 19:41:52 aliman has joined #swd 19:42:02 [continued discussion on mapping relations] 19:42:28 GuusSc has joined #swd 19:43:40 Topic: SKOS Mapping 19:44:01 -> http://www.w3.org/2006/07/SWD/wiki/WashingtonAgenda/MappingIssues SKOS Mapping Issues 19:44:24 related to issues 71, 73, 74, and 75 19:44:28 zakim, who's on the phone? 19:44:28 On the phone I see [LC], SeanB 19:44:29 [LC] has Antoine, Guus, Clay, Alistair, Simon_Spero, Ed, Barbara_Tillett, Tom, Ralph, Jon 19:44:29 I'm here 19:45:23 zakim, lc no longer has Barbara_Tillett 19:45:23 -Barbara_Tillett; got it 19:45:32 TomB has joined #swd 19:46:07 Antoine: usage scenario A concerns semantic relationships between concepts in a scheme; standard stuff 19:46:23 ... scenario B concerns mapping between different schemes with related concept 19:46:45 ... we propose using mapping properties from the current proposal 19:47:13 ... (exactMatch, relatedMatch, broadMatch) 19:47:54 ... two new scenarios; (C) shows a new scheme that reuses concepts from another scheme 19:48:17 ... a variant of this scenario builds an umbrella scheme using concepts from two other schemes 19:48:38 Alistair: these are really the same pattern; the idea is to be able to reuse a schema that someone else has created 19:49:01 Antoine: next scenario is defining relationships between two existing schemes 19:49:16 ... how to represent new relationships for your application 19:49:42 ... relations not necessarily approved by the scheme owners, or relations that are speculative 19:50:27 ... there was an initial assumption that relationships between schemes were all mapping relations whereas relations within a single scheme were not 19:51:58 Guus: so two cases are relationships between two schemes; ok because no one "owns" these relations, and relationships within a scheme that aren't stated by the scheme owner 19:52:02 Old reason to distinguish was broader was hierarchical, but broad match might have errors 19:52:36 Antoine: when a scheme is the concepts plus the relationships between them then when you add relationships you could say you have created a new scheme 19:52:56 Alistiar: but what you want is for the application to be able to load all the triples and treat them as a single concept scheme 19:53:15 ... but if the application does want to differentiate it can recall where the triples came from and use that provenance 19:53:47 Guus: the primary scenario for me is mapping between two existing schemes 19:54:44 Alistair: call these two scenarios "KOS Description", "KOS Mapping", "KOS Extension", and "KOS Enrichment" 19:55:14 ... for KOS Description, consider linking LCSH to the Semantic Web 19:55:41 ... I can offer a new concept scheme that includes LCSH 19:55:50 Guus: this scenario occurs often 19:56:30 ... e.g. I'm working on a project that uses TGN but each time we encounter a location that's not in TGN we want to add a local concept for this new location. 19:56:50 ... when we do this we want to define relations between the TGN concepts and our new local location 19:57:00 ... it happens a lot that organizations want their own local extensions 19:57:02 -SeanB 19:57:08 Alistair: we're calling this KOS Extension 19:57:14 ... different from KOS Enrichment 19:57:36 Antoine: in some cases the relationships are about the meaning of the concepts; these are inherent to the concepts 19:58:02 ... KOS Description and KOS Extension are these 19:58:16 ... in other scenarios the new relationships are not inherent 19:58:29 Simon: this is the difference between hierarchical and associative relationshiops 19:59:06 Alistair: the decision points I see are in scenario A, we use broader/narrower but want to identify the mapping cases 19:59:24 ... in scenario C we want applications to be able to treat the result as one big concept scheme 19:59:42 ... the controversy is over scenario D where the question is whether or not to rely on graph provenance 20:00:15 seanb has left #swd 20:00:21 Antoine: perhaps we can define some meaning to distinguish the mapping relationship from the semantic relationship 20:01:23 ... alternatively we could rely on a syntactic distinction; mapping is always between two schemes and require that extension always include the original scheme 20:01:35 Guus: but this would take us into discussing the meaning of imports 20:02:03 Alistair: so extension would use the semantic relation properties 20:02:32 Guus: what happens when a concept belongs to multiple schemes? 20:02:50 Alistair: you have to explicitly state when a concept is in your scheme 20:03:22 Antoine: and I do KOS Extension with mapping, though from a technical perspective we could go with the provenance solution 20:04:21 Tom: the proposal seems like a convention of etiquette; is there a set of technical reasons to distinguish the cases where the boundaries are blurred? 20:05:05 ... is there any reason other than etiquette to require the use of skos:broader only when you're in a position to be defining inherent semantics? 20:05:20 Alistair: I think that is Antoine's point of view 20:05:45 ... the goal is to allow SKOS browsers to easily display a single concept scheme for scenario A 20:06:01 ... in scenario B you want the browser to display 2 schemes with relationships between them 20:06:14 ... in scenarios C and D you also want the browser to display a single scheme 20:07:03 ... so for A, C, D you can use broader/narrower/related but in B you want broaderMatch/narrowerMatch/relatedMatch 20:07:21 ... i.e. use the vocabulary to indicate what's special about B. KOS Mapping 20:07:58 Tom: the difference between scenarios (e.g. C and D) are hazy and might even morph over time 20:08:17 Alistair: but an application doesn't really need to know the difference between C and D, or between A and C 20:08:41 ... B. KOS Mapping is the only case where the application really needs to be able to tell the difference 20:08:53 ... the easiest way to do this is to provide more properites 20:09:04 Guus: we do a lot of these thesaurus alignments 20:09:23 ... consider Wordnet's notion of Artist and the AT Artist 20:09:41 ... Wordnet:Artist has a much broader natural language meaning than AT:Artist 20:10:04 ... I want to express this relationship; why couldn't I use broader vs. broaderMatch? 20:10:23 ... my first intuition is that skos:broader is OK, it just has a different provenance 20:10:32 ... but is there a good semantic reason for distinguishing? 20:11:01 Alistair: if you're doing ontology mapping you assert links and the application knows that it's loading data from 3 places 20:11:19 ... you don't need special properties because you know the 3 data sources 20:11:52 Antoine: but these mapping applications often have their own formats for storing the mapping data 20:12:09 Alistair: most OWL applications work because they really know where the data is coming from 20:12:23 ... to what extent do we think SKOS applications need to be able to handle data with unknown provenance? 20:12:38 ... suppose Guus links two concepts with skos:broader and publishes his relation in the Web 20:13:25 ... then a SKOS browser comes across Guus' published data and starts to use the data 20:13:43 Ralph: but this is a general issue for all SemWeb tools -- how to decide whether to "use" any triple it happens to find 20:13:59 Antoine: so do we have a case that warrants a special solution? 20:14:33 ... in my experience, the mapping folk are happy to use skos:broader/skos:narrower and don't need special mapping properties 20:15:18 Guus: I have a paper that does use mapping relations 20:15:42 ... for me, case B KOS Mapping is the important case because we do have users of it 20:15:54 ... we have to decide whether provenance is sufficient 20:16:22 ... we have users for scenario B and not for C and D 20:17:24 s/a paper/a paper from @@/ 20:18:15 Jon: in my metadata registry I instantiate a narrower relation whenever anyone asserts a broader relation, independently of provenance 20:18:42 ... however we don't do this for the broadMatch relation 20:19:36 ... we think it's important that users creating relationships between schemes include the schemes they're referencing 20:19:46 ... we look at concept schemes as distinct entities 20:19:56 ... if a user wants to extend a scheme they should include it in their own 20:20:01 ... that keeps the provenance clean 20:20:37 ... once a concept is included in a new scheme, they can assert anything they want about it 20:21:09 ... note that we don't actually do this at the moment but it's the direction we're headed to solve our provenance problems 20:21:50 ... we prefer to have a separate mapping vocabulary to allow users to assert relationships between concepts without requiring them assert additional relationships 20:22:13 ... e.g. the inference of a narrower relation whenever a broader relation is found but not when a broadMatch relation is found 20:25:24 Ralph: there's a general notion of scope of a triple here 20:25:33 ... provenance is only one example of scope 20:25:38 Jon: we have a notion of 'ownership' 20:26:08 ... when I make assertions about concepts that Alistair owns, it's important that I not be able to assert false relationships about concepts he owns 20:26:36 ... when someone makes assertions about Alistair's concepts, they become part of that scheme in the registry 20:27:08 ... in the context of our registry there's no separation of the sources of the triples; a registry user always finds all the triples 20:27:26 ses has left #swd 20:27:36 ... so we want to add provenance so that when I add a mapping it does not become part of Alistair's scheme 20:27:37 ses has joined #swd 20:29:51 Ralph: but I think Jon's registry will want to distinguish provenance for any property 20:30:05 ... consider whether Alistair asserted that he is dc:creator or forgot to do so 20:30:14 http://www4.wiwiss.fu-berlin.de/bizer/SWTSGuide/ 20:30:25 ... and what if Alistair wants to assert broadMatch on a concept within his scheme? 20:30:41 Guus: I'm wondering if this whole issue has more to do with provenance 20:30:52 Antoine: but it really does have some semantics within the graph 20:31:33 Alistair: one line of thought is that this really is just about provenance and that's nice because it makes the model simple 20:31:45 ... to make a separate set of properties leads to combinatorial explosion 20:33:04 ... but if you talk to KOS people who do mapping they do think they're doing something fundamentally different (with broadMatch vs. broader) 20:33:20 Tom: when did broadMatch get added to SKOS? 20:33:29 Alistair: very early on in SWAD-Europe 20:34:36 ... but we didn't have a lot discussion of the differences between the two sets of vocabulary 20:36:14 ... broaderMatch was a convenient hook for applications that didn't need to look too deeply into provenance 20:37:08 ... if we drop broaderMatch then I think we'd have to invent something else like a MappingGraph Class 20:37:18 ... or a skos:MappingScheme 20:37:44 Tom: so conventions of etiquette 20:38:21 ... the evolution of SKOS did lead to a distinction between mapping and concept scheme definition 20:38:52 ... if we make clear that the difference is rooted in cultural concepts of what is a mapping vs. definition of a concept scheme 20:39:21 Guus: so we may have sufficient motivation for a separate set of mapping properties 20:39:35 ... but then we have to define the semantic relationship between the properties 20:39:39 Antoine: there is no relationship 20:39:46 ... one can't imply the other 20:40:10 Guus: consider AT:Artist and Wordnet:Artist 20:40:22 s/AT:/AAT:/ 20:40:57 ... wn:Artist skos:broader wn:Person. 20:41:10 .... aat:Artist skos:broadMatch wn:Artist. 20:41:53 ... I would like to be able to derive aat:Artist ?p? wn:Person. 20:42:12 Antoine: but what exactly is the relation ?p? -- it could be skos:broadMatch 20:42:39 Guus: probably the relation is skos:broaderTransitive 20:43:02 ... the scheme alignment is nice to have only if it's useful for query 20:43:57 ... so I don't see the point of the mapping if we don't define the relationship between broadMatch and broader 20:44:34 ... if not having such a relationship is the cost of having a cultural convention then we haven't accomplished much 20:45:04 Alistair: broadMatch could be a subProperty of broaderTransitive 20:45:18 ... there are four options: 1. say nothing 20:45:27 ... 2. broadMatch subPropertyOf broader 20:45:37 ... 3. broadMatch subPropertyOf broaderTransitive 20:45:46 ... 4. broadMatch and broader are disjoint 20:46:05 Guus: ... 5. or broadMatch and broader are disjoint 20:46:42 s/disjoint/equivalent/ 20:46:50 rrsagent, please draft minutes 20:46:50 I have made the request to generate http://www.w3.org/2008/05/06-swd-minutes.html Ralph 20:47:29 Alistair: the advantage of 2 and 3 are that these reuse the data model for semantic relations 20:47:43 ... the disadvantage is that it becomes harder to distinguish when you're mapping and when you're not 20:47:54 Guus: the subPropertyOf approach will never work 20:48:10 ... because you expect broader to only work between concepts in the same scheme 20:48:22 ... the only thing I think works is to have a superProperty 20:48:54 ... it's a nice cultural etiquette but it creates lots of overhead 20:50:09 s/super/common super/ 20:50:31 s/it's a nice cultural/the cultural convention is nice / 20:51:17 Antoine: to do things properly we'd also need transitive superproperty of broadMatch and so on 20:52:32 Alistair: if there is a common superproperty of broadMatch and broader then the extensions of broadMatch and broader are disjoint 20:53:12 ... so you could use a checker to say that someone is saying 'nonsense' 20:53:22 Guus: this would be the formal translation of the cultural convention 20:54:10 Antoine: suppose at one time there's two schemes with a mapping and then later someone creates a third scheme that encompasses both the original two 20:54:26 Tom: so saying the extensions are disjoint is unhelpful 20:54:50 Guus: the consequence of dropping disjointness is that we must drop all the mapping relations except exactMatch 20:55:15 Clay: I've been doing some work using exactMatch 20:55:42 ... I like the current definition but wouldn't have a problem if they were specified as disjoint 20:56:06 Jon: what does disjoint mean in this context? 20:56:34 Alistair: given a graph that has A broader B. A broadMatch B. this graph would be inconsistent with the current SKOS data model. 20:56:46 Jon: I don't see why this restriction is unacceptable 20:57:23 Tom: the reason for broadMatch and broader is that the culture of information description that gave rise to SKOS is that mapping is somehow different from definition then enforcing that restriction in the semantics ... 20:57:37 Jon: the restriction is just that I can't say both 20:57:56 Guus: but A broadMatch B also entails that A and B are in different schemes 20:58:36 Alistair: given the graph A broadMatch B. A inScheme S. B inScheme S. is also inconsistent 20:59:17 Jon: but just saying [the extensions of] broadMatch and broader are disjoint doesn't give this constraint 20:59:30 Alistair: right, we'd also have to say this graph somewhere 21:00:07 ... but it does simplify the task to start by saying broadMatch and broader are disjoint 21:00:22 ... if we allow them to be mixed at all then we have to consider all the combinations 21:00:36 Guus: going back to the subProperty notion 21:00:59 ... could permit broader without restriction but use broadMatch if you want typing 21:01:08 ... this would be a nice cultural convention 21:01:19 ... make no restrictions about broader within or between schemes 21:01:32 ... but broadMatch subPropertyOf broader as a cultural convention 21:01:38 ... however, this is also problematic 21:01:54 Antoine: because I can envision scenarios where you ask for all broader that are not broadMatch 21:02:09 ... if you want a 'clean' hierarchy, you have to remove the extension of broadMatch from the extension of broader 21:02:22 Guus: and would still have to use the provenance of triples 21:02:31 ... but inScheme would be sufficient 21:03:18 ... PROPOSE: broader can be within or between schemes and broadMatch only used between schemes as a convention 21:04:18 Tom: if there's an evolution of two schemes merging over time into a single scheme then this restriction is problematic 21:04:32 ... there's not a logical distinction here; it's only based on intention and cultural convention 21:05:28 ... but the justification for the distinction is that there is apparently a community who sees a difference between mapping and scheme definition 21:05:47 Alistair: inScheme allows me to isolate the semantic relations for a single scheme 21:06:28 ... but how should I handle an A broader B. triple without any inScheme triples? 21:06:59 Ed: I'd hope that in general a browser would want to provide the user some context about what scheme they were currently viewing 21:07:21 ... in the case of no inScheme triples, the browser would not be able to give this semantics 21:07:30 Guus: we won't be able to nail down all the operational semantics 21:07:50 ... I'm moving in the direction of the subPropertyOf approach 21:08:00 ... this gives us a meaningful relationship between the two 21:08:28 ... whereas common superproperty would introduce an enormous overhead for something that really is just a cultural convention 21:08:47 ... I don't think this overhead cost would be worth it 21:09:51 Alistair: my concern about subproperty approach is what the application does when it encounters a broader relation without inScheme. 21:10:03 Guus: it's underspecified; maybe the author didn't care 21:10:30 Alistair: maybe the triple was inferred from broadMatch and only the inferred triples were published 21:12:13 SGorse has joined #swd 21:12:19 SGorse has left #swd 21:12:58 Clay: I currently favor the current definition where there is no relationship between broader and broadMatch because it makes provenance clean 21:14:47 Alistair: there are two camps; KOS Description and KOS Mapping 21:14:52 Clay has left #swd 21:15:13 ... if I find just A broadMatch B then I know it came from the Mapping camp 21:15:39 ... but if I find A broadMatch B. A broader B. do I say it came from Mapping? 21:16:21 ... there are six cases; broadMatch only, broader only, both X with inScheme and without inScheme 21:16:50 ... in the absence of provenance information, can I infer whether these 6 graphs came from the Description camp or the Mapping camp? 21:18:59 Ralph: is it really about authority to make an assertion? 21:19:04 Jon: yes 21:20:13 Guus: [cites paper] lots of examples; the issue comes down to mistaken interpretations 21:27:44 Alistair: refer to the graphs in MappingIssues 21:27:53 -> http://www.w3.org/2006/07/SWD/wiki/WashingtonAgenda/MappingIssues#head-416ff39e19abfd192902f944550582770a3fdb7a Usage from the Application Point of View 21:28:22 ... for each of these 6 graphs, let's decide the question ?Consistent or not Consistent? 21:28:33 ... and ask whether applications can do what they want to do 21:29:06 ... ask whether the six choices are commensurate with saying broadMatch rdfs:subPropertyOf broader 21:30:24 ... consider first graphs 2, 4, 6; no inScheme triples 21:31:16 Guus: graph 3 must be inconsistent, else broadMatch has no meaning. 21:33:10 ... if we think graph 3 is consisent then it means that there must be no semantics for broadMatch 21:33:41 Tom: you could take the view that broadMatch and broader are semantically equivalent and the only difference is a cultural one 21:34:29 ... you could arrive at graph 3 by evolution 21:35:00 disconnecting the lone participant, [LC], in SW_SWD()9:00AM 21:35:04 SW_SWD()9:00AM has ended 21:35:04 ... the only constraints are soft cultural constraints 21:35:05 Attendees were Antoine, Guus, Clay, Alistair, Simon_Spero, Ed, Barbara_Tillett, Tom, Ralph, Jon, [LC], SeanB 21:36:15 cgi-irc has joined #swd 21:37:45 PROPOSE: 1. keep the mapping vocabulary broadMatch, narrowMatch, 2. broadMatch, narrowMatch, etc. are rdfs:subPropertyOf broader, narrower, 3. there are no semantic conditions on broadMatch, narrowMatch; i.e. graphs 1-6 are all consistent, 4. there is some text about cultural conventions explaining where we expect broadMatch to be used. 21:38:20 Alistair: ammend to drop "there are no semantic conditions", keep "graphs 1-6 are all consistent" 21:38:44 ... there are no semantic conditions that make graphs 1-6 inconsistent 21:40:04 Ed: why the wording about cultural conventions? just because of prior use? 21:40:37 Antoine: making *Match be subPropertyOf the others makes the story harder to tell 21:41:46 Alistair: could say 2 statements about the mapping properties; 1. by convention, the mapping properties are only used to link concepts in different schemes, though this is not constrained by the data model 21:42:31 Guus: we do this in OWL too; we say that there's not supposed to be any non-OWL statements in an OWL namespace document but if a tool finds it it's supposed to flag it and continue 21:43:51 Alistair: statement 2; by convention, semantic relation properties are only used to link concepts in the same scheme 21:44:10 ... if broadMatch is subPropertyOf broader then we can't make statement 2 21:44:31 Guus: I'm in favor of making only statement 1 21:45:19 PROPOSE: 1. keep the mapping vocabulary broadMatch, narrowMatch, 2. broadMatch, narrowMatch, etc. are rdfs:subPropertyOf broader, narrower, 3. there are no semantic conditions on broadMatch, narrowMatch; i.e. graphs 1-6 are all consistent, 4. there is some text about cultural conventions explaining where we expect broadMatch to be used, 5. by convention, mapping properties are only used to link concepts in different schemes. 21:45:53 Jon: I don't really like it because I think the story is easier if broadMatch is disjoint from broader 21:46:16 Antoine: I don't like it but I don't object 21:46:30 Jon: I accept it but I hate it 21:46:32 [laughter] 21:46:55 Antoine: I'm hoping that the provenance will be properly dealt with 21:47:09 Alistair: look for inScheme statements 21:48:10 Ralph: I think we do need to tell the Definition and Mapping camps that we believe these are their semantics 21:48:30 Tom: if we make them disjoint because of provenance that's really opening a large can of worms 21:49:36 ... conceptually it would be cleaner to have just skos:broader but if we're accepting that there is a community of practice that sees a significant difference and people are already deploying SKOS on this basis then this is the best way to retain a difference without making semantic overcommitments 21:50:05 Ed: I prefer to keep things as simple as possible and just keep broader and narrower 21:50:23 ... I haven't heard persuasive arguments other than existing usage and it being a matter of provenance 21:50:34 Guus: we could make this a Last Call issue 21:51:08 ... explicitly asking folk who have strong opinions to give us feedback 21:53:57 ... for Last Call I would like explicit consensus in advance about alternatives 21:54:18 ... otherwise we might have to produce a new Last Call draft 21:54:31 ... the only alternative I see is to drop the mapping properties 21:54:41 Antoine: what about disjoint? 21:54:46 Guus: I don't think we'd get consensus on that 21:55:30 Ed: I can live with the resolution 21:55:47 Simon: I do not believe that this discussion affects anything 21:56:27 Alistair: I can live with the proposal 21:56:47 ... from a technical point of view, I think dropping *Match is the right thing 21:57:06 ... if we make this a Last Call option then most of the comments will be from people who want to keep it 21:57:28 ... if we want to drop it we need to make a strong statement to that effect and be prepared to engage in a strong conversation to educate the community 21:57:49 ... if we do decide to keep *Match then because of Tom's point that things might change over time then we don't want to say they're disjoint 21:58:12 ... if there's an option to consider making the mapping properties an optional extension ... 21:58:55 Tom: would make sense to make it optional if there's a note that says skos:broader can be used 22:01:15 PROPOSE: 1. keep the mapping vocabulary broadMatch, narrowMatch, 2. broadMatch, narrowMatch, etc. are rdfs:subPropertyOf broader, narrower, 3. there are no semantic conditions on broadMatch, narrowMatch; i.e. graphs 1-6 are all consistent, 4. there is some text about cultural conventions explaining where we expect broadMatch to be used, 5. by convention, mapping properties are only used to link concepts in different schemes, 6. in the Last Call WD we'll note that th 22:01:52 s/that th/note that this vocabulary may be dropped 22:02:41 RESOLVED: 1. keep the mapping vocabulary broadMatch, narrowMatch, 2. broadMatch, narrowMatch, etc. are rdfs:subPropertyOf broader, narrower, 3. there are no semantic conditions on broadMatch, narrowMatch; i.e. graphs 1-6 are all consistent, 4. there is some text about cultural conventions explaining where we expect broadMatch to be used, 5. by convention, mapping properties are only used to link concepts in different schemes, 6. in the Last Call WD we'll note that t 22:02:54 s/note that t/note that the mapping vocabulary may be dropped 22:02:58 rrsagent, please draft minutes 22:02:58 I have made the request to generate http://www.w3.org/2008/05/06-swd-minutes.html Ralph 22:07:46 Zakim has left #swd 22:15:48 JonP has joined #swd