SWD Amsterdam F2F -- 9 Oct 2007

<berrueta> scribe: diego

<berrueta> scribenick: berrueta

[resuming discussion on Labelling Properties, subtopic H]

aliman: for disjointness (subtopic G), I propose to describe semantics using normative prose, also for subtopic H
... we can describe the syntax constraint but make it informative

<RalphS> I agree with Sean that if we're going to state constraints, they should apply to graphs that can result from merges and application of owl:sameAs and not just to what might appear in a single Web document

TomB: we are implicitly talking about two different applications: a model checker and a syntax checker
... we need to clarify what the role of each application is

Antoine: it can be the same application with two different modes

aliman: to find all insconsistencies, the application must check the semantics and then the syntax

sean: we can only take into account owl:sameAs in the semantic check

<RalphS> Alistair: I was looking for a lightweight, simple-to-implement checker by only looking at syntax but the bottom-line is that the semantics is what matters

guus: this document should be not just "SKOS semantics"

aliman: for every feature, they may be some syntax conditions and some semantic constraints

<RalphS> I think it's crazy for a SemWeb spec to consider it proper to ignore inconsistencies that can result from reading triples from more than one document

TomB: are they constraints in the vocabulary or in the use of the vocabulary?
... a basic template to describe each issue (subtopic) there are syntactic conditions and syntax conditions on the use of the vocabulary

<RalphS> Alistair: semantic conditions are on the interpretation of the vocabulary and syntax constraints are on the use of the vocabulary

aliman: syntax constraints constrain the use of the vocabulary in RDF graphs
... include a syntax constraint for disjointness (subtopic H)?
... in the semantic we said "the property extensions of pref, lat and hidden are pairwise disjoint " (subtopic G)

sean: it seems to me similar to validation in OWL-DL

<RalphS> I believe the term "syntax constraint" will be confusing and we should find another term

guus: concerned about introducing two different definitions for the same thing

<seanb> suggestion is to use "graph constraints" rather than syntax constraints

<RalphS> "graph constraint" is better, yes

RESOLUTION: all graph constraints should be moved into an informative section

aliman: the previous statement about pref, alt and hidden ... objects is now moved into an informative section

sean: agree with guus, we should not call this document "skos semantics", this might upset some people

RalphS: what's the motivation to make these appendix informative instead of normative?

aliman: due to redundancy in some cases, the graph constraints are weaker
... if both are normative, it is really confusing. Which one to implement?
... if they're informative, if you want to implement a checked, you just implement the semantic conditions and you catch most of the inconsistencies

RalphS: so the motivation is to make it easier to write a checker

guus: in OWL-DL, there is a separed part

aliman: move on into subtopic I
... this cannot be expressed using triples, so how do we state it?
... is it enough to use some prose to state this?
... "there cannot be more than one preferred lexical label per "language" for any give resource"

<RalphS> If the motivation for making some constraints informative is to make it easier to write a conforming model checker then I think that motivation is mis-placed. Our spec should make it clear to vocabulary authors what is expected rather than weakening the expectations in order to make it simpler to implement a tool that might search the Web for errors.

RESOLUTION: (for subtopic I): "there cannot be more than one preferred lexical label per "language" for any give resource"

move on into subtopic J

<RalphS> MUST not rather than cannot?

sean: I don't belive our motivation here is to make it easier for validator implementors

guus: for each feature: the prose, and example, and in the appendix, describe the syntax constraints

<RalphS> ah, thanks Sean; so the motivation for an informative appendix is to make our spec authorship task simpler; in the case of inconsistencies in our _spec_ the prose is meant to be correct and the appendix might not be complete

guus: not using two definitions in the same paragraph

<Antoine> http://www.w3.org/TR/owl-ref/#app-DLinRDF

aliman: subtopic K
... if the range is plain literals, then they're OWL datatype properties
... any objection?

guus: in OWL-Full, data property is a subprop of object property

aliman: is it redundant to say the a owl:datatypeProperty is also an rdf:Property?

guus: if we use OWL, we might want to split the schemas

aliman: happy to say they are rdf:Properties and owl:datatypeProperties

<RalphS> [regarding the previous resolution, we need a definition for "cannot". I could not hear the resolution being proposed and do not support it as written. Clearly an author _can_ write a graph that violates SKOS constraints. If we said "MUST NOT be more than one preferred lexical label ..." or "a graph violates SKOS semantics if it contains more than one preferred label", it would be clear]

resolution for subtopic J is implicit in the previous for resolution

RESOLUTION (subtopic K): labelling properties are rdf:Properties and owl:DatatypeProperties

ralph: "cannot" does not have a clear meaning (in resolution of subtopic I)

aliman: "must" and "should" do not have meaning yet
... you may say "prefLabel MUST be interpreted in a way that..."
... but you cannot say "it MUST NOT be"

<RalphS> Alistair is trying to tell a tool how to interpret a graph rather than telling authors how to write a graph

aliman: it only makes sense if you say "prefLabel MUST be interpreted in a way that..."

guus: let's wait for the written text

[showing OWL reference in the screen, appendix E]

guus: see how the restrictions are written in that document

<RalphS> Appendix E. Rules of Thumb for OWL DL ontologies

<RalphS> (is what you're looking at, I believe?)

guus: let's go to the next topic

semantic relation properties

sean: do we expect broader/narrower to be transitive?

<TomB> [moved microphone]

sean: what's the way we expect applications to behave? or do we stick to semantics?

guus: why not transitive?

aliman: from an IR POV you might not want transitivity (the number of steps is relevant)

guus: the only alternative is to apply a pattern where we have two different properties... too complicated

aliman: my proposal is open to both possibilities

sean: if you don't say in the semantics if it is transitive or not, the applications may choose
... rdfs:subClassOf is clearly transitive
... but in this case, it is not so clear

Antoine: i discussed last week with a guy from Mondeca

sean: the semantics should be open
... if you want them to be transitive, you may introduce transitivity youself

jon: what should a checker do?

<RalphS> The spec could say something such as "The primary use case for broader/narrower is in information retrieval. For such cases, the application of OWL reasoning on transitive relations would weaken search results in many (most?) cases, therefore the SKOS specification does not demand that broader/narrower are transitive."

<RalphS> basically, I'm agreeing with Sean; if an application finds it useful to add explicit transitivity, it can do so

RESOLUTION: we make no statement about the transitivity and reflexivity of broader/narrower

aliman: we can leave reflexivity open, this not constraints about cycles

antoine: the previous resolution forbids forbidding cycles

aliman: the issue about cycles is implicit in the previous one

<RalphS> [Sean, could you type your proposed resolution into irc please?]

<TomB> [it is already there - RESOLVED plus s/substitution...]

<RalphS> [ok, so Guus was just asking for a repeat -- thanks]

<seanb> Proposed: We make no statement about the transitivity or reflexivity of broader/narrower.

guus: i would be in favour of including an example on how to enforce these properties

<RalphS> [I'm confused about whether we're still discussing Sean's PROPOSED resolution or debating whether we've already RESOLVED it, but will let TomB as chair sort out the record]

antoine: should we propose such subproperty?

<seanb> [I believe we have resolved the issue as proposed]

<RalphS> [that's the sense I get too, Sean :) ]

sean: interaction between related and broad/narrow

aliman: there can't be any clash between broad/narrow and related
... do we want to say anything about that?
... the transitive closure of broader and related should be disjoint

<RalphS> [we've just closed ISSUE-44 with the resolution "We make no statement about ..."]

aliman: in the "minimal proposal" I put this sentence: "skos:related MUST be interpreted as disjoint with the transitive closure of skos:boader"

sean: this sentence captures what you want to say

aliman: I think the confussion is that the thesaurus standard also says that cycles are a problem

antoine: that does not appear in the use cases document

edsu: +1

RESOLUTION: skos:related MUST be interpreted as disjoint with the transitive closure of skos:broader"

aliman: in this proposal i had skos:related as owl:SymetricProperty

guus: can you think in a counterexample?

<RalphS> that (proposed?) resolution is inconsistent with the previous resolution "we make no statements about transitivity"

antoine: this might introduce noise if the cardinality of the relation is high

aliman: there is some confussion about the meaning of a symmetric property
... se the note at the bottom of the "minimal proposal"

guus: (to RalphS's comment) why?

ivan: because it talks about transitive closures

<RalphS> we can't both say "we make no statements about transitivity" and also say "interpreted ... with the transitive closure ..."

guus: these are different things, you can still do transitive closures. It's just wording
... it's good to have this as an explicit note

<seanb> [The earlier resolution should be reworded to say that it's talking about whether broader is *transitive* or not, rather than general statements about transitivity.]

we agree in keeping broader inverse of narrower

<RalphS> I believe those resolutions are best interpreted as instructions to the spec editors and in that sense the details will only matter in the final words so I'm happy waiting for the next set of editors' drafts]

tom: the current SKOS spec explicitly says broad/narrow are transitive, so this is a change

concept semantics

antoine: going through the wiki page

<TomB_> RalphS we are starting again

antoine: first problem: find a definition of skos:Concept
... some informal semantics in the SKOS spec and the SKOS guide

<Ralph> Concept Semantics

aliman: all that prose about skos:Concept interpretation is pretty open

Antoine: compare the previous skos:Concept definitions with the "class" definition in RDFS semantics and OWL Overview
... "class" in just a group of individuals
... first question: can we say that skos:Concept rdf:type rdfs:Class?
... this comes naturally, I propose to add the triple to SKOS semantics. It does not add much
... do everyone agree?
... agreed

RESOLUTION: skos:Concept is an RDFS class, skos:Concept rdf:type rdfs:Class can be added to SKOS axiomatic triples

Antoine: 2nd question: skos:Concept rdf:type owl:Class?
... I propose to add this triple, if we do so, we can even remove the first one

guus: no reason to object

RESOLUTION: skos:Concept is an OWL class, skos:Concept rdf:type owl:Class can be added to SKOS axiomatic triples

antoine: 3rd question: are there instances of owl:Class that are also instances of skos:Concept?
... this brings some ambiguity: "conceptualization" (skos:Concept) vs. "specification of conceptualization" (ontology)
... owl:Classes are linked to their set of instances (extension)
... but you cannot link the skos:Concept with the real objects in the world

guus: what's the proposal?

Antoine: there are several proposals
... see the previous (3rd) question

aliman: there are 3 options w.r.t. the disjointess of skos:Concept and owl:Class: MUST, MAY BE, MUST NOT

Antoine: the first one is skos:Concepto owl:disjointWith owl:Class

aliman: the second one it the same as not saying anything about the disjointness

<Ralph> Representing Classes As Property Values on the Semantic Web [W3C Note 5 April 2005]

guus: you can take two views of the subject (for instance, a person)
... from different abstract levels
... from a SKOS POV, everything is a concept
... it's difficult to solve this in one level

Antoine: this actually comes in the different proposals I made
... bridging OWL and SKOS modelling, several use cases from the mailing list
... some ontologies would benefit from the skos properties
... the first solution i propose is to allow instances of owl:Class to be also instances of skos:Concept (no disjointness)
... in the example, a #car is both an owl:Class and a skos:Concept and has a skos:broader and a skos:prefLabel

guus: note that skos:Concept is also an owl:Class

Antoine: there are some pros and cons
... pros: compatible with current semantics, simplicity, conciseness
... no redundancy between individuals in the OWL world and individuals in the SKOS world

ivan: i'm trying to join a SKOS vocab about musical instruments and the music ontology

danbri joins the meeting room

Antoine: drawbacks: we are implicitly in owl-full

danbri: will owl 1.1 be more permissive?

ivan: it might be

Antoine: other drawbacks: problems with re-usability, the mix may be done by different persons
... difficulties with "tangible" things: who is the dc:creator of a #car?
... moving into solution 2: different instances bridged by a dedicated property
... on the left you have an individual in OWL, on the right you have a skos:Concept

guus: the only reason to do this is to be in OWL-DL
... people might see this as complicated because they don't have the notion of the problem of mixing OWL and SKOS

aliman: recap. the issue is disjointness of owl:Class and skos:Concept
... what patterns do we want to allow or disallow

guus: there are different worlds
... in the vocab world, we have skos:Concept rdf:type owl:Class
... in a different level of abstraction, we have instances of skos:Concept

[guus draws a diagram in the whiteboard]

guus: we are overloading owl:Class

ivan: we accepted the first triple an hour ago, is this the problem?

guus: we cannot remove that triple
... the only problem is OWL-DL conformance

<Ralph> ("first triple" is, I suppose, skos:Concept rdf:type owl:Class ?)

guus: introducing this bridge is a syntactical solution that is difficult for the user

aliman: do we allow people to mix levels? yes, if the want to
... there will be people that may want to keep things separated
... the bridge property allows that

guus: but at the cost of making SKOS more complicated
... this is related with metamodelling in OWL-DL/Full
... if you want to do metamodelling in OWL-DL, you have to coin two different URIs for the same thing

danbri: the value of bridging is not about classes, but instances

ivan: are you suggesting to use owl:sameAs to bridge?

danbri: no

guus: is the description of Henry VIII in the thesaurus different from Henry VIII, the person?
... with sameAs, every characteristic of one node is also a char. of the other one

sean: the concept represents the object, but is not the object (consider dc:creator)

aliman: we are proposing a pattern on how to do this, if you want ot
... we are not discussing the introduction of new properties, but the semantics of skos:Concept, in particular its disjointness with owl:Class

guus: skos:Concept is the class of the things that exist in the vocabulary, that's the minimal

aliman: we will not say anything about the disjointness

sean: we should make clear that the omission is explicit

RESOLUTION: We make no statement either way about whether skos:Concept is disjoint or not disjoint with owl:Class

Antoine: the wiki page describes more patterns and variants

label relationships

guus: this appears in several use cases
... for example, a concept has two labels and you want to express that one is an acronym of the other
... we have three options
... the last one (remove range restriction) is now invalid

<Ralph> [I hope someone will take photos of the whiteboard diagram that was used in the previous discussion]

guus: let's try to find consensus in one of the other two

<Ralph> [I believe the record adequately shows this meeting has consensus on skos:Concept rdf:type owl:CLass ]

[aliman describes his proposal in the board]

<Ralph> Capturing relationships between labels

<Ralph> ? that proposal ?

<ivan> Ralph, yes

guus: you can specialize the properties to refine the relationship (for instance: acronym)

aliman: see the next example. It uses fullForm, acronymForm

<Ralph> (that's really background; is Alistair focussing on his "minimal" proposal or his "label annotation" proposal?)

aliman: we are trying to workaround the restriction that forbids to use a literal as a subject in RDF
... this pattern allows relationships of any arity

guus: i find it difficult to sell to users, due to bnodes and subproperties
... many people want to avoid bnodes

danbri: you don't have to use bnodes, you can give them URIs

sean: this is just a tool issue

ivan: the reality today is that users type RDF

aliman: this pattern looks good in RDF/XML
... you want the label relationship to be linked to a concept, so you know which concept it refers to

guus: let's discuss the other proposal to compare them

<Antoine> http://www.w3.org/2006/07/SWD/wiki/SkosDesign/RelationshipsBetweenLabels/ProposalThree

guus: this introduces a separated set of properties which end in -R
... and a new skos:Label class
... the main drawback is that you have two different ways to express a prefLabel

aliman: this proposal is not one proposal, but two different ones
... there are two variants

<ivan> http://isegserv.itd.rl.ac.uk/public/skos/2007/10/f2f/label-relations.html

<ivan> (Alistair's comparison of the two)

aliman: there are four options indeed, but two of them are ruled out
... can an instance of skos:Label have more that one plain literal value?
... can two different instances of skos:Label have the same plain literal value?
... how to tell the story? how is skos:Label different from the literal value?
... there are four options for the relationship between skos:Label and RDF literals: many2many, many2one, one2many and one2one
... many2one and one2one are the ones we have to choose from
... in one2one, we have some interesting inferences
... in many2one you have to tell the story of what skos:Label is

guus: in the first proposal we don't have a URI for the label, but in this one, we do
... by introducing URIs to strings, we are opening a can of worms

aliman: we are not introducing URIs for strings, but for something that has a string

guus: not from the user's perspective

ivan: if you use bnodes, you have problems to express the relationship

guus: the simple fact that you have to tell a story is what makes SKOS complicated

antoine: the same string will be involved in several relationships

guus: i suggest we accept alistair's proposal

tom: raises the issue of comparision between string literals
... are "FAO"@en the same as "FAO"@en in the same graph, provided they're different nodes?

aliman: I suggest we agree in the pattern, there is no need to agree in the URIs of the properties and classes

antoine: what if we mix two concept schemes? which scheme should we attach the label relationships to?

sean: let's think in how to solve this regardless of the RDF graph, and then try to fit it into the RDF model

guus: do strings have identity? when translating wordnet, we gave a URI to literals

aliman: from a logical POV, the bijection is a good thing

guus: let's make a pragmatical resolution

danbri: I like alistair's proposal, maybe with other names

<ivan> ralph, DanBri refers to the proposal of Alistair

<Ralph> _which_ of Alistair's proposals?

tomb: willing to go along with this

<Ralph> ah, proposal 4

<Ralph> Minimal Label Relation Proposal

sean: i prefer proposal four

<seanb_> [I think "Guus's" proposal is -> http://www.w3.org/2006/07/SWD/wiki/SkosDesign/RelationshipsBetweenLabels/ProposalThree]

jon: concerned about cross-vocab relationships in proposal 4

aliman: i think the only viable option is proposal 4, but i would be happy to delay the decission

edsu: proposal 3 is more open to extension, it gives more choices

antoine: my favourite option was "remove range restriction", then Guus's simple extension

berrueta: i prefer Guus' simple extension, but i'm happy with Alistair's

ivan: i prefer Guus', but with the 1-1 version of Alistair

guus: just an observation: people nearer from the user's community prefer strings-as-resources

Antoine: in the "remove range restriction", we let users to decide if they want a resource or not

aliman: but it leaves undefined the semantics of such resources

[break for lunch]

<Ralph> [lunch/breakfast break]

<Ralph> [I don't yet have a strong preference between "Minimal Label Relation" proposal and "Simple Extension" proposal but Ed's point about greater extensibility is attractive to me]

<seanb_> scribe: seanb

<inserted> scribenick: seanb_

[Ralph: we're starting again....]

Returning to label relations

Guus: Alistair describes four options.
... Only one makes sense
... If you introduce an explicit resource, you do this to represent one label
... doesn't make sense to have 2 literal values for the same label resource
... In the web context, makes no sense to assume unique 1-1 relationship between
... label resources and literals.
... Leaves us with many-one.
... label resources have one literal. Could be multiple resources with the same label
... proposes Guus's proposal with many-one.
... whichever approach you take, contextualisation is important.
... e.g. only within this context, an acronym rel holds

<Ralph> Guus' simple extension proposal

Guus: seeLabelRelation needs to be introduced into Guus's

<Ralph> (well, that was Tom's modification of Guus' proposal)

Guus: boils down to minimally committing to Alistair's proposal. Then postpone
... decision on labels as resources.
... could canvas opinion on this.

Alistair: Adopting minimal relation solution doesn't bar us from introducing label resources in the future

Guus: would like to go for ProposolFour, but with the option of revisiting

Jon: Needs to be able to say to vocab owners
... here's a lossless way that you can bring your vocabularies into SKOS
... and relate those resources to concepts. So the work is to create the concept
... URIs.
... so less comfortable leaving this discussion
... Also think it's useful to support inference pattern
... define resource with a preflabel, then by inference the literal becomes
... the preflabel for the concept

Guus: Makes the proposals similar. Have both expressions of label relations
... New issue, label as resource?
... intrinsic value in label as resource as this is already present in a number
... of vocabularies. Makes it easier to migrate

Alistair: If you want to contextualise the relationships, need an n-ary pattern

Antoint: Could have a constraint that you have only one label resource per literal *in a vocabulary*

Alistair: Need to represent that the label resource is in the vocabulary
... containment is difficult to represent explicitly
... comment that keeps coming back "we have a term oriented view with metadata on terms"
... "Why can't I do that in SKOS?"

Guus: Boils down to accepting the minimal label relation solution
... and opening a new issue

PROPOSAL: Accept the minimal label relation solution. Details/naming to be worked out.
... Open an issue. Should there be a Label Resource in the SKOS vocabulary?

<Ralph> [I'm willing to second *any* proposal at this point so we can put a stake into this ground and move forward :) ]

Proposal one. Two abstentions: Antoine, Tom

Proposal one accepted

RESOLUTION: Accept the SKOS minimal label relation solution. Details/naming to be worked out.

Proposal two. No objections, no abstentions

<scribe> ACTION: Guus to write up the issue and add to issue list. [recorded in http://www.w3.org/2007/10/09-swd-minutes.html#action01]

Recipes

Tom: walk through issues.

<Ralph> Consolidated Recipes Issues List

Jon: Issues by number (rather than importance)
... Issue 16.
... suggests a deadline on this action
... nice Xmas present?? :-)

Diego: issue 17
... took action to write draft for recipe 6
... requirements
... 1.extended config
... 2.slash namespace
... proposed three alternatives
... first two similar. Only difference. First is script, second is servlet/program
... much easier to deploy a script than a program. Should consider the script
... option.
... in both cases, recipe includes rewrite rules.
... Third option uses HTTP redirection to a SPARQL server.
... implemented using sesame. Works fine.
... Use cases from list using similar approach
... need to choose alternatives and then write recipe
... could include more than one (e.g. 1st and 3rd), but that's two different recipes.

<Ralph> issue 17

Sean: what's the downside with lots of recipes?

Alistair: pattern here is to redirect to some service.
... details of implementation of service are secondary

Jon: primary difference between 5 and 6 is that the RDF is being served as th result of a query

Alistair: Separation of concerns. How to write server configuration and how to implement how that serving's done.

Jon: Diego is talking about (at least) a 7th recipe.

Alistair: Would be inappropriate to include instructions on implementing dynamic service for HTML
... could be done in many different ways.

[Ralph -- we've lost you?]

Ivan: can't say what "the best" configuration is

Jon: Challenge with this recipe is that earlier cases were recipes -- much more
... prescriptive. Here, it's much more open-ended.
... this is the most common

Alistair: possibly the most important

<Zakim> Ralph, you wanted to ask about "cannot" and to propose a specific example case

Ralph: propose that we implement a query service to return wordnet rdf on the w3 site
... if any WG people would like to help it would be a useful test case.
... supports Alistair's view that we not build too much implementation detail into the document

dan: surprised to hear that a SPARQL endpoint is central to scenario
... thought small vocabulary sets were the idea.
... has large vocab gone center stage?

<Ralph> I don't think SPARQL endpoint is _central_ to the point but it's now an interoperable way to illustrate the scenario

Alistair: Recipes 1 - 4 are more siuted for publishing smaller things. Notes say
... that 5 or 6 are for bigger vocabs.
... Option 3 problem. Doesn't give an impl independnet URI for the data.

<Zakim> aliman, you wanted to comment on implementation independent URLs for partial RDF data

Alistair: start off with the upper rewrite rules.

<Ralph> option 3

Alistair: then add internal rewrite rules to rewrite to SPARQL qery

<Ralph> the issue here is exposing just the "right" amount of implementation detail

<Ralph> as SPARQL is nearing end of REC track, I suggest we're on firm ground if we use SPARQL to expose just enough implementation detail to illustrate the scenario

RESOLUTION: Recipe 6 recast as an implementation pattern. Example 3 of HTTP redirect made a little more complex to show an internal query based response. Illustrative example on W3C.

<Ralph> I wouldn't use DESCRIBE as in Diego's draft, but that's easy to fix

<scribe> ACTION: Diego to recast Recipe 6 [recorded in http://www.w3.org/2007/10/09-swd-minutes.html#action02]

<Zakim> Ralph, you wanted to clarify for DanBri

<scribe> ACTION: Ralph/Diego to work on Wordnet implementation. [recorded in http://www.w3.org/2007/10/09-swd-minutes.html#action03]

<Ralph> drop action 2

<Ralph> oops, undrop action 2

<Ralph> I expect that Diego and I will work together both on the recast and the example implementation

Jon: Issue 19. Is this in scope?
... if in scope, how do we implement it?

dan: What's the server market? Apache, IIS?
... what would get us 90%?
... be wary of creating a big framework.

jon: maybe 3/4 would do it.

<Ralph> yes, pointing to a W3C Wiki for submissions would be a fine implementation

Guus: minimal effort would be preferable!
... so it's in scope, but minimal effort

Ralph: *no* effort! Put up a wiki page and let others contribute. Don't even have time

<Zakim> Ralph, you wanted to propose that we create a way for people to submit other implementations but not devote energy in the WG to produce them

Ralph: to test stuff.

Tom: Where does the wiki live? WHo controls it? Who controls access?

Ivan: public wiki page linked from document would be fine.

guus: limit to W3 members?

dan: too many people drifting around.

Ivan: positive experience of this in the past

<scribe> ACTION: Ralph to come up with a URI for wiki page [recorded in http://www.w3.org/2007/10/09-swd-minutes.html#action04]

Jon: Issue 22. IE hack/workaround

<Ralph> issue 22

Jon: will resolve issue 22 by implementing suggestion a)
... Issue 23

<Ralph> issue 23

Jon: organisations won't implement recipe due to allowoverride not being allowed
... could add discussion that recipes could be done in server configuration
... include alternative implementation in each recipe showing server config vs htaccess

Diego: If you can't use htaccess then go speak to your IT department....

<Ralph> I like "3. Point out that each of the recipes can be implemented directly in httpd.conf

<Ralph> files without enabling AllowOveride and show how to do that for at least one of them

<Ralph> "

Dan: Also hosting providers

ralph: Likes jon's compromise proposal. point out that it can be done by the server admin with an example

jon: Because recipes are in htaccess, this is used as an excuse to not implement by sys admins

<scribe> ACTION: Jon to make changes as proposed [recorded in http://www.w3.org/2007/10/09-swd-minutes.html#action05]

<Ralph> I think step 1,

<Ralph> [[

<Ralph> 1. Briefly discuss the relative performance and security disadvantages of

<Ralph> .htaccess files, or at least point to such a discussion.

<Ralph> ]]

<Ralph> is lower priority for us

Jon: Issue 24

<Ralph> fine to do it, but could also be dropped as out of scope if we chose to drop it

Jon: May be subsumed by cool URis.

-> http://www.w3.org/2006/07/SWD/track/issues/24

scribe: rationale behind redirect choices.

<Ralph> +1 to referencing SWEO Note

scribe: may be able to just reference the cool uris note.

<berrueta> +1

RESOLUTION: Issue 24 resolved by referencing Cool URIs note

Jon: Issue 30

-> http://www.w3.org/2006/07/SWD/track/issues/30

<Ralph> [I hope the SWEO Note will ultimately get a different title than "Cool URIs" :) ]

Alistair: Raised this because in the XML world, args about what you put in your
... xml namespace.
... RDDL describing the relationship between resources.
... Note quite the same as what we're doing
... Should at least have some sort of story.

ivan: wouldn't be shocked if this document wasn't referenced here.

Ralph: Propose that we defer the issue

<TomB> http://www.w3.org/2001/tag/doc/selfDescribingDocuments.html

<Ralph> issue 30 is really "what can appear at an RDF namespace URI?" and is a big topic that, given our remaining charter lifetime, we should defer

<Ralph> Associating Resources with Namespaces Draft TAG Finding 5 October 2007

Jon: Should we raise an issue about publishing vocabs using RDFa/GRDDL?
... is that within scope?

Ralph: Suggestst that this should be out of scope due to lack of experience

Tom: Michael took action to clarify scope for Cool URIs. Could that be used here?

Ralph: skeptical that we could achieve closure on testing implementations

Tom: Propose that we acknowledge their existence, but not go much further

<scribe> ACTION: Jon to add words that acknowledge the existence of RDFa as potential mechanisms, but it's out of scope here. [recorded in http://www.w3.org/2007/10/09-swd-minutes.html#action06]

Jon: Issue 58

-> http://www.w3.org/2006/07/SWD/track/issues/58

Jon: Diego has solution that fixes some of the problems.
... do we publish this (with limitations) or change all the recipes using type-maps

Alistair: if you want to do conditional redirects, need a type-map up front.
... simple solution using a single redirect, but required rdf&html in the same directory

<Ralph> Alistair's mail on type maps

Ivan: general response to this was "write a php script" and do the logic there.

Ralph: Sounds like a good contribution for the wiki page

Jon: Could also be explicit about the cases where the simple recipes fail to handle
... things. Point to recipe 6/7 as a way of solving things.
... No, that's not a good idea....

Alistair: Should talk to someone from Apache. Are conditional redirects common?

dan: Have some Apache contacts

<Ralph> I'm not confident that the example in recipe 6 will handle all content negotiation situations either; it may well end up with similar restrictions to recipes 3, 4, and 5

dan: can pass on a request

<scribe> ACTION: Dan/Alistair to ask apache about conditional redirects [recorded in http://www.w3.org/2007/10/09-swd-minutes.html#action07]

RESOLUTION: Hold until further information available

Jon: Issue 60

-> http://www.w3.org/2006/07/SWD/track/issues/60

scribe: IPTC work.

Ralph: Combination of SWEO Note + Recipes will probably address this

Ed: SWEO note talks about this

Ralph: suggests we defer on the IPTC code URI question

RESOLUTION: Issue 60 is out of scope of Recipes and is Closed.

Jon: Draft form by the end of the year.

Guus: Reviewers?

<scribe> ACTION: Guus/Tom to solicit reviewers for the Recipes document. [recorded in http://www.w3.org/2007/10/09-swd-minutes.html#action08]

Possible reviewers: 1WG + 1 SWEO + Karl Dubost?

Guus: If we think we're done, we should publish this as a Note. Need to ask this question in December

<scribe> ACTION: TF leaders to prepare a version of Recipes for review in December [recorded in http://www.w3.org/2007/10/09-swd-minutes.html#action09]

<Ralph> ("done" in the sense of "we don't currently have a plan to do more work on this")

Diego: Issue about online server testing (Issue 20)

<Ralph> (not as in "we believe this covers all the questions that could be covered")

-> http://www.w3.org/2006/07/SWD/track/issues/20

<TomB> (+1 Ralphs)

[diego demos service]

[sorry ralph -- it's running on localhost....]

Diego: would like to host this on a public server somewhere
... concerned about security though. Could be used for DoS attacks

<Ralph> Diego's pointer to his tests

Tom: is this service related to finalising the note

Jon: Only to the extent that it would be useful to be able to point to it from the note..

Ralph: valuable resource.
... similar to RDFa tests that we discussed yesterday

<Ralph> i.e. non-normative but very useful

Jon: Question. Where would you host it?
... W3C might be interested?

Diego: Can host once the security problems are fixed.

RESOLUTION: Issue 20 resolved by adding a reference to Diego's service

<Ralph> Thanks, Antoine and Guus, for hosting us

<Ralph> [I look forward to seeing the photograph of the participants]

<ivan> hey ralph, we are getting back

<Ralph> [hope the weather is nice there.]

SKOS Planning

<TomB> scribe is danbri

<TomB> guus> skos planning ... review issue list

<Ralph> scribenick: scribe

guus ... who can work on docs?

<Ralph> scribe: DanBri

scribe: aim at a wd

guus: some progress on rels between labels
... re anno on label, some work to be formulated
... basiclexicallabelsemantics ... covered this am
... contentschemecontainment to discuss now

broadernarrowersemantics and conceptsemantics ie 44 54 closed

also 31

scribe: conceptschemelabellinginteractions open
... 26 closed but we opened a related one

al: conceptschemelabellinginteractions is about rel between lex labels and concept schemes
... typically in a thes, each concept has to have a preferred lex label
... various constraints which, while perhaps not needing to go in the semantics ... we might want to tlak about how to achieve
... rulesandconformance issue
... proposed that resolve RulesAndCOnformance ie isssue 35, by noting that the SKOS semantics is explained using prose so we wont use any rule syntaxes

guus: 37 SkosSpecialization, eg. partitative

al: the actual issue here, ... how does a 3rd party create and publish extensions to skos
... we could resolve this issue by including some guidance in the doc
... we could talk about whether we want to do it ourself
... we have this skos extensions namespace
... in which there are various specialistions of broader and narrower

guus: thats another issue, re what to do with those
... conceptmappinglinks ie issue 39

al: one of the important next ones to consider

antoine: good that there have been some other contribs in this area

issue 40 Coordination / eg. side effects of asperin vs asperin

sean: its compound terms

al: you dont have to get heavily into the semantics
... if you have side effects and you have asperin

if you tag a doc with 4 things, ... how to show the groupping

qplus

sean: if i tag ...

(missed sorry)

al: if you want the interaction you can implement a query expansion
... but we dont need to say

dan: reminds me of rdf:Bag which proved unused

john: these are raised issues not open issues, whats the process

guus: first review the list quickly then rate importance

41 ... UseLangTagsInExamples

al: literals shoudl always have a lang tag
... not a real issue, more a Primer action

45: NaryLinksBetweenDescriptorsAndNonDescriptors

eg. "Use X plus Y@

(excuse my punctuation)

or "Use X OR Y"

guus: different to coordination

al: no, capturing the nondescriptor and the things it cites is different
... but related issue

46, IndexingAndNonIndexingConcepts

antoine: linked to the existance in some concept scheme ... things that can be in coordinations
... unique role is to apply as modifiers

guus: eg. iconclass

antoine: also LCSH

47, MappingProvenanceINformation

MappingProvenanceInformation 47

next...

IndexingRelationship 48

al: we need to be able to relate a res to a concept

antoine: i think we already made the requirement
... maybe we should move some of these out

guus: dont think they belong to the language

LexicalMappingLInks 49

al: implciit in this, idea of labels as part of a specific vocab
... here we are saying we might want to map lexically

guus: only possible if you have URIs for the lexical entries

CompatibilityWithDC 50

al: to make sure what we say is fitting in neatly with the dc abstract model

CompatibilityWithISO11179, important metadata std, should be considered

john: at the open forum, i presented on skos, one of the primary Qs I was asked ... re compatibility
... conf was about metadata registries
... sig portion of the audience used 11179 as their definitive spec
... people were saying "if i wanted to implement skso in concept of an 11179 registry..."
... a lot of ppl have requirement to use a formal published standard
... and they could use it if it got to REC and had mappings to other stds

al: next two are re newer thesaurus stds

COmpatibilityWithISO2788

CompatibilityWithISO...

ReferenceSemanticRElationshipSpecialiations 56

scribe: relates to other issue
...

guus: apart from open issues, looking at raised issues
... we work on WD that addresses current open issues

mapping relationships, 39

lexicalmappinglinks 49

referencesemanticrelationshipspecializations 56

guus: i suggest to take these 3
... they all are at level of "whatare the parts of a vocab"

al: also coordination needs new vocab

guus: thats thorny

al: no more than the others

ed: in 56 ... something in there for coordination?

guus: if we want to get to REC, we owe community a new WD now
... we can state issues that are open
... but we owe them a new draft
... needed within next 2 months

al: fair enough

guus: ordering, not priority

al: in this case drop 49 lexicalmappinglinks

guus: so we do 39 and 56

opening them now

ConceptualMappingLinks 39:

issue owner: antoine

admin ... guus: we are using RaisedBy for issue owner, tooling issues

(logs in to issue tracker)

referencesemanticrelationshipspecializations 56

al: as dan says, we start to tread on toes of owl

guus: i can take this one

issue owner for 56: Guus

guus: re planning
... looking at our package of docs

Use Cases ... Syntax, Semantics or Reference doc, .... and Primer.

scribe: suggest PRimer also has info on guidelines
... ie. how to do things

best to distribute work and glory :)

scribe: some prev discussions at telecon
... Ed asked if he could contrib to a PRimer

ed: yeah, definitely
... i would like to work with someone, as not written such a doc before
... sounds like Alistair and I could ...

guus: for primer i was thinking there should be another lead
... I assume Al will take major lead with reference docs
... so better if someone else takes major lead with Primer

al: I can live with that, sure .... I will try to contrib to primer but happy to have someone else
... on primer

guus: so who else re primer

antoine: i am willing to help

guus: if you can make it fit your work description within Stitch (acronym) it could work in your job in Ams
... with a number of other contribs
... so who can share this work
... and names of the docs

al: Re name "Reference" I was thinking to make quick reference

general waryness of Syntax and Semantics

al: Reference or Reference Manual

Reference.

ed: Whats the status of the Core GUide

al: most of Core Guide I would move to Primer

guus: needs to be a systematic

who else helps re Reference_

Sean. Dan (helper only, esp re OWL bridge)

guus: Use Cases doc is now finished. Antoine and Daniel and John were editors.
... if he has time for this WG, Daniel Ruben from Stanford might have time here for Reference or PRimer
... for Reference, I expect minimally that doc to be rectrack
... i view it as a new publication
... with clear links to the original sources where it came from
... as soon as possible
... realistic timeline?
... 1st a draft, non editors. ...

al: 2 months for an editors draft
... could try for faster

6 weeks?

<scribe_> ... worth having a big attack at 1st edit pass

<scribe_> al: would 6 weeks be enough?

<scribe_> guus: proposal is 6 weeks to editors draft

<scribe_> Sean: ISWC happens in those weeks

<scribe_> danbri: who will be there? al, not, sean yes.

<scribe_> ...also KnowledgeWeb review gets in the way

<scribe_> guus: rest of oct, beginning of Nov, to get something out

<scribe_> guus: if we do a 1st WD ... we need to start resolving some other issues

<scribe_> ... if by end of our charter we have agreed on a Last Call draft, thats a good schedule

al: we need ... 1st public WD, ...

guus: if we need a 2nd, we do a 2nd
... moment you are done you do a Last Call WD

4 to 6 weeks for review from the world

process for react to comments

then the group decides where next

handle objections if they happen

guus: during comment period, if errors in design emerge, can do a new LC
... if happy with LC handling, can request Candidate Recommendation stage
... need 2 impls of each feature in the lang

ivan: what does this mean re skos

guus: have vocab checkers that implement the semantics

danbri: if thats the case, DTD checkers would be enough to get any xml spec thru CR

ivan: its up to the WG
... if it was only a vocab in sense of foaf etc, strictly speaking it doesn-t need any implementation in sense of software

sean: there are all these conditions ... not just syntactic
... to check it is being used properly

ivan: question in case of skos, is do we need it?

guus: minimal woould be better

ralph: i tihnk we need to show people are using skos

re full module checker, ... we might not want to make that a CR criteria

scribe: we will want to show there are interoperable implementations

ralph: eg 2 or more websites that publish skos docs, 2 or more tools that do sometihng useful

guus: ralph, you tihnk a vocab checker is not necessary
... the wg can decide that
... a model checker that tests the informal constraints in our appendix sets the bar quite high

sean: always inclear to me what a skos impl is

al: my dc paper last year ... 3 classes ...
... vocab dev tool
... indexing app

<Zakim> Ralph, you wanted to consider implementations

which consumes a vocab in skos

scribe: and a searching app

something like swed

ivan: i am still arguing here ... thats different

in svg world, ...

implementations eg. the plugin

the CR only requires implementations in the case of SVG

it doesnt require showing use

<Ralph> DanBri: the spirit of W3C specifications is that something doesn't make it to Recommendation unless it shows that it is useful [to some community]

<aliman> danbri: class of languages to define languages, dtds, xml schema, skos is yet another language. pushing skos out without proving how it's useful, bad idea. need to show how the world is made better. need to show people are producing, and people are consuming it. E.g. two major thesauri available for use using current SKOS spec (don't need full model check). Another thing, skos with non-thesaurus RDF, so show how SKOS mixes with other stuff. Tell the story, then

thx al

<Ralph> +1 to DanBri

john: i have an app ...
... that uses skos, i dont know if it counts as an "implementation"
... but i plan to allow import into the app of skosbased ontologies
... so i need import validity checker
... intend to set it up as a checker

webservice

scribe: will do in next 4 or 5 months

ralph: johns interesting point ... that any time you find a piece of spec that you dont know how to interpret
... try to write a test case
... if we use test cases to record resolutiosn that we have made
... and to document things that the implementors believe to be true about the spec
... i dont think we want to go so far as to write a huge test suite that tests EVERYTHING

<Zakim> Ralph, you wanted to make a suggestion to Jon

john: we have a test cases doc in our deliverables

guus: am hearing consensus that this isnt required
... we dont really have the people to run that bit, except sean
... during LC ... we can prepare implementation report doc

if we can manage to be readywith LC around april, we will only need a few months extension

guus: ... id be v uncomfortable publishing some of these issues near LC

and we cant do everything now

so i would expect at least two WDs to be done close to LC

ivan: at some point close the WG and discuss in the CG how to finsih them
... we would need to make a case to extend

danbri: why not just ask now? for extension

ivan: other non skos things
... when we go to an extension, we have to say exactly what it is for
... if only skos, thats a clear arg

guus: important thing is that this WG ... if we make that schedule, LC in April ... May and June will still be busy periods, bringing doc thru CR
... rest of work is mostly for the chairs
... for your planning, you can expect this work to die down around summer next year

timecheck: 5.05pm

ConceptSchemeContainment next

(back in 10 minss)

resumed

Module: Concept Schemes

al: so the use case i had in my mind was ...
... eg i receive some rdf data
... in that data, two diff thesauri schemes are defined
... want to be able to show someone there are two schemes, and show them which is which
... thats the use case
... minimal way
... tried to be consistent with rdfs isDefinedBy
... implicitly depracates skos:inScheme

semantics are just that skos ConceptScheme is a class

(pls someone post the link, wont transcribe detail)

danbri: clever proposal, 2nded

<Ralph> are we looking at -> http://www.w3.org/2006/07/SWD/track/issues/36 ConceptSchemeContainment ?

al: couple of "may" statements

<edsu> http://www.w3.org/2006/07/SWD/wiki/SkosDesign/ConceptSchemes/MinimalProposal

ralph, MinimalProposal

thx

al: can use sparql to ask if this semantic ... in this graph

guus: re wordnet eg, considered using owl imports

al: parag here says we could have conceptscheme as owl ontology
... .diff may as the one re named graphs and conceptscheme

(discussion of what comes as std in sparql vs out of band server controls)

guus: i like the proposal
... nice use of isDefinedBy

al: if you do think of conceptschemes as named graphs
... you dont ever need to use the isDefinedBy

danbri: you could generate them explicitly using SPARQL CONSTRUCT tooling

guus: this uses our base level mechanisms, ie rdf, rdfs etc, to the max
... and we only do extras when needed

al: with inScheme, was no notion of cardinality
... with isDefinedBy, implicitly saying aconcept is only defined by one concept scheme

<Ralph> I'm pretty certain that isDefinedBy is not an owl:functionalProperty

<Ralph> rdf:isDefinedBy (a "utility property")

<scribe_> al: the rdfs spec says "isDefinedBy may be used to indicate an rdf vocab in which a resource is described"

<scribe_> guus: if we get comments that they would like another term ... we could have same notion in skos or a subprop but for moment i see no real need

john: inScheme allowed a concept to be related to multiple schemes
... but isDefinedBy is ok that way too

al: personally i would like to explore us being a bit stricter

<Ralph> (that is, I'm pretty sure that no W3C spec says rdfs:isDefinedBy is an owl:FunctionalProperty but I think that this would be consistent with intent]

(what ralph said ... i think i didn-t argue hard enough for functioanl within rdfcore)

guus: am happy to define inscheme as subprop of isdefinedby, and recommend latter

antoine: q re issue this morning for mixing owl and skos

proposal: to close issue Concept Schemes

guus summarising

<aliman> http://www.w3.org/2006/07/SWD/wiki/SkosDesign/ConceptSchemes/MinimalProposal?action=recall&rev=1

guus: until now, proposal meeting with moderate enthusiasm
... keep inScheme for historical reasons
... define as subprop of isDefinedBy from rdfs
... with some practice for how to use it in skos context
... antoine asks how to handle hasTopConcept
... i-m happy computing it

danbri: only if you have a complete description
... is it used?

al: yup

guus: keep it
... proposal is to accept the proposal from alistair as a resolution for closing issue 36
... with two remarks

1. for historical reasons, inscheme is kept as a subprop of isDefinedBy

2. we dont touch hasTopConcept

<Ralph> skos:inScheme

al: are we explicitly depracating skos:inScheme

danbri: precedents for deprecation?

al: in prev WG we useed OWLs classes for these

danbri: i suggest doing likewise here

<aliman> http://www.w3.org/2006/07/SWD/wiki/SkosDesign/ConceptSchemes/MinimalProposal?action=recall&rev=1

guus: formalities
... no objections, abstentions
... resolved by consensus

we agree 3. that deprecating skos:inScheme (using approporiate owl vocab) is part of the accepted proposal

RESOLUTION: skos:inScheme is deprecated

thanks ralph!

ADJOURNED!

<Zakim> scribe, you wanted to ask re testAMONIALS and to ask re DL

<Zakim> Ralph, you wanted to thank the hosts

<Ralph> did Guus just say "no meeting next Tuesday"?

<danbri> thanks Ralph for 10 years of RDF work!

<Ralph> [/me pulls more grey hair :) ]

<edsu> Ralph: yes

<Ralph> Guus: next meeting 23 October

<Ralph> [now really adjourned]

SWD Amsterdam F2F

9 Oct 2007

Attendees

Contents

semantic relation properties

concept semantics

label relationships

Recipes

SKOS Planning

Summary of Action Items