W3C

- DRAFT -

SWD F2F Day 2

07 May 2008

Agenda

See also: IRC log, day 1 minutes

Attendees

Present
Sean Bechhofer, Guus Schreiber, Alistair Miles, Clay Redding, Antoine Isaac, Tom Baker, Ralph Swick, Ed Summers, Diego Berrueta, Jon Phipps
Regrets
Quentin Ruel, Vit Novacek, Margherita Sini
Chair
Guus, Tom
Scribe
Clay, Antoine, Alistair, Ed

Contents


 

 

<RalphS> Day 1 record

<RalphS> conference room photos

<RalphS> flipchart images

Notations

Guus: is notation the standard terminology?
... do we need explicit vocabulary for expressing relations?

Alistair: yes

Guus: question to Sean, about user-defined datatypes in OWL 1
... you couldn't define URI and that what best practice was about
... alternative was whether to use/misuse language tag

Guus: is it common to use artificial language codes in this way?

Clay: ISO639-2 has ZXX code meaning "no linguistic content"

<edsu> here's Jakob's paper: http://aps.arxiv.org/abs/0801.3908

Guus: problem indicating if the notation using language

aliman: rfc 4646 private label "x-notation" is what Jakob proposed

<RalphS> Jakob's proposal

<RalphS> RFC 4646 Tags for Identifying Languages

-> iso639/part2/alb.xml Clay's example

(view source and look at @xml:lang attrs

Guus: if "x-" is reserved for private use and tools expect this then it might be okay

<RalphS> See section 2.2.7 Private Use Subtags

Guus: that satisfies all my concerns, b/c one can use "x-iconclass", etc.

Alistair:> see Section 4.5. Considerations for Private Use Subtags
... may disallow this proposed use

Antoine: it's more for displaying this information

<RalphS> ... "[Private use subtags[ SHOULD NOT be used where alternatives exist and SHOULD NOT be used in content or protocols intended for general use."

Guus: write it up and see if anyone has a problem with it.

aliman: explains the exposure of notations

ralph: this could be a URI

<RalphS> <lexicalLabelSet>

<RalphS> <preferredLabel xml:lang="x-notation">alb</preferredLabel>

<RalphS> <alternateLabel xml:lang="en-Latn">Albanian</alternateLabel>

<RalphS> <alternateLabel xml:lang="fr-Latn">albanais</alternateLabel>

<RalphS> </lexicalLabelSet>

Clay: political issue -- objections to using either the English or the Latin label as the prefLable

<RalphS> <membershipSet>

<RalphS> <conceptSchemataMembership>

<RalphS> <conceptScheme>

<RalphS> <conceptSchemeURI>info:lc/vocabulary/iso639/part2</conceptSchemeURI>

<RalphS> <isTopConcept>false</isTopConcept>

<RalphS> </conceptScheme>

<RalphS> </conceptSchemataMembership>

<RalphS> <collectionsMembership>

<RalphS> <collection>info:lc/vocabulary/iso639/part2/bibliography</collection>

<RalphS> </collectionsMembership>

<RalphS> </membershipSet>

Clay: don't beat me up about the info: URIs

Ralph: so how do we know where a give notation is coming from? can we use "x-notation-???"
... are notations always used in conjunction with lexical labels?

aliman: notion of a label is unique to skos, beforehand that was a caption and a notation

Ralph: there's no restrictions on what can go into a literal

<seanb> Are plain literals always going to be sufficient to capture the notation identifiers?

Ralph: now this is acting as a special sort of label, and with multiple classification schemes, it means this is a type of label coming from classification schemes

<seanb> Do we need additional infrastructure in SKOS in order to deal with notations, or is it sufficient to allow the applications to handle it?

Ralph: Jakob's proposal is to fold the model of "type=notation" and "system=dewey" etc into a literal in lexical labels
... what is the justification for this for putting this in labels?

aliman: this keeps us in plain SKOS without XL

Antoine: what is nice about this proposal is that we don't expect users to know where the code is coming from, such as dewey.

Ralph: do i search using a dewey code, etc.

Antoine: they serve both as labels and identifiers as well

Ralph: would it be the case that there is a skos:Concept of "History of European Civilization", and then has a notation of dewey 3xxx
... why isn't the notation part of the properties of the skos:Concept instead of being in the label

aliman: my first proposal was to have a skos:notation property with a typed literal
... there was a property called "external id"

Clay: I used skos:notation earlier and it made perfect sense to me
... it was SIL who wanted a mechanism for putting the code within the prefLabel

Tom: DCMI has a URI for "the set of 3-letter codes listed in ISO 639-3" intended to be used as a datatype

Clay: there was a need for using codes in prefLabel that were not from a natural language, for political reasons

Guus: there seems to be a need for representing a notation as a label, and that we'd like to have a notation tied to the actual skos:Concept

Ralph: there could be a duplication of data between the label and the skos:notation property

edsu: Jakob was bundling everything into the literal

Guus: suggests that we reintroduce skos:notation, and that if you want to use a notation as a prefLabel, that 'x-notation' is the preferred way to do this

aliman: the original skos:notation should coin a URI for the notation system, but didn't say what is should dereference to, and it was a typed literal

Tom: that's what OCLC does, a syntax encoding scheme

<aliman> Alistair's original proposal for skos:notation

aliman: looking up the original email re: skos:notation

<RalphS> PROPOSE: introduce skos:notation a rdf:Property whose value is a typed literal. The datatype of the literal specifies a syntax encoding scheme and the value of the literal is the classification code from that encoding scheme

Tom: showing syntax encoding scheme for dcterms:language

:book dcterms:language "alb"^^dcterm:iso639-3

Tom: we also have something for dewey

aliman: you need a uri for every dewey concept, the dewey concept scheme, and the dewey notation system

Guus: I think this works
... nice hook

Ralph: i think we could support the use of "fr-x-notation", "de-x-notation" , etc.

Guus: recommend in case there is a collison of multiple notations in different languages then we could use multiple notations
... such as "fr-x-notation" example that Ralph just suggested
... to Ralph: I don't expect tools will be able to do much with the lexical label w/the x-notation suggestion

Ralph: discussing if the notation as label matches on the notation property, and a tool could offer more functionality for learning about the classification

aliman: don't always have to use a prefLabel

Ralph: deduce prefLabel from notation?

aliman: not necessarily
... if a notation exists, a tool would render that, and labels would appear beneath

Ralph: skos:notation would be richer and could generate a label from the notation value
... one of prefLabel or notation is required

Clay: was asked if a skos:notation is used, then could it be possible to use altLabels without a prefLabel

Ralph: prefLabel is not required

Guus: this is a primer issue
... how you use it, that is

aliman: there's no requirement because of the open world assumption
... it's advisable to use a prefLabel, but not required

Ralph: i think it's fine to say some concepts won't have prefLabels

aliman: i do too

<JonP> Tom's model sketch from 15 minutes ago... http://tinyurl.com/6kahut

<RalphS> PROPOSE: introduce skos:notation a rdf:Property whose value is a typed literal. The datatype of the literal specifies a syntax encoding scheme and the value of the literal is the classification code from that encoding scheme.

<RalphS> PROPOSE: introduce skos:notation a rdf:Property whose value is a typed literal. The datatype of the literal specifies a syntax encoding scheme and the value of the literal is the classification code from that encoding scheme. As prefLabel is optional, SKOS tools may want to display notations as labels.

RESOLUTION: to introduce skos:notation a rdf:Property whose value is a typed literal. The datatype of the literal specifies a syntax encoding scheme and the value of the literal is the classification code from that encoding scheme. As prefLabel is optional, SKOS tools may want to display notations as labels.

<RalphS> issue-79

ACTION: Clay will respond to Jakob about the resolution for notations and x-notation [recorded in http://www.w3.org/2008/05/07-swd-minutes.html#action01]

Reference Semantic Relation Specialisations

Guus: this has to do with broaderTransitive, broaderPartitive, etc
... the specialization of broader

Guus: if we want to include these speicialization as subproperties of broader, it won't work.
... would prefer not to include any pre-defined specializations

Sean: only concern is that if we don't include anything we might get ad-hoc implementaitons

Guus: I suggest writing text for the primer showing what a local specialization would look like
... broaderTransitive w: subproperty of broader, etc.

<RalphS> SWAD-Europ SKOS Core specification of broaderGeneric, etc.

Guus: how many of these specializations are used in the thesaurus community

aliman: seemingly sparingly

Sean: if we do what Guus suggests (i.e., nothing), the solution with the least ramifications...

Guus: postpone issue?

Tom: is this in scope? what kind of community follow-up will there be in the w3c context, or in other communities?

<RalphS> 2005 SKOS WD deprecation of broaderGeneric

Ralph: the SW Interest Groups, incubator groups, etc. formalizing an extension could come from a report from these sorts of groups.

Tom: what happens if someone starts a SKOS discussion outside the context of W3C?

Ralph: we don't own the discussion but encourage them to work through us
... the locus of attention is not just through W3C

Tom: from August-December, should we draft something to determine what the options are regarding specialization?
... there probably should be a website with pointers to these efforts beyond the life of the core SKOS work

aliman: this community might be more comfortable with the notion of a registry

<RalphS> issue-56

PROPOSED: To postpone Reference Semantic Relation Specialisations (ISSUE-56) becuase we do not yet have sufficient information on how to embed these specializations in the current SKOS model

<RalphS> +1

RESOLUTION: To postpone Reference Semantic Relation Specialisations (ISSUE-56) becuase we do not yet have sufficient information on how to embed these specializations in the current SKOS model

Tom: names for the lineage of SKOS?

Alistair: I'm calling the SWAD-EU version "SKOS alpha"

Tom: SKOS 2005 for the SWBPD WD
... and SKOS 2008 and "Recommended SKOS"

Use of OWL Imports (ISSUE-119)

<RalphS> issue 119

Sean: in reference or primer?

Tom: primer

Sean: triples in the actual issue means that all triples are pulled in
... in the reference there is the use of owl:imports
... use a mechanism to show provenance...external mechanism perhaps?

Guus: dictated by owl:import semantics
... it becomes an editorial issue, how do reflect these statements in the documents?

Antoine: be sure you are aware of the existence in the primer already

Guus: the answer in the issue is that ONT2 pulls in all of ONT1

Tom: we decided yesterday that skos imports are out of scope

<RalphS> day 1 OWL Imports discussion

PROPOSED: That SKOS does not have its own specific import mechanism and that documents will have appropriate text on how to use existing owl:import mechanisms (ISSUE-119)

<RalphS> +1

RESOLUTION: That SKOS does not have its own specific import mechanism and that documents will have appropriate text on how to use existing owl:import mechanisms (ISSUE-119)

Coordination (ISSUE-40)

aliman: is our goal to have a resolution for the issue

Sean: did we decide yesterday that this was out of scope?

Guus: we don't have sufficient time to do this

<RalphS> issue 40 ConceptCoordination

<aliman> PROPOSED: to postpone issue 40, due to lack of time, lack of implementation experience with tentative solutions, and unclear interaction between SKOS and OWL.

<seanb> +1

<RalphS> +1

RESOLUTION: to postpone issue 40, due to lack of time, lack of implementation experience with tentative solutions, and unclear interaction between SKOS and OWL.

<edsu> seanb: will do

subject indexing

Guus: I'd like to propose that indexing is more in the scope of other vocabularies
... like Dublin Core, I propose to drop it from the vocabulary
... Alistair can live with it

<RalphS> Indexing properties in SKOS

Antoine: favors keeping it in

Guus: there are vocabularies that (will) propose such links

Alistair: the only reason for having skos:subject was the variability of skos:subject
... the question is for the skos:primarySubject
... the main subject of the document

Ralph: it seems even less in the scope of SKOS

Alistair: my only concern is that people can start using SKOS now

Tom: about primarySubjectOf

Alistair: we don't really need it

Guus: PROPOSE to drop the SKOS indexing properties because
... 1) it's the role of SKOS to publish vocabularies and not to indicate how they should be used for indexing purposes

2) there appears to be enough support from existing metadata vocabularies

scribe: to handle links between resources and SKOS concepts

Ralph: "drop" or "not include"?

Alistair: technically, "not include"

RESOLUTION: to not include the SKOS indexing properties because

1) it's the role of SKOS to publish vocabularies and not to indicate how they should be used for indexing purposes 2) there appear to be enough support from existing metadata vocabularies to handle links between resources and SKOS concepts

Guus: (opening the raised issues)

Guus: there are 10 left that need to be open

Open Issues

<RalphS> issue 26

<RalphS> issue 27

Guus: ISSUE 26/27 we had resolutions yesterday

<RalphS> yesterday's minutes

-> day 1 discussion on labels

Guus: both 26 and 27 are handled by the three resolutions there
... Sean, would you be happy with re-publishing Reference in two weeks?

Sean: OK

<seanb> Yes, that's fine.

Guus (closing ISSUE-77)

Guus (closing ISSUE-79)

Guus (closing ISSUE-65)

Ralph (closing ISSUE-71 and ISSUE-74)

Guus (closing ISSUE-117)

Guus: about issue on compatibility with DC

<TomB> http://dublincore.org/documents/abstract-model/

Guus: we still have not decided for exactMatch properties

<TomB> http://dublincore.org/documents/dc-rdf/

<RalphS> 4. Representing DCAM constructs using the RDF Model

Alistair: DC seems to use vocabulary encoding scheme in a way compatible with the use of SKOS concept scheme

Alistair: the DCAM pattern appears to be the same as the SKOS pattern

Alistair: dcam:memberOf looks like skos:inScheme

Ralph: how feasible would it be to write some test cases?

<aliman> Expressing Dublin Core in RDF, see e.g. example in section 4.3 for how DCAM notion of vocabulary encoding scheme maps to SKOS notion of concept scheme

<scribe> scribenick: Antoine

Alistair: there is a wiki page for test suite

<aliman> SKOS test suite

Alistair: with mapping stuff for the moment

Tom: the notion of member of a vocabulary encoding scheme is not at the same level as a concept being a member of concept scheme

Alistair: looking at the DCAM document...

Alistair: in 4.3, if ex:ExampleSubjects was a skos:Concept, the right thing will happen

Tom: but that would be redundant

Alistair: to declare that it's a member of
... it does not hurt, though
... PROPOSE the use of concept scheme URI in DC metadata as a vocabulary scheme URI does not raise compatibility issues

RESOLUTION: the use of concept scheme URI in DC metadata as a vocabulary scheme URI does not raise compatibility issues

Guus: what about issues 52 and 53?

<RalphS> issue 52 Compatibility with ISO 2788

<RalphS> issue 53 Compatibility with ISO 5964

Guus: about compatibility with ISO standards

Alistair: ISO 2788 is about monolingual thesauri, ISO 5964 for multilingual vocabularies
... ISO 2788 is about monolingual thesauri, ISO 5964 for multilingual vocabularies
... ISO 2788 is about monolingual thesauri, ISO 5964 for multilingual vocabularies

Alistair: ISO 2788 is about monolingual thesauri, ISO 5964 for multilingual vocabularies

Guus: we could have tables in one of the documents

Alistair: easy for ISO 2788, more difficult for ISO 5964

Guus: ISO 11179

<RalphS> issue 51 Compatibility with ISO 11179

Tom: it has 6 parts, the third is about vocabularies
... it defines principle for hierarchies and registries

Ralph: problem with the 'compatibility' notion
... easy to do with DC, less with ISO 11179

<RalphS> Ralph: DC has an RDF encoding, 11179 doesn't

Alistair: [Steve Harris at Oxford Com Lab] has an ISO11179 implementation
... with generation of SKOS from the ISO 11179 data

Ralph: one sense of "compatibility" is "Can I write a single RDF document instance that uses properties (and classes) from both vocabularies?"

Jon: there is a consensus that government agencies should comply with ISO 11179

<JonP> http://en.wikipedia.org/wiki/ISO/IEC_11179

Clay: it's hard to compare the two

Jon: we're talking about _compatibility_, not _conformance_

Guus: did anyone raised the issue?

PROPOSE to close ISSUE-52 by adding a table to the Primer with correspondences between ISO-2788 and SKOS constructs

RESOLUTION: to close ISSUE-52 by adding a table to the Primer with correspondences between ISO-2788 and SKOS constructs

Guus: about ISSUE-53

Alistair: it's about how to construct a multilingual vocabularies
... and while building it, linking these terms from different languages

Guus: I'd propose that with the representation of language-specific information
... SKOS relies on the existing XML facilities for language tagging

Antoine: ISO 5964 describes the process for defining labels in multiple languages and linking them

Antoine: links between terms from different languages in 5964 can be represented
... in SKOS by the fact that a same concept has labels in different languages

Ralph: PROPOSE to close ISSUE-53 by saying that we see no incompatibility between SKOS and ISO5964

RESOLVED:to close ISSUE-53 by saying that we see no incompatibility between SKOS and ISO5964

RESOLUTION: to close ISSUE-51 by saying that we see no incompatibility between SKOS and ISO11179

Symbol labels

Guus: we have no resolution from the scoping discussion

<aliman> For Clay, XML notes example at http://www.w3.org/2006/07/SWD/wiki/SkosDesign/XMLNotes

Ralph: there was a message last night mentioning interest for symbols

Guus: we can keep them

Alistair: we could have a subproperty of skos:note

<RalphS> Margherita's comments

Antoine: I'd prefer to leave them out

Tom: why would symbolic labels be in scope if we declared that XML code in notes was out of scope?

Ralph: we shouldn't try to close issue 76 without Margherita

Property naming

<RalphS> issue-82 Property Names

Guus: raised after comments on the mailing list
... I also find it very difficult
... the simplest solution is to make an absolutely clear note
... the other is to change the names of the properties

-> http://www.w3.org/2006/07/SWD/wiki/SKOS/DraftPrimer

<RalphS> Antoine: see the 5 May "minor edit"

<RalphS> Section 2.3.1

Ralph: rather than "the label of the ... property" I'd say "the name of the property"

Guus: PROPOSED to resolve ISSUE-82 by adding editorial changes to the documents highlighting the intended interpretation of broader and narrower

<RalphS> +1

RESOLUTION: to close ISSUE-82 by adding editorial changes to the documents highlighting the intended interpretation of broader and narrower

Tom: we could drop -> http://www.w3.org/2006/07/SWD/track/issues/81 issue 81

Guus: maybe we could not include an unspecified label relationship property

Alistair: the space of decision is tight. The only property is labelRelated

Alistair: the only property that caused issue 81 is labelRelated, which we've dropped. So issue 81 is moot.

<TomB> PROPOSED: ISSUE-81 is resolved because the property in question "labelRelated", has been dropped.

<RalphS> group photo

<RalphS> left to right: Ralph, Clay, Jon, Alistair, Guus, Tom, Ed, Antoine

Vocabulary Management

<RalphS> collected notes from reviewers on March 16th Editor's draft [Elisa 2008-05-07]

tomb: i pasted resolution to ISSUE-81 into IRC

PROPOSED: ISSUE-81 is resolved because the property in question "labelRelated", has been dropped.

<RalphS> VM 16 March Editor's Draft

RESOLUTION: ISSUE-81 is resolved because the property in question "labelRelated", has been dropped.

elisa: helpful comments, general consensus that if fixed specific things, general agreement to move document forward
... in terms of structure of doc, a few comments on things to make it clearer, visually outlining/emphasising things e.g. list of topics. Couple of places, organising sections better & labelling sections with headings. i will do that.
... one comment, mark van assem, needed section to say intended audience/readership. I haven't seen this in many notes from W3C, appreciated guidance on who right audience is.
... People who author RDF/OWL schemas, people doing vocab management.
... Tension between the two. What are we addressing? Concept systems? OWL ontologies? What are we talking about?
... Could use some assistance from this group on that. One area where, comments in general, unclear what we're talking about, schemas? vocabularies? biggest issue generally in feedback.
... My sense of feedback was, tension between what a vocabulary is, relationship to concept systems, rdf graphs, owl ontologies. Having a section that teases that out, clear about what we're describing in the document, helpful to broad audience.
... That's the major issue to be addressed.
... Other comments on specific sections, e.g. describing URI schemes in section 2.1. I may need assistance on. Section 2.2, thanks Diego for comments on annotation properties. Tools for generating human-readable documentation.
... A few more comments on section in readable documentation.
... In section 2.3, some feedback on maintenance policies for SKOS. I think, this section is one where I need some input, based on what we've decided. What do you want to highlight? Reference from one of SKOS documents to this, to help connect the two.
... Then there were a few minor comments on research topics, tightening it up.
... That was majority of issues. Biggest one is, what's a vocabulary, graph, ontology etc.?
... That's the biggest issue, need help, Alistair made a good start in email he said. Might be a good idea to have a whole section in the document on this.

tomb: does seem to be a lot to do. In march, planned to publish on may1. in april, changed to publish on june 1 as a WD. but to publish as WD, need to have response to all of points raised, many can discuss now, identify which need further work.
... would need a draft. Moving the note beyond 1 june doesn't seem like a good idea. Feels like there's a lot that needs to be done.
... When could you get a revised draft to WG?

elisa: started on it last week, hoped to get it done this weekend, not possible. I have started addressing them, haven't sent any out yet. Lions share of small issues not hard. Things I need help with, definitions, ontology, graph etc. So much confusion out there.
... Even in the semantic wbe community.

ralph: Do you think there is a distinction we need to clarify for the purposes of this doc?

elisa: could say we're talking about pulishing schemas and their documentation. Not talking about concept systems or vocabularies. So if refocus, less to discuss.
... I think document right now, tries to do both. Maybe because of my misunderstanding of goal. If can corral it, state something up front, or eliminate by talking about schemas, maybe make document more readable.

tomb: I propose we have a discussion first about the meaning of "vocabulary". As I noted in my comments, there's the draft we started with, still reflects ambivalence/ambiguity about what a vocabulary is which was present in early wiki draft.
... whether RDF vocabulary is a set of resources or a set of URIs ...
... Alistair points to RDF semantics and the way that clearly says a vocabulary is a set of URIs, ...
... but on the other hand, alistair also points out, notion of OWL ontology is different from notion of vocabulary. In OWL semantics, closer to notion of RDF graph than "vocabulary".
... I'd like to discuss, if we say an RDF vocabulary is a set of URIs, then sets of assertions around those URIs are out of scope? E.g. domain and range etc. Are they part of a vocabulary? Or is it just set of URIs?
... Or are we dealing with technical definition of a vocabulary, or information notion of vocabulary as set of resources denoted by URIs.

ralph: let me try my formulation. I hoped we could convey advice on how to manage things like SKOS. How to manage evolution of a specification of some set of things. I mixed together vocabulary, ontology, RDF namespace for purposes of managing whatever those things describe.
... If it would answer you're concerns to rename as "namespace management", telling people how to manage evolution of definitions of terms in the namespace, dated versions to old properties etc.
... that DC has dealt with, SKOS, OWL, FOAF stability vocabulary. For me, answer to the question is, if choosing either choice, e.g. domain and range constraints are not in "RDF vocabulary" ... all properties of a property are what need to be managed.
... We're talking about managing *the definition of SKOS* and the documents at the SKOS namespace.

Tomb: "namespace" is an overloaded term.

Ralph: It's not just the URIs that define the resources. Also other properties of resources. Elisa, do you have any clever terms from OMG?

elisa: they're confused. Maybe we could say up front, what we mean is, collection of things in some specifications, e.g. SKOS and all documentation a specification, then we're talking about managing a specification on the Web.
... Exactly what ralph said, conflated notions of OWL ontology, RDF vocabulary, concept system, publishing something which is specification of something at some place ...
... talking about managing evolution of those things.

ralph: so if we say our audience is, people who have to evolve contents of a namespace document, if that's our audience, then is it confusing to that audience to conflate schema ...

tomb: schema is a bad word

elisa: schema is a subset of that specification. OWL ontologists, everything explicit in the ontology.
... I would argue it's the whole specification.

Alistair: I think we _can_ talk about managing "RDF vocabularies"
... I raised the issue because the document seemed to define "RDF vocabulary" in 2 different ways

Elisa: I'm happy to drop those definitions

Alistair: defining and managing a Web vocabulary includes all the related documents

[from before] ralph: I wouldn't want to include in scope all documentation practices, out of scope.

ralph: hung up on, what exactly is RDF vocabulary. Found in RDF model and concepts, it had definition of RDF vocabulary. Authors didn't mean to exclude property of a property.

Alistair: when you're managing a vocabulary, you're managing a set of URIs and a set of properties about those URIs
... you're managing at a syntax level
... you're not managing a _class_; you're managing a _definition_ of a class
... in a model-theoretic world there's what you say and the interpretation of what you say
... be explicit that we're managing _documentation_

Elisa: I can take a crack at writing a new paragraph describing this

Alistair: you can't version a _class_ but you can version a _definition of a class_
... you can't version the world :)

Tom: that fits with DCMI usage
... we have successive snapshots of a description of a term
... the term and each snapshot have their own URIs

elisa: I can't try to write short paragraph in the introduction.

ralph: I think that will help, get to meat of what this practices is trying to describe, i.e. managing definitions

elisa: examples of multiple definitions of same terms?

tomb: i have an action to write a paragraph on that.

elisa: would fit nicely

tomb: I wondering now about stuff in note which doesn't fit so well. Taking things out which are orthogonal.
... So e.g. in my comments on introduction 4th para ... this emphasis on repositories and portals, example of a repository ...

elisa: might go away, if you don't think useful

tomb: for reviews, respond point by point, take out or leave in, so then reviewers can check new version against comments.
... we need one more iteration, have a new version of the entire draft that we can read and discuss in light of response to reviews.

elisa: I will do that. The philosophical issue in reviews slowed me down, didn't know how to address that.

tomb: going down my comments, section 2.1 para 7, not clear what example of URI schemes, what the point was there. Because we have principle of URI opacity. Examples seem to say, one can construct URIs so embeds informaiton in strings ...
... assisting users in finding things, seemed to imply good practice to embed information in URIs. (A) did I read that right, and (B) do we want to recommend?

elisa: OMG do this. OASIS does this. So we can either take that out, not in keeping with notion of opacity, or leave it in and describe tradeoffs.

ralph: tension here, because value of this document will be to say, some stuff jon's doing with his registry, snapshots of sets of things which make sense, give snapshots a name with dates, have cognitive value to people.
... so say, here's a reasonable practice for naming things, but URIs are supposed to be opaque. So not sure.

tomb: But either describe example in more detail, or drop. As it is, not clear what example is actually saying. Is this document about recommending something explicitly?
... as it is, example doesn't provide enough information to understand what OMG is actually doing.

elisa: I can provide example, if want to keep it in and expand.

ralph: I'd either drop entirely, or expand into something like a cookbook. I perceive call for cookbook-type things. E.g. owner of the foobar vocabulary, if I do X Y Z nobody at W3C will have a problem. Current example has too many links.

elisa: I will expand to include examples at OMG, how it's working.

ralph: Before you do the work, in this para you say OMG has adopted practices, on the other side of complication. Specifications are sufficiently large and detailed that simple mechanisms aren't working. Rather restrict to simple cases.

elisa: I'll have a look at it.

tomb: My preference to drop it. Expanding it ideally would involve including simpler examples as well, e.g. datestemping in constyructing URI strings.
... we should be careful not to expand scope of what we have, try to narrow scope. We need to get out the door in a very short time. That would expand to whole set of issue which we don't have time for.

elisa: ok

tomb: Some detail about tools which could go. Maintenance policies, there was section about articulating policies, section 2.3 last para.
... policies for vocabularies, but list covers vocabularies and other stuff, things are more than just vocabularies. Not that many published policies, including SKOS. There was a published policy in SKOS 2005, but effectively that's been superseded by decisions taken here. Not clear to me that we have requirement and resources to formulate a policy per se.
... Although that would be desirable to do, but do we have now with tight human resources and focus on Recommendation documents in place before the summer, what that would mean to assign actions to write up maintenance policy for SKOS.

Alistair: the thing that changed for SKOS was that it entered W3C Recommendation Track
... which means that decisions are made within the W3C process
... before that, we had this idea that SKOS was totally community-driven

Ralph: Yeah, but W3C process ... Dan Brickley for FOAF had vocabulary for how well baked each vocabulary term is. W3C doesn't say anything about whether you SHOULD/MUST/MAY do fine-grained indication of maintenance.
... If we got to point 2 years ago, would like to say something about e.g. whether like FOAF vocabulary subset or not. But at this point, can't do more than cite example of what's been done.
... Alistair in 2005 SKOS had done similar sort of stability things, if you're point is we should drop aspiriations to deal with stability vocabulary in this note, we don't have time for that.

Alistair: the SKOS stability terms don't really make sense now in the way SKOS is being managed
... FOAF is managed on a shorter timescale

ralph: think of this the other way around, original SKOS example, FOAF example, DC example, important to say something to community about how much consensus around a term. Maybe encourage W3C to think about their process. Need to roll with evolution of definitions, maybe community knows something which W3C Process doesn't yet formalize.

elisa: In terms of document, maybe put into two classes, vocabs like FOAF or DC with ongoing revision policy. Other class of things go through more formal review process within some kind of standards-based structure, e.g. W3C has REC-track, OMG structure for documents final then formal, then process in ISO WD, CD, FCD ... more informal community approach, more formal standards approach ......
... maybe that is enough?

tomb: There is a formal process with DCMI terms. Once they're published, DCMI policy is, we can deprecate URI but URIs are forever. The audience for this, we want to encourage people who develop vocabulary, if examples from standards processes, it points out of sync with general ideas to publish formal schema, identify versions ... these headings ...
... how they're formulated, aimed at audience to lower the barrier and encourage to create vocabularies. Focus on large complex ontologies and research topics, preference to completely cut. Doesn't fit with the message as I understand it of the note, to invite people to look at some example that they might reasonably follow.

ralph: You said something there, it's the case that standards orgs like OMG & W3C have formality that is above and beyond what we think the community ... we would like to encourage more community-develop vocabularies ... formal processes forced on us is not what we'd expect.
... The more we talk about formal processes, the more we scare off...

Tomb: selling semantic web in library world, perception that semweb is research, it's way out there and modeling things, we just want something that works, i'm exagerrating this.
... So I feel uncomfortable if group comes out with note that underlines researchy formal complex aspects, as opposed to lower barrier basic principles "use URIs" etc.

<edsu> TomB++

Tomb: problem for semweb activity generally. As semweb deployment WG, we need to push on message which emphasises general principles as opposed to complexities, and doesn't emphasise how complex things can get, especially when look at advanced research issues.

elisa: Fine with me, my users in UML world would prefer that. My user community tends to be people wanting to share with each other, don't need all the baggage. So can happily refocus. If you have examples like FOAF that I can point to, that have been successful in broad community. FinnOnto community of folks doing what we descibre, community effort to retain cultural hertiage, ontologies...
... for art & literature.

<RalphS> FinONTO citations

elisa: they're using SKOS. Only example I know of, national example, maybe audience we're targeting this for. I'm happy to lighten up and direct efforts to doing the simple things.

ralph: Jon do you have support for notions of stabillity of definitions?

jon: we assume definitions aren't going to be stable, so we've defined timeslices, so put stability in hands of consumers, editor's are then free to morph a vocabulary over time. Given users a mechanism to lock it down and trust over time.

ralph: is there explicity mechanisms to say this definition is in flux

jon: we have number of statuses we can assign from approved published to unstable at property level

ralph: analogous to SKOS and FOAF

jon: took our stability definition from those.
... we include stability mechanism at every level, can define at whole vocab level, or single property or concept, and can change over time.

tomb: write some sentences on this
... point out SKOS vocabulary falls under the maintenance procedures as defined by W3C process.

ralph: well but, in context of 2.3, (articulate maintenance policies) ... 2005 SKOS had fine grained stability descriptors a la FOAF & metadata registry .. would'nt want to lose that.
... that was in past when SKOS was community exercise. Now SKOS in standards process, have not retained.

tomb: interesting point, good place to capture it.
... can anyone take an action to write a paragraph about that?

ralph: IRC has it?
... I'm arguing against somet.hing I said earllier, maybe time to do a bit of case study exposition, but don't have time to do a vocabulary of stability.

Alistair: what SKOS 2005 was an ideal
... what we actually did in practice was less that this ideal
... so the articulated SKOS 2005 maintenance policies may not be as useful as a working example

elisa: Can still point to it as ideal, in practice less idea?

ralph: propose we don't admit to that.

elisa: It could be a short paragraph.

ralph: didn't prove the model is broken
... similar in FOAF.
... interesting to see what happens with Jon's model, more open, people construct vocabularies by retrieving definitions from repository, so separation between benign dictators and users retrieving stability.

elisa: I have some direction, can poke people to send paragraphs. Can look to lighten up research side, emphasise practical approaches. Try to point to practical things you send me. Eliminate scary parts.

tomb: suggest revised timetable, first to respond to comments as ...

elisa: tomb talking about timetable?

tomb: revised timetable, suggest step 1 to respond to comments yes no maybe, there are a few issues e.g. wordsmitihing scopign statement (what we mean by a vocabulary) (also mark van assem, if use "vocabulary", many people associated that with controlled vocabularies) -- so handling scoping on mailing list would be good, if can do that in next 2 weeks, revised version by may 20, time to...
... iterate on mailing list, aim for publication decision on june 3 or june 10.

elisa: ok. I will get my responses out this week. perhaps get draft up towards end of next week. Following week is semantic technologies conference.

tomb: anyone have any further questions?

ralph: any other big things?

elisa: philosophilca discussion no so nasty. hadn't identified tension between practical light weight folks as opposed to heavy weight side. Occurs to me Jim hendler wrote article on this tension a while ago. Aside from that, most specifics ok.

tomb: propose short break, then hack away at skos issues.

SKOS Issues

<RalphS> issue 37 SKOS Specialization

PROPOSED: Section 4.8 of the SKOS Primer resolves ISSUE-37

RESOLUTION: Section 4.8 of the SKOS Primer resolves ISSUE-37

ISSUE-45 NaryLinksBetweenDescriptorsAndNonDescriptors

antoine: i think it should have the same fate as the coordination issue, since i believe the solution for one is the solution for the other
... and we postponed ISSUE-40

<RalphS> issue 45 N-Ary Links between descriptors and non-descriptors

<RalphS> issue 40

PROPOSED: to postpone issue 45, due to lack of time, lack of implementation experience with tentative solutions, and unclear interaction between SKOS and OWL.

RESOLUTION: to postpone issue 45, due to lack of time, lack of implementation experience with tentative solutions, and unclear interaction between SKOS and OWL.

Alistair: we are clear on the relation of SKOS and OWL

Alistair: we are clear that SKOS is an OWL Full ontology

Alistair: what is yet unknown is what all the reasonable patterns are for using SKOS and OWL together, and becuase of our lack of knowledge, we don't know what the consequences of solutions for coordination are on those patterns

ISSUE-46 Indexing and NonIndexing concepts

<RalphS> issue 46

Antoine: i think we can drop this one
... i was involved in the raising of this issue
... the fact that skos:subject is removed makes it unclear if it's ok to put this in

aliman: yeah it seems to be out of scope

Alistair: since we've said that indexing is out of scope then this also seems out of scope

<RalphS> PROPOSE: Close issue 46 as we have decided that the indexing vocabulary is not part of SKOS

RESOLUTION: Close issue 46 as we have decided that the indexing vocabulary is not part of SKOS

TomB: going through these issues has a pretty clear overlap with finalizing the use case document as a note
... we should give an action to the editors of the use cases to report back on the consequences of the decisions for the final set of proposed and candidate requirements

Antoine: we should say which requirements are not met, i think that would do the trick

TomB: is there anything that needs to be revised?

Antoine: there is the issue of what to do with all the use cases ... is it ok to keep them on the wiki?

JonP: we've got use cases that came into the list and aren't documented

aliman: it's a nice repository of use cases

TomB: would be nice but we need to be careful about dividing our attention

RalphS: would it be ok to just point to the wiki from the Note?

Antoine: is it ok for w3c?

RalphS: sure, I'd treat it as a record of the design rationale for the Recommendation
... for community relations reasons its worth putting the effort of editing the information in the wiki -- but we have better ways to spend our time right now

JonP: need to put up what we've decided not to do

ACTION: Editors of the Use Cases to clean up the lists of requirements in light of resolutions [recorded in http://www.w3.org/2008/05/07-swd-minutes.html#action02]

Issue-47 MappingProvenanceInformation

<RalphS> issue 47

aliman: antoine, you have a proposal for this?

<JonP> http://lists.w3.org/Archives/Public/public-swd-wg/2008Feb/0063.html

Antoine: proposing to create a mapping scheme that would be an RDF named graph, and provenance would be retrieved using the named graph

<aliman> http://lists.w3.org/Archives/Public/public-swd-wg/2008Feb/0017.html

aliman: this proposal has 2 solutions 1) mapping scheme 2) use n-ary relations
... was your proposal to go for the first of these?

Antoine: yes

Elisa: still there?

<RalphS> proposed text to close issue 47

RalphS: we don't know what "standard RDF containment mechanisms" are
... I don't like us including vocabulary like Named Graphs in a REC

Antoine, Alistair: we've done that already

TomB: maybe we have to stay till 5:15 :)

aliman: one thing we can say is that it's a general rdf problem, and it's not our problem
... we could point to possible options, such as the use of named graphs, sparql queries as a suggestion

RalphS: in the current working draft we use it in the appendix about patterns, and in a sideways reference to concept schemes and named graphs
... we're making no statements about something that does not exist yet
... but this resolution is a step beyond to suggest someone use this even though it doesn't exist yet

aliman: what does sparql lack?

RalphS: sparql support is in query results right?

aliman: sparql is a recommendation as of january
... and it has 8.2.2 specifying named graphs

<Elisa> Sparql has some limited support for mapping, but doesn't support nesting very well

-> http://www.w3.org/TR/rdf-sparql-query/#namedGraphs 8.2.2 Specifying Named Graphs

RalphS: sparql is a query language that allows the query to be restricted to a particular set of triples
... antoine's proposed resolution is consistent with this
... the problem i have is that in the context of sparql they can put in this source URI in a way that I don't think we have the luxury to do

aliman: can't we resolve this by saying it's out of scope for us, and we'll point to examples of other ways of doing this

RalphS: i'd be happy to point at what sparql does, but i'd be nervous about doing something that looks like a specification for something

Antoine: i would be ok with that as long as it's the same as the semantic relations solution

RalphS: maybe i'd be happy with a subset of Antoine's text
... is just the final sentence sufficient?

<Ralph:> how about just the final sentence "Similar to what..." in http://lists.w3.org/Archives/Public/public-swd-wg/2008Feb/0078.html ?

aliman: can't we just resolve quickly and then work with this text?

RalphS: i'm ok with that

<aliman> PROPOSED: Provenance of mappings is not handled by the introduction of specific SKOS vocabulary. In the SKOS reference documents (Reference and maybe Primer), SKOS users are instead pointed at other RDF containment mechanisms.

RalphS: as long as we don't point at stuff that doesn't exist
... The URI of the information source can be used in a query ... that part is not hypothetical

<aliman> PROPOSED: Provenance of mappings is not handled by the introduction of specific SKOS vocabulary. In the SKOS reference documents (Reference and maybe Primer), SKOS users are instead pointed at other RDF containment mechanisms (E.g. the URI of a mapping information resource can be used as the name of a graph in a SPARQL query).

RalphS: the thing I'm trying to protect us against, is that in timbl's quoted graphs, the literal graph is not asserted
... if we use the term named graphs, then some future spec might not do what we need

<aliman> PROPOSED: Provenance of mappings is not handled by the introduction of specific SKOS vocabulary. In the SKOS reference documents (Reference and maybe Primer), SKOS users are instead pointed at other RDF containment mechanisms (E.g. the URI of a mapping information source can be used in a SPARQL query).

<RalphS> +1

<aliman> RESOLVED: Provenance of mappings is not handled by the introduction of specific SKOS vocabulary. In the SKOS reference documents (Reference and maybe Primer), SKOS users are instead pointed at other RDF containment mechanisms (E.g. the URI of a mapping information source can be used in a SPARQL query).

RESOLUTION: Provenance of mappings is not handled by the introduction of specific SKOS vocabulary. In the SKOS reference documents (Reference and maybe Primer), SKOS users are instead pointed at other RDF containment mechanisms (E.g. the URI of a mapping information source can be used in a SPARQL query).

ISSUE-49 LexicalMappingLinks

-> issue 49 LexicalMappingLinks

PROPOSED: the XL appendix provides a framework for asserting lexical mapping links

RESOLUTION: the XL appendix provides a framework for asserting lexical mapping links

ISSUE-64 TextualDescriptionsForConcepts

<RalphS> issue 64

aliman: the primer has place holders for talking about these patterns

Antoine: yes but they are empty

JonP: do we continue to allow these design patterns, yes.

aliman: i don't see any reason not to

RalphS: let the community experiment. What was the DCMI experience in this sort of thing?

TomB: we left the range of description unspecified I believe

JonP: part of this issue is how should we formally specify it

aliman: the SKOS reference has done this, so maybe we could use that
... some people will want to keep things simple, and some people will want to use a bit of structure

Antoine: i like not closing the door to it

RalphS: you didn't think there were huge interoperability problems that arose? is it similar situation?

aliman: i think it is similar
... there isn't much that's not flat in dublin core data

antoine: the problem is how to decide whether these different patterns are optional or not
... i would feel uncofortable making skos tool developers to deal with all three patterns

RalphS: this is the question

aliman: communities of practice could emerge, and there are application profiles we could talk about

RalphS: i'm still comfortable with community experiments, some tools may encourage the adoption of a particular pattern

aliman: i imagine the literal pattern will predominate

TomB: we assumed in DC that there are some properties like description that have been so widely deployed, even when they can't be constrained, they'll just need to be special cases, we don't know what else to do with that ...
... in other cases we tried to make a clear decision between literal no-literal

RalphS: is it ok with you Antoine that whatever happens, happens?

Antoine: maybe?

aliman: pracitces may differ for different properties, so making a sweeping statement at a high level, because people might create different refinements with different characteristics

RalphS: it could be advice to the user that don't assume that the tools support each of these patterns
... it feels like an area where we are accomadating experimentation

aliman, Antoine, Tomb: yes

aliman: can we just let it happen and not say anything?
... hard to say without specific examples/tools

(ralph packing up laptop)

PROPOSED: SKOS will explicitly allow all 3 patterns for documentation properties

RESOLUTION: SKOS will explicitly allow all 3 patterns for documentation properties

TomB: should we print out remaining Issues and take them to dinner?
... laughter ..

lets run down the list and say easy|medium|hard

ISSUE-72 ExactMatchTransitive

aliman: 72, 73, 75 medium to high

76, easy

78, easy

ISSUE-80

aliman: could be the subject of an interesting long note
... reluctant to squeeze in to the Primer

ISSUE-83

aliman: probably easy

ISSUE-84

aliman: the issue is to review the statement in the Primer
... if we are it's easy, if we're not it's hard

Antoine: diego sent something

TomB: so hopefully easy

ISSUE-86

aliman: medium
... this issue was triggered by the section of the primer that talks about extending concept schemes
... an application would need to know it can get a URI
... what do we expect to happen when a URI for a concept is resolved
... medium well

Elisa: i don't think it's overly hard, medium sounded ok

TomB: i think we are adjourning ... thanks Elisa

Elisa: looking forward to catching up with you next week

meeting adjourned

Summary of Action Items

[NEW] ACTION: Clay will respond to Jakob about the resolution for notations and x-notation [recorded in http://www.w3.org/2008/05/07-swd-minutes.html#action01]
[NEW] ACTION: Editors of the Use Cases to clean up the lists of requirements in light of resolutions [recorded in http://www.w3.org/2008/05/07-swd-minutes.html#action02]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.133 (CVS log)
$Date: 2008/05/13 18:13:58 $