See also: IRC log, day 1 minutes
<RalphS> Day 1 record
<RalphS> conference room photos
<RalphS> flipchart images
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]
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"
<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)
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
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
<RalphS> issue 26
<RalphS> issue 27
Guus: ISSUE 26/27 we had resolutions yesterday
<RalphS> yesterday's minutes
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?
<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
<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
<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.
<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
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
<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]
<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
PROPOSED: the XL appendix provides a framework for asserting lexical mapping links
RESOLUTION: the XL appendix provides a framework for asserting lexical mapping links
<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