W3C

- DRAFT -

SWD Face-To-Face

06 May 2008

Agenda

See also: IRC log, previous 2008-04-29, day 2 minutes

Attendees

Present
Antoine Isaac, Guus Schreiber, Clay Redding, Alistair Miles, Ed Summers, Tom Baker, Ralph Swick, Jon Phipps, Sean Bechhofer, Simon Spero (observer), Barbara Tillett (guest)
Regrets
Quentin Reul, Diego Berrueta, Elisa Kendall
Chair
Guus, Tom
Scribe
Antoine, Tom, Ed, Ralph

Contents


 Guus: charter extension has been approved

RESOLVED: to accept minutes of 29 April telecon

Guus: schedule should go as on the agenda

SKOS Scoping

Feature: Notations

Alistair: this feature is about support for codes for identifying concepts
... mostly in classification schemes
... It is widely used.

Guus: you're thinking about Iconclass or DDC

Alistair: one pattern is to use prefLabel with a specific tag
... proposed by Jakob
... a second is to have another SKOS relation, like skos:notation

Simon: some concepts have multiple notations

<Ralph> Antoine: I prefer Jacob's proposal for prefLabel

<Ralph> Jacob's proposal

Clay: we've used that as well

Antoine: I like Jakob Voss proposal (prefLabel)

Alistair: does anyone have motivation for leaving it out?

Ralph: how hard is it to use?
... the thing I don't like about Jakob's proposal is that it is a whole new syntax

Ralph: literal value would have structure that is peculiar to SKOS
...Jakob proposes to embed language information in literal,

Guus: would be normal to define datatype for it

Ralph: actually Jakob made a typo
... so I'm more comfortable with it now

Alistair: do we spend more time on it?

Guus: I think we can do this with guidelines, it should not affect the voc
... it's worth supporting

Feature: (Subject) Indexing

Antoine: about links to resources - existing vocabulary like
....skos: subject - or do we prefer to delegate to other vocabularies, like
....skos: dublin core?

<aliman> blog post about this meeting

Antoine: reason for removing - bc can be supported by other vocabularies
...dc: subject might be appropriate
... other argument for removing: these links are not part of the inherent meaning of a subject

<Ralph> issue-77 SubjectIndexing

Simon: in classical knowledge organization, concepts defined by the documents they index

Antoine: an "extensional" view.

Simon: dc:subject is polluted

Guus: seems to be outside the scope of SKOS
... if you have a thesaurus of artist names, will be typically dc:creator
... My preference is to drop completely.

Simon: In MARC, diff btw authors and creators and people who are subjects,
... though stored in similar authority records...

Guus: leave this out of scope.

Edsu: could still reference old vocabulary

Ralph: likely to mix old and new vocabularies.

Guus: low on the priority list.
... only problem is deprecation.

Feature: Symbol (Image) Labels

Alistair: dates back from the beginning of SKOS

<aliman> Evolving list of priorities

Simon: has anyone implemented it?

Feature: Mapping Between Concept Schemes

Guus: It's not an option to drop it
... almost everyone who uses SKOS I know use it

Alistair: so it goes top in the priority list

Feature: Labels as Resources

Guus: it belongs to the top of the list

Feature: Label Relations

Guus: I thought it was with the previous one
... the main discussion should be:
... there are solutions on the table
... we should make sure what their status is: part of SKOS? notes?

Alistair: so this goes in scope

Feature: Reference Semantic Relation Specialisations (broaderGeneric etc.)

Alistair: these were previously defined in the non-core part
... people may want to use it
... but they raise problems

Simon: this goes straight at the difference between KOS and ontologies
... it has been defined in terms of what you want to get back when you search
... if they don't have a clear meaning in SKOS...

Feature: OWL Imports

Alistair:do we leave the door open to use it, or do we ignore it?

Guus:an editorial item (Primer), not normative

Guus:my proposal is to show examples of owl imports in the Primer but not normatively describe it in the Reference

Sean:concerned we understand consequences

Guus:problem where we need to know provenance of triples

Antoine:would leave this to annex, with OWL-related problems

Antoine:I'd even omit from the Primer, as owl:imports doesn't solve the problem that people want

Sean:if you remain completely silent on it, people will use it
...point out issues
...issues = unexpected consequences

Sean:if you don't say anything, people will use it anyway

Alistair: if we focus on the consequences of using it
... it could be ok

Guus: the primary use case is the provenance
... in case the vocabulary is spread in different files
... owl:import is an option

Sean:but you still need external mechanisms to give the provenance if your vocabulary comes from several places

Guus:If you have namespace document, "provenance of this triple is this graph" - simple mechanism

Alistair: you would use to prevent duplication of triples

Guus: if you use this graph you should consider this graph as well
... it requires some joint action

Guus:Sean and I can work this out

Guus: I'm happy to work on it with Sean

Sean: OK

Feature: SKOS Imports

ACTION: Guus and Sean propose some owl:imports text for Primer [recorded in http://www.w3.org/2008/05/06-swd-minutes.html#action01]

<Ralph> RESOLVED: SKOS Imports low priority

Feature: Coordinated Subject Indexing

simon: it's used

Antoine: the Mapping use case uses this

Sean: composite indexing strays into OWL territory

Guus: I was supposed to write a resolution to postpone this issue -
... that is the most likely outcome
... depending on time, could come up with OWL examples...
... but I consider risky.
... If there are examples of using OWL, we could point that it.
... the most we could do.
...OWL: you have a concept that consists of ....
... need to explain how that relates to OWL union

Alistair: Now clear how to say, in OWL, "this is about sideeffects of aspirin'
... you can bundle into new unit, use that....

Guus: if it is still a battle, then definitely out of scope

<seanb> I'd like to see it out of scope.

Guus: would welcome text from, say, LC.
... but late to introduce into vocabulary

<seanb> I think it's rather late to try and define such a semantics

Edsu: out of scope

Feature: XML Literal Notes

Alistair: would be nice to have clear pattern but could live without

Guus: can't you standard RDF facility for this?

Alistair: documentation property as related resource description
... could give content type
... but no clear requirement in Use Cases and no mature proposal
... so out of scope

Feature: N-Ary Thesaurus patterns

Antoine: related to coordination
... if we had a solution to this, would have solution for coordn

Alistair: this is not a link between descriptors
... propose this be out of scope.

Antoine agrees. Would like it to be in scope, but no time.

<aliman> http://www.w3.org/2006/07/SWD/wiki/WashingtonAgenda/SkosPriorities

SKOS Namespace

<Ralph> Re: Deprecated SKOS Vocabulary [Sean 2008-04-09]

<Ralph> Draft SKOS Schema [Sean 2008-04-29]

summary of namespace issues is on that page

Guus: fact that it is not OWL-DL is not the issue

<Ralph> Guus: annotation properties are the only thing that's keeping this from being OWL-DL

<Ralph> ... the only thing of any substance

Sean: OWL 2 will cover this
... what do we do in interim? Publish one schema which is DL, one that is not?
... I have an OWL Full schema. Useful to have that recorded somewhere.

Guus: Given that we are in transition state, publish this as currently is.

Sean: though the schema we publish will be DL, but we will be declaring ObjectProperties.
... we can publish an OWL-DL schema, but usage will push people into OWL Full.

Guus: We don't publish OWL-DL schema. Publish as is.
... otherwise, people inclined to use differently.

<Ralph> +1 for not restricting our schema to OWL-DL

Guus: differences have nothing to do with computational complexity, etc.

RESOLVED: Publish RDF schema as is (OWL Full)

Alistair: with rdf:list - just leave this range triple out of schema
... we have said the text of the reference will be normative
... we have already said that the RDF schema might not capture everything normative.

Sean: almost some inconsistency - things allowed into schema and not allowed.
... if we publish the schema as is, some triples make it OWL Full.
... Some stuff is OWL Full for annotation purposes - can ignore.
... If we don't put in rdf:list, slightly inconsistent.

Guus: provide recipe for making OWL-DL.
... OWL 2 will come up with something that makes this necessary.

Sean: Arguments for keeping it out - OWL 2 will probably solve -
... but makes for complicated story.

Guus: Smaller story to tell about making DL-compliant.
... Include rdf:list triple, keep OWL Full.

<ses> *

<ses> A: Keep old namespace, don't include deprecated vocab.

<ses> *

<ses> B: Keep old namespace, include deprecated vocab (and mark as such)

<ses> *

<ses> C: Define new namespace, with only new vocab.

Sean: I proposed the B option, did not really like A
... my preference goes for C though

<ses> http://www.w3.org/2006/07/SWD/wiki/SkosDesign/RdfSchema

<GuusS> http://lists.w3.org/Archives/Public/public-swd-wg/2008Apr/0032.html

<GuusS> thread on deprecated vocabulary

Simon: if the semantics of old and new SKOS are incompatible, A and B are not tractable

Alistair: not necessarily true

Guus: people have tools that upgrade their vocabulary
... it would be confusing not to upgrade the namespace, actually

Jon: is there a strong argument for sticking to the old namespace?

Guus: people using the old namespace would migrate without problem

Alistair: I agree with creating a new namespace

Guus: anyway as long as the old namespace is there, nothing is made incoherent

Ralph: new tools may want to acknowledge the latest document but still to do things with the old one

Guus: that's actually an argument in favor of having old and new separate

Jon: in the metadata registry, there is a casacading effect
... some dependencies that are difficult to track

Guus: if people are happy with the old namespace, we can' prevent them to use it

Guus: I wrote a list of differences between DAML and OWL
... PROPOSE to create a new namespace
... PROPOSE that either the Reference or the Primer say something about the differences

<Ralph> Old SKOS WD

Tom: what about the redirections from the SKOS URL to the most recent WDs?

Ralph: there is indeed a redirection
... from the old WD to the new one (by the 'latest version' link
... )

<Ralph> Ralph: we made a new "Latest Version" URI for the current SKOS: "http://www.w3.org/TR/skos-reference/"

<Ralph> ... and we redirect the old "Latest Version" URI http://www.w3.org/TR/swbp-skos-core-spec

Antoine: for the moment the URL of latest version of the old Guide redirects to the Primer

Ralph: we could have the Guide redirect to a page linking to Guide *and* Primer

ACTION: Ralph compose 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 [recorded in http://www.w3.org/2008/05/06-swd-minutes.html#action02]

RESOLVED to have a new namespace

ACTION: Alistair to check the old namespace wrt dereferencing [recorded in http://www.w3.org/2008/05/06-swd-minutes.html#action03]

<Ralph> Ralph: I propose /2008/05/skos

Guus: Sean's document will be on this space

Alistair: which receipe are we going to use for publishing the document?

<seanb> Do you mean hash/slash etc Alistair?

Guus: it's a very clear receipe, the document is small

<seanb> oops...:-)

Alistair: receipe 3

Jon: 3 is fine

Alistair: the HTML de-referencing could point to the Reference doc

Guus and Ralph: we're surprised when we see this

<TomB> Guus/Ralph: expect to see screen-friendly version of RDF schema

<TomB> ...not a document like Reference

Alistair: I could write a small HTML from the quick access table

Guus: in OWL there is an appendix that played this role

Ed: I would argue for using as a summary what can be found in the Reference

Alistair: what if you have three documents: one HTML doc, one HTML table, and the schema

<TomB> http://www.w3.org/TR/2008/WD-skos-reference-20080125/#related

Ralph: at the end the SKOS recommendation should consist of one document
... in the 'print' sense

Sean: the OWL documents were published as a bundle of documents

Alistair: the problem is that an HTML 'first page' would not be W3C-labelled

<scribe> scribenick:Antoine

Ralph: I think I prefer the duplication

Guus: let's let the editors decide

ACTION: Sean and Alistair to send a file for the namespace [recorded in http://www.w3.org/2008/05/06-swd-minutes.html#action04]

<Ralph> PROPOSE: http://www.w3.org/2008/05/skos# for the namespace URI

RESOLUTION: http://www.w3.org/2008/05/skos# is the namespace URI

Related Irreflexive? Broader Irreflexive? Broader Cycles? (Issues 68, 69, 70)

Guus: the new OWL spec will contain primitives
... to represent these characteristics
... it's potential an easy addition to the semantics
... my proposal is that we focus on the features allowed by OWL 2

Alistair: three questions:
... are broader/related reflexive? are there cycles in broader?
... last condition = "is broaderTransitive irreflexive?"

Tom: how about the OWL/SKOS patterns that a strict data model would prevent?

Alistair: most KOS users would have the 3 properties irreflexive
... some that map OWL properties to SKOS properties would not be allowed

Alistair: I can see value in saying yes to all 3 questions

Guus: We could still have brooderGeneric subproperty of rdfs:subClassOf
... or have broaderGeneric as a subproperty of both broaderTransitive and rdfs:subClassOf

Alistair: we could still say that most tools should check these conditions

<ses> 3.1 Hierarchical relationships

<ses> Dextre Clarke defines a hierarchical relationships as one “assigned to a pair of terms when the

<ses> scope of one of the terms totally includes (is broader than) the scope of the other.” (Dextre Clarke

<ses> 2001, p. 42)

<ses> Milstead confirms that total inclusion is the key criteria: “[The part-whole relationship] only has

<ses> to meet the test of always being true, just as with the other hierarchical relationships.”(Milstead

<ses> 2001, p.60)

Sean: if you have statements in the SKOS reference about irreflexivity
... that's quite strong

<ses> Both in Bean and Green

Sean: my inclination would not to have these assertions
... given that the definitions of the relations there are quite "whooly"

Tom: could we have them in the non-normative part (rule of thumb)

Sean: in that case I would prefer to have rule of thumb in the documents again

<ses> ``Elsewhere in this volume examples are given which demon-

<ses> strate clearly that the application of the hierarchical relationship

<ses> in actual thesauri is frequently not nearly as rigorous as the stan-

<ses> dards recommend. An operation may be subordinated to a phys-

<ses> ical entity, or a subordination that does not always apply may

<ses> be treated as hierarchical. It is very tempting to do this, and it

<ses> is easy to make the argument that a user who wants everything

<ses> on the broader subject would expect information on the narrower

<ses> subject to be included. However, actual development experience

<ses> has repeated ly demonstrated that extending the criteria for hier-

<ses> archical relationships is fraught with dangers. Any attempt to

<ses> define broader criteria (rather than just deciding on the relation-

<ses> ships ad hoc) runs into problems. . . . Unless a better, rigorously

<ses> definable substitute can be found, it is preferable to stick with the

<ses> provisions of the standard.

<ses> Jessica Milstead''

Jon: there are potential spaces where it could be important to be reflexive
... in order to keep the vocabularies in SKOS

Simon: about synonyms

Alistair: we would not use broader and narrower to define synonyms

<Ralph> Antoine: I could live with broaderTransitive being a reflexive closure over broader

<Ralph> ... but still disallow cycles

Tom: how would the reference say that?

Guus: Ralph mentioned that subClassOf is reflexive so as to model equivalence
... when it could not be modelled without subClassOf cycles
... how about asymmetric?

Alistair: asymetric is subsumed by antisymetric
... so I did not ask the question

<seanb> Will be back in about 1.5 hours.....

<seanb> Enjoy lunch!

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

Ralph: it might be helpful to actually provide the triples, which could be added to a checker

JonP: would be useful

guus: i think (like transitivity) you should mention it in reference

Ralph: we don't want to have stronger level of constraint in the normative version of skos

aliman: there are notes on this in the reference

PROPOSED: to resolve skos:related, skos:broader and skos:broaderTransitive are not normatively irreflexive

for ISSUE-68, ISSUE-69, ISSUE-70

<ses> Associative relationships are *defined* as being relationships which aren't hierarchical

<Ralph> Sean, any objections or comments on the proposal on the table?

<seanb> What's the proposal?

ACTION: alistair and sean to add a note about irreflexivity to Reference [recorded in http://www.w3.org/2008/05/06-swd-minutes.html#action05]

<Ralph> PROPOSED: to resolve skos:related, skos:broader and skos:broaderTransitive are not normatively irreflexive

Tom: seconds

<seanb> This is ok with me -- I preferred the less restrictive solution

RESOLUTION: to resolve skos:related, skos:broader and skos:broaderTransitive are not normatively irreflexive

ACTION: antoine, ed to add content to Primer about irreflexivity [recorded in http://www.w3.org/2008/05/06-swd-minutes.html#action06]

Labels as Resources, Label Relations (Issues 26, 27)

GuusSchreiber: this was raised at our very first f2f
... every vocab owner has a use case for this
... we have the current proposal in the reference and primer
... there is the XL proposal on the table
... is it ok to say the XL proposal has met with general approval?
... I want to postpone the discussion of whether XL should be part of the REC or not
... I like how prefLabel has a deeper semantic meaning in XL

JonP: I agree

GuusSchreiber: lets talk about the different patterns, what should happen to the current pattern in the reference, the n-ary pattern
... I think we'd like to have one preferred pattern
... my view is that the XL pattern is the most intuitive one

aliman: which of the 3?

GuusSchreiber: the binary one
... I think it's the most natural ... having one in the Primer document and one in the XL namespace is confusing

aliman: your preference is to move all three patterns into the XL namespace?

GuusSchreiber: my preference is to have support just for binary relations, but can live with other views

aliman: my preference is to have all label relations in XL, and in XL to have all three options, with no preferences
... with n-ary you can have more than two labels in a relation, and provide context to relationships
... it's not clear to me which of these three is going to be generally appropriate

GuusSchreiber: we have the use cases, where the binary pattern is sufficient
... why do you need the context?

aliman: RDA (Resource Description and Access | Recommended Daily Allowance)

<ses> controlling for Polysemy is what controlled vocabs are for

GuusSchreiber: but everything gets a URI
... the only way to solve this is to go the full wordnet route: semantics, sense and word form
... if we just have concept and label this is what we have to work with

<ses> Extracting dot/A/B/Abduction_(Canon_law).dot

<ses> Extracting dot/A/B/Abduction_(Logic).dot

aliman: implicit in the decision you will make is your decision to model things using binary relations
... there are consequences to these decisions

GuusSchreiber: we should give preference to how easy it is to learn
... and the use cases are covered largely by binary relations

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"

GuusSchreiber: but the binary solution is the simplified version
... after they understand that they may encounter further complications

aliman: I can capture the relationship between WHO and World Health Organization without introducing new classes of resources
... i find n-ary simpler, work with literals that have clearly defined identity semantics

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
... if you are forced to think of them as blank nodes, it's difficult

aliman: it's not clear that 1 of the 3 should be held up as the_one to use

<ses> RDF is hostile to N-tuples

<ses> (Think about how much easier RDF provenance/trust would have been if there n-tuples)

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

aliman: i'd like to see what people use in practice

Ralph: it seems that I could say someone is mislabeling things if RDA is shared

GuusSchreiber: lexical resource community have gone through this, which is why we have the 3 types in wordnet
... how often to we really get into this difficult situations

aliman: we don't know, it's not obvious that binary is simpler in the long run

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

<ses> Murphy carefully distinguished between lexical relation and relations between the denoted concepts

<ses> Murphy - Semantic Relations and the Lexicon

<ses> Label relationships must be the former

-> Tom's comments

GuusSchreiber: if people who are experts on SKOS, how are we going to make it clear to users

aliman: i'm more than happy to do what the consensus of this room is

GuusSchreiber: i think we need to keep an explicit door open

aliman: i've drawn two examples up: the top is the n-ary relation, and the bottom is the binary relation

TomB: it's not the way I pictured it [Tom makes an alternative drawing]

<ses> seanb - do you want a picture of the flipchart?

we're looking at 8.5 in the Reference

GuusSchreiber: i have strong preference for non foo/bar examples :)

seanb, http://www.flickr.com/photos/inkdroid/2470890333/

JonP: http://www.flickr.com/photos/inkdroid/2470890303

<ses> What about gendered and plural terms?

<ses> f.sg / m.sg / m.sg / m.pl ?

<ses> lexical relationships (between words)

GuusSchreiber writes down the binary relation rdf/xml example

aliman: the use cases are covered by both n-ary and binary relations
... you get context with the literals

GuusSchreiber: it's more accepted principle that Strings don't have identity

aliman: but in rdf that's not true

GuusSchreiber: just speaking about how people model
... if you need to give identity to a string you give it an identifier

aliman: but you don't give identity to a string, you give it to the resource

GuusSchreiber: there's nothing like uniqueness of strings, they just replicate like numbers

<ses> "RDA

<ses> "RDA" == "RDA"

<ses> With xl, labels aren't strings, they're objects

aliman: when you get into the xl label class you get into the modelling where you have to make decisions

<ses> That have literal values

<ses> a.value = "RDA" , b.value = "RDA"

<ses> (equals a b) but (not (eq a b))

aliman: you and antoine have come to a different intuitive understanding of what this xl class is used for

Antoine: if we define this understanding/consensus then we're ok

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

JonP: if we substitute literals for terms ...
... 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

aliman: can you provide an example?

JonP: synonyms, antonyms

ses: relationships between the words, not between the meanings of the words

Tom: i would support making a decision for the binary relation

Ralph: i don't have a handle on the use cases to see if n-ary is needed

<seanb> Found it hard to follow everything.

<seanb> My impression is that there is no clear front runner based on use cases.

<seanb> DO we know what the costs of making the "wrong" decision are at this point??

Antoine: i can't make a strong argument

cred: the binary relation seems a little simpler

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

Tom: i feel like i don't really understand the issue of identity of literals

Ralph: i think that's a red herring, in each case we have an instance of a label

aliman: in n-ary literal xl label doesn't occur at all

Ralph: i think n-ary literals is a bad idea

<ses> literals can't be subjects

JonP: has no preference, but is deeply suspicious of n-ary relations between literals (Tom and Ralph)

Tom: there are communities who want to associate annotations with lexical label relations

aliman: i'm not saying i prefer one over the other, they all have unexplored consequences

<ses> the subject, which is an RDF URI reference or a blank node

<ses> (from RDF Concepts)

GuusSchreiber: i think Ralph's point is that this is potentially dangerous territory

<seanb> If they all "have unexplored consequences", this seems dangerous to make any choice.

TomB: the question is to have two variants or one
... 1) whether to adopt XL approach
... 2) how many variants
... 3) is it in scope for the reference or a note

GuusSchreiber: we could be in a non-normative section of the reference

aliman: we just need to make it clear that XL is optional

<seanb> +1 for alistair's comment

<ses> There's always room for an XXL

<cgi-irc> we have to think about the actual namespace name

<cgi-irc> and we have to think of the actual vocabulary in that namespace

<cgi-irc> the label relations stay the same

<seanb> Can't make that kind of restriction in OWL 1 (card on annotation)

Alistair: rdfs:label is a built-in; what are the consequences of adding a [local] cardinality constraint on a built-in?

Guus: good point
... in the current OWL-DL, yes, Alistair is right; you can't make this sort of restriction

Sean: yeah, agree -- can't do it
... unclear whether OWL 2 will relax this
... it may be possible but I wouldn't want to rely on it for SKOS-XL
... there's a notion of annotation spaces in OWL 2
... the idea is to define or provide semantics for reasoning within the annotation space

<ses> Are Skos labels not really annotations then?

Sean: it will be richer than the annotations in OWL 1

<ses> They're the first class objects for a controlled vocab language.

<ses> In many ways, they are the resource

Guus: can postpone the decision [on xl:literalForm vs rdfs:label]

<aliman> 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

ACTION: Sean to write a proposal to indicate to OWL WG our requirements for annotation properties [recorded in http://www.w3.org/2008/05/06-swd-minutes.html#action07]

PROPOSED: to accept sections 3, 4,6 of the 14 April -XL proposal and the vocabulary defined there
... 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

no objections

RESOLUTION: 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

ACTION: Guus and Alistair write text for Reference indicating understanding of a possible need for future patterns for n-Ary label relations [recorded in http://www.w3.org/2008/05/06-swd-minutes.html#action08]

PROPOSED: Include label relations in SKOS Reference as OPTIONAL and NORMATIVE
... Include XL sections 3, 4, 6 in SKOS Reference as OPTIONAL and NORMATIVE

RESOLUTION: Include XL sections 3, 4, 6 in SKOS Reference as OPTIONAL and NORMATIVE

PROPOSE: http://www.w3.org/2008/05/skos-xl# as XL namespace

RESOLUTION: Use http://www.w3.org/2008/05/skos-xl# as XL namespace URI

Tom: note 2 advantages:
... 1 resuse of prefLabel, etc.
... 2 explicitly OPTIONAL
... 3 makes it easy to spot a document instance that uses XL

<ses> The librarian of congress just brought in a magnum of bolly

<ses> in my mind

<GuusSchrei> [continued discussion on mapping relations]

SKOS Mapping

-> SKOS Mapping Issues

related to issues 71, 73, 74, and 75

Antoine: usage scenario A concerns semantic relationships between concepts in a scheme; standard stuff
... scenario B concerns mapping between different schemes with related concept
... we propose using mapping properties from the current proposal
... (exactMatch, relatedMatch, broadMatch)
... two new scenarios; (C) shows a new scheme that reuses concepts from another scheme
... a variant of this scenario builds an umbrella scheme using concepts from two other schemes

Alistair: these are really the same pattern; the idea is to be able to reuse a schema that someone else has created

Antoine: next scenario is defining relationships between two existing schemes
... how to represent new relationships for your application
... relations not necessarily approved by the scheme owners, or relations that are speculative
... there was an initial assumption that relationships between schemes were all mapping relations whereas relations within a single scheme were not

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

<ses> Old reason to distinguish was broader was hierarchical, but broad match might have errors

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

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
... but if the application does want to differentiate it can recall where the triples came from and use that provenance

Guus: the primary scenario for me is mapping between two existing schemes

Alistair: call these two scenarios "KOS Description", "KOS Mapping", "KOS Extension", and "KOS Enrichment"
... for KOS Description, consider linking LCSH to the Semantic Web
... I can offer a new concept scheme that includes LCSH

Guus: this scenario occurs often
... 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.
... when we do this we want to define relations between the TGN concepts and our new local location
... it happens a lot that organizations want their own local extensions

Alistair: we're calling this KOS Extension
... different from KOS Enrichment

Antoine: in some cases the relationships are about the meaning of the concepts; these are inherent to the concepts
... KOS Description and KOS Extension are these
... in other scenarios the new relationships are not inherent

Simon: this is the difference between hierarchical and associative relationshiops

Alistair: the decision points I see are in scenario A, we use broader/narrower but want to identify the mapping cases
... in scenario C we want applications to be able to treat the result as one big concept scheme
... the controversy is over scenario D where the question is whether or not to rely on graph provenance

Antoine: perhaps we can define some meaning to distinguish the mapping relationship from the semantic relationship
... alternatively we could rely on a syntactic distinction; mapping is always between two schemes and require that extension always include the original scheme

Guus: but this would take us into discussing the meaning of imports

Alistair: so extension would use the semantic relation properties

Guus: what happens when a concept belongs to multiple schemes?

Alistair: you have to explicitly state when a concept is in your scheme

Antoine: and I do KOS Extension with mapping, though from a technical perspective we could go with the provenance solution

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?
... 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?

Alistair: I think that is Antoine's point of view
... the goal is to allow SKOS browsers to easily display a single concept scheme for scenario A
... in scenario B you want the browser to display 2 schemes with relationships between them
... in scenarios C and D you also want the browser to display a single scheme
... so for A, C, D you can use broader/narrower/related but in B you want broaderMatch/narrowerMatch/relatedMatch
... i.e. use the vocabulary to indicate what's special about B. KOS Mapping

Tom: the difference between scenarios (e.g. C and D) are hazy and might even morph over time

Alistair: but an application doesn't really need to know the difference between C and D, or between A and C
... B. KOS Mapping is the only case where the application really needs to be able to tell the difference
... the easiest way to do this is to provide more properites

Guus: we do a lot of these thesaurus alignments
... consider Wordnet's notion of Artist and the AT Artist
... Wordnet:Artist has a much broader natural language meaning than AAT:Artist
... I want to express this relationship; why couldn't I use broader vs. broaderMatch?
... my first intuition is that skos:broader is OK, it just has a different provenance
... but is there a good semantic reason for distinguishing?

Alistair: if you're doing ontology mapping you assert links and the application knows that it's loading data from 3 places
... you don't need special properties because you know the 3 data sources

Antoine: but these mapping applications often have their own formats for storing the mapping data

Alistair: most OWL applications work because they really know where the data is coming from
... to what extent do we think SKOS applications need to be able to handle data with unknown provenance?
... suppose Guus links two concepts with skos:broader and publishes his relation in the Web
... then a SKOS browser comes across Guus' published data and starts to use the data

Ralph: but this is a general issue for all SemWeb tools -- how to decide whether to "use" any triple it happens to find

Antoine: so do we have a case that warrants a special solution?
... in my experience, the mapping folk are happy to use skos:broader/skos:narrower and don't need special mapping properties

Guus: I have a paper from @@ that does use mapping relations
... for me, case B KOS Mapping is the important case because we do have users of it
... we have to decide whether provenance is sufficient
... we have users for scenario B and not for C and D

Jon: in my metadata registry I instantiate a narrower relation whenever anyone asserts a broader relation, independently of provenance
... however we don't do this for the broadMatch relation
... we think it's important that users creating relationships between schemes include the schemes they're referencing
... we look at concept schemes as distinct entities
... if a user wants to extend a scheme they should include it in their own
... that keeps the provenance clean
... once a concept is included in a new scheme, they can assert anything they want about it
... note that we don't actually do this at the moment but it's the direction we're headed to solve our provenance problems
... we prefer to have a separate mapping vocabulary to allow users to assert relationships between concepts without requiring them assert additional relationships
... e.g. the inference of a narrower relation whenever a broader relation is found but not when a broadMatch relation is found

Ralph: there's a general notion of scope of a triple here
... provenance is only one example of scope

Jon: we have a notion of 'ownership'
... 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
... when someone makes assertions about Alistair's concepts, they become part of that scheme in the registry
... in the context of our registry there's no separation of the sources of the triples; a registry user always finds all the triples
... so we want to add provenance so that when I add a mapping it does not become part of Alistair's scheme

Ralph: but I think Jon's registry will want to distinguish provenance for any property
... consider whether Alistair asserted that he is dc:creator or forgot to do so

<ses> http://www4.wiwiss.fu-berlin.de/bizer/SWTSGuide/

Ralph: and what if Alistair wants to assert broadMatch on a concept within his scheme?

Guus: I'm wondering if this whole issue has more to do with provenance

Antoine: but it really does have some semantics within the graph

Alistair: one line of thought is that this really is just about provenance and that's nice because it makes the model simple
... to make a separate set of properties leads to combinatorial explosion
... but if you talk to KOS people who do mapping they do think they're doing something fundamentally different (with broadMatch vs. broader)

Tom: when did broadMatch get added to SKOS?

Alistair: very early on in SWAD-Europe
... but we didn't have a lot discussion of the differences between the two sets of vocabulary
... broaderMatch was a convenient hook for applications that didn't need to look too deeply into provenance
... if we drop broaderMatch then I think we'd have to invent something else like a MappingGraph Class
... or a skos:MappingScheme

Tom: so conventions of etiquette
... the evolution of SKOS did lead to a distinction between mapping and concept scheme definition
... if we make clear that the difference is rooted in cultural concepts of what is a mapping vs. definition of a concept scheme

Guus: so we may have sufficient motivation for a separate set of mapping properties
... but then we have to define the semantic relationship between the properties

Antoine: there is no relationship
... one can't imply the other

Guus: consider AAT:Artist and Wordnet:Artist
... wn:Artist skos:broader wn:Person.
... aat:Artist skos:broadMatch wn:Artist.
... I would like to be able to derive aat:Artist ?p? wn:Person.

Antoine: but what exactly is the relation ?p? -- it could be skos:broadMatch

Guus: probably the relation is skos:broaderTransitive
... the scheme alignment is nice to have only if it's useful for query
... so I don't see the point of the mapping if we don't define the relationship between broadMatch and broader
... if not having such a relationship is the cost of having a cultural convention then we haven't accomplished much

Alistair: broadMatch could be a subProperty of broaderTransitive
... there are four options: 1. say nothing
... 2. broadMatch subPropertyOf broader
... 3. broadMatch subPropertyOf broaderTransitive
... 4. broadMatch and broader are disjoint

Guus: ... 5. or broadMatch and broader are equivalent

Alistair: the advantage of 2 and 3 are that these reuse the data model for semantic relations
... the disadvantage is that it becomes harder to distinguish when you're mapping and when you're not

Guus: the subPropertyOf approach will never work
... because you expect broader to only work between concepts in the same scheme
... the only thing I think works is to have a common superProperty
... the cultural convention is nice etiquette but it creates lots of overhead

Antoine: to do things properly we'd also need transitive superproperty of broadMatch and so on

Alistair: if there is a common superproperty of broadMatch and broader then the extensions of broadMatch and broader are disjoint
... so you could use a checker to say that someone is saying 'nonsense'

Guus: this would be the formal translation of the cultural convention

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

Tom: so saying the extensions are disjoint is unhelpful

Guus: the consequence of dropping disjointness is that we must drop all the mapping relations except exactMatch

Clay: I've been doing some work using exactMatch
... I like the current definition but wouldn't have a problem if they were specified as disjoint

Jon: what does disjoint mean in this context?

Alistair: given a graph that has A broader B. A broadMatch B. this graph would be inconsistent with the current SKOS data model.

Jon: I don't see why this restriction is unacceptable

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 ...

Jon: the restriction is just that I can't say both

Guus: but A broadMatch B also entails that A and B are in different schemes

Alistair: given the graph A broadMatch B. A inScheme S. B inScheme S. is also inconsistent

Jon: but just saying [the extensions of] broadMatch and broader are disjoint doesn't give this constraint

Alistair: right, we'd also have to say this graph somewhere
... but it does simplify the task to start by saying broadMatch and broader are disjoint
... if we allow them to be mixed at all then we have to consider all the combinations

Guus: going back to the subProperty notion
... could permit broader without restriction but use broadMatch if you want typing
... this would be a nice cultural convention
... make no restrictions about broader within or between schemes
... but broadMatch subPropertyOf broader as a cultural convention
... however, this is also problematic

Antoine: because I can envision scenarios where you ask for all broader that are not broadMatch
... if you want a 'clean' hierarchy, you have to remove the extension of broadMatch from the extension of broader

Guus: and would still have to use the provenance of triples
... but inScheme would be sufficient
... PROPOSE: broader can be within or between schemes and broadMatch only used between schemes as a convention

Tom: if there's an evolution of two schemes merging over time into a single scheme then this restriction is problematic
... there's not a logical distinction here; it's only based on intention and cultural convention
... but the justification for the distinction is that there is apparently a community who sees a difference between mapping and scheme definition

Alistair: inScheme allows me to isolate the semantic relations for a single scheme
... but how should I handle an A broader B. triple without any inScheme triples?

Ed: I'd hope that in general a browser would want to provide the user some context about what scheme they were currently viewing
... in the case of no inScheme triples, the browser would not be able to give this semantics

Guus: we won't be able to nail down all the operational semantics
... I'm moving in the direction of the subPropertyOf approach
... this gives us a meaningful relationship between the two
... whereas common superproperty would introduce an enormous overhead for something that really is just a cultural convention
... I don't think this overhead cost would be worth it

Alistair: my concern about subproperty approach is what the application does when it encounters a broader relation without inScheme.

Guus: it's underspecified; maybe the author didn't care

Alistair: maybe the triple was inferred from broadMatch and only the inferred triples were published

Clay: I currently favor the current definition where there is no relationship between broader and broadMatch because it makes provenance clean

Alistair: there are two camps; KOS Description and KOS Mapping
... if I find just A broadMatch B then I know it came from the Mapping camp
... but if I find A broadMatch B. A broader B. do I say it came from Mapping?
... there are six cases; broadMatch only, broader only, both X with inScheme and without inScheme
... in the absence of provenance information, can I infer whether these 6 graphs came from the Description camp or the Mapping camp?

Ralph: is it really about authority to make an assertion?

Jon: yes

Guus: [cites paper] lots of examples; the issue comes down to mistaken interpretations

Alistair: refer to the graphs in MappingIssues

-> Usage from the Application Point of View

Alistair: for each of these 6 graphs, let's decide the question ?Consistent or not Consistent?
... and ask whether applications can do what they want to do
... ask whether the six choices are commensurate with saying broadMatch rdfs:subPropertyOf broader
... consider first graphs 2, 4, 6; no inScheme triples

Guus: graph 3 must be inconsistent, else broadMatch has no meaning.
... if we think graph 3 is consisent then it means that there must be no semantics for broadMatch

Tom: you could take the view that broadMatch and broader are semantically equivalent and the only difference is a cultural one
... you could arrive at graph 3 by evolution
... the only constraints are soft cultural constraints

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.

Alistair: ammend to drop "there are no semantic conditions", keep "graphs 1-6 are all consistent"
... there are no semantic conditions that make graphs 1-6 inconsistent

Ed: why the wording about cultural conventions? just because of prior use?

Antoine: making *Match be subPropertyOf the others makes the story harder to tell

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

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

Alistair: statement 2; by convention, semantic relation properties are only used to link concepts in the same scheme
... if broadMatch is subPropertyOf broader then we can't make statement 2

Guus: I'm in favor of making only statement 1

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.

Jon: I don't really like it because I think the story is easier if broadMatch is disjoint from broader

Antoine: I don't like it but I don't object

Jon: I accept it but I hate it

[laughter]

Antoine: I'm hoping that the provenance will be properly dealt with

Alistair: look for inScheme statements

Ralph: I think we do need to tell the Definition and Mapping camps that we believe these are their semantics

Tom: if we make them disjoint because of provenance that's really opening a large can of worms
... 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

Ed: I prefer to keep things as simple as possible and just keep broader and narrower
... I haven't heard persuasive arguments other than existing usage and it being a matter of provenance

Guus: we could make this a Last Call issue
... explicitly asking folk who have strong opinions to give us feedback
... for Last Call I would like explicit consensus in advance about alternatives
... otherwise we might have to produce a new Last Call draft
... the only alternative I see is to drop the mapping properties

Antoine: what about disjoint?

Guus: I don't think we'd get consensus on that

Ed: I can live with the resolution

Simon: I do not believe that this discussion affects anything

Alistair: I can live with the proposal
... from a technical point of view, I think dropping *Match is the right thing
... if we make this a Last Call option then most of the comments will be from people who want to keep it
... 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
... 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
... if there's an option to consider making the mapping properties an optional extension ...

Tom: would make sense to make it optional if there's a note that says skos:broader can be used

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 note that this vocabulary may be dropped

RESOLUTION: 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 the mapping vocabulary may be dropped

Summary of Action Items

[NEW] ACTION: alistair and sean to add a note about irreflexivity to Reference [recorded in http://www.w3.org/2008/05/06-swd-minutes.html#action05]
[NEW] ACTION: Alistair to check the old namespace wrt dereferencing [recorded in http://www.w3.org/2008/05/06-swd-minutes.html#action03]
[NEW] ACTION: antoine, ed to add content to Primer about irreflexivity [recorded in http://www.w3.org/2008/05/06-swd-minutes.html#action06]
[NEW] ACTION: Guus and Alistair write text for Reference indicating understanding of a possible need for future patterns for n-Ary label relations [recorded in http://www.w3.org/2008/05/06-swd-minutes.html#action08]
[NEW] ACTION: Guus and Sean propose some owl:imports text for Primer [recorded in http://www.w3.org/2008/05/06-swd-minutes.html#action01]
[NEW] ACTION: Ralph compose 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 [recorded in http://www.w3.org/2008/05/06-swd-minutes.html#action02]
[NEW] ACTION: Sean and Alistair to send a file for the namespace [recorded in http://www.w3.org/2008/05/06-swd-minutes.html#action04]
[NEW] ACTION: Sean to write a proposal to indicate to OWL WG our requirements for annotation properties [recorded in http://www.w3.org/2008/05/06-swd-minutes.html#action07]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.133 (CVS log)
$Date: 2008/05/07 19:06:47 $