See also: IRC log
<berrueta> scribe: diego
<berrueta> scribenick: berrueta
<inserted> day 1 minutes
<inserted> day 1 minutes
[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
... 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
... 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
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> (is what you're looking at, I believe?)
guus: let's go to the next topic
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
... 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
... 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
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
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?
RESOLUTION: skos:Concept is an RDFS class, skos:Concept rdf:type rdfs:Class can be added to SKOS axiomatic triples
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
... 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
... 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
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
... 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
... 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
... 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
... 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?
guus: is the description of Henry
VIII in the thesaurus different from Henry VIII, the
... 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
guus: this appears in several use
... 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> ? 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
... 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
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> (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
... 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
... 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
... 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]
Tom: walk through issues.
<Ralph> Consolidated Recipes Issues List
Jon: Issues by number (rather
... Issue 16.
... suggests a deadline on this action
... nice Xmas present?? :-)
Diego: issue 17
... took action to write draft for recipe 6
... 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
... 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
... 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
... if in scope, how do we implement it?
dan: What's the server market?
... 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
... 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
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> 1. Briefly discuss the relative performance and security disadvantages of
<Ralph> .htaccess files, or at least point to such a discussion.
<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.
scribe: rationale behind redirect choices.
<Ralph> +1 to referencing SWEO Note
scribe: may be able to just reference the cool uris note.
RESOLUTION: Issue 24 resolved by referencing Cool URIs note
Jon: Issue 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
<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
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
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.
<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")
<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
... 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.]
<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
... re anno on label, some work to be formulated
... basiclexicallabelsemantics ... covered this am
... contentschemecontainment to discuss now
broadernarrowersemantics and conceptsemantics ie 44 54 closed
... 26 closed but we opened a related one
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
... 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
sean: if i tag ...
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
... not a real issue, more a Primer action
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
antoine: linked to the existance
in some concept scheme ... things that can be in
... unique role is to apply as modifiers
guus: eg. iconclass
antoine: also LCSH
al: we need to be able to relate a res to a concept
antoine: i think we already made
... maybe we should move some of these out
guus: dont think they belong to the language
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
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
... 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
scribe: relates to other
guus: apart from open issues,
looking at raised issues
... we work on WD that addresses current open issues
mapping relationships, 39
guus: i suggest to take these
... 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
issue owner: antoine
admin ... guus: we are using RaisedBy for issue owner, tooling issues
(logs in to issue tracker)
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
... 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
... 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
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
... could try for faster
<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
... 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
... 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
<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
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
(back in 10 minss)
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
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
... with isDefinedBy, implicitly saying aconcept is only defined by one concept scheme
<Ralph> I'm pretty certain that isDefinedBy is not an owl:functionalProperty
<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: 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
... is it used?
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
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
... 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
<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]
$Log: 09-swd-minutes.html,v $ Revision 1.12 2007/11/06 15:43:26 swick fix validity bug introduced in changelog Revision 1.11 2007/11/06 15:42:22 swick Per ACTION Ralph of 30 October telecon   http://www.w3.org/2007/10/30-swd-minutes.html#action01 . Remove DRAFT heading. . Add resolution: skos:Concept is an RDF class . Add resolution: skos:Concept is an OWL class . Add resolution: We make no statement either way about whether skos:Concept is disjoint or not disjoint with owl:Class . Add resolution: Accept the SKOS minimal label relation solution . Add resolution: skos:inScheme is deprecated . delete scribe.per diagnosticsMinutes formatted by David Booth's scribe.perl version 1.128 (CVS log)