IRC log of swd on 2008-05-06

Timestamps are in UTC.

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