See also: IRC log, previous 2008-04-29, day 2 minutes
Guus: charter extension has been approved
RESOLVED: to accept minutes of 29 April telecon
Guus: schedule should go as on the agenda
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
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.
Alistair: dates back from the beginning of SKOS
<aliman> Evolving list of priorities
Simon: has anyone implemented it?
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
Guus: it belongs to the top of the list
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
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...
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
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
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
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
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
<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
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]
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
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]
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