Re: List of resolutions from the Face-to-Face meeting

Sini, Margherita (KCEW) wrote:
> Hi Ralph and Sean,
> 
> I think Sean proposed to have the list of all resolutions at the end of the
> minutes of the meeting. As I had to read all in order to see if I have
> comments, I volunteer on doing this.
> 
> Here below the list of resolutions I could find. Please check if everything
> is ok.
> 
> -----------------------------------------------------------------------------
> ---
> RESOLUTIONS from  Face-to-Face meeting
> -----------------------------------------------------------------------------
> ---
> 
> DAY 1: 06 May 2008
> 
> - RESOLVED: to accept minutes of 29 April teleconference
> (http://www.w3.org/2008/04/29-swd-minutes.html)
> - RESOLVED: SKOS Imports low priority
> - RESOLVED: Publish RDF schema as is (OWL Full)
> - RESOLVED: to have a new namespace
> - RESOLUTION: http://www.w3.org/2008/05/skos# is the namespace URI
> - RESOLUTION: to resolve skos:related, skos:broader and
> skos:broaderTransitive are not normatively irreflexive
> - RESOLUTION: to accept sections 3 (xl:Label), 4 (Preferred, Alternate, and
> Hidden xl:Labels), 6 (Binary Relations Between Instances of xl:Label) of the
> 14 April -XL proposal and the vocabulary defined there.
> - RESOLUTION: Include XL sections 3, 4, 6 in SKOS Reference as OPTIONAL and
> NORMATIVE
> - RESOLUTION: Use http://www.w3.org/2008/05/skos-xl# as XL namespace URI
> - RESOLUTION: 
> 	1. keep the mapping vocabulary broadMatch, narrowMatch, 
> 	2. broadMatch, narrowMatch, etc. are rdfs:subPropertyOf broader,
> narrower, 
> 	3. there are no semantic conditions on broadMatch, narrowMatch; i.e.
> graphs 1-6 are all consistent, 
> 	4. there is some text about cultural conventions explaining where we
> expect broadMatch to be used, 
> 	5. by convention, mapping properties are only used to link concepts
> in different schemes, 
> 	6. in the Last Call WD we'll note that the mapping vocabulary may be
> dropped
> 
> MY COMMENTS:
> 
> Ok for all except:
> - >>>> Publish RDF schema as is (OWL Full) <<< --> I would have like to have
> owl-DL because I think one advantage may be computability if we do reasoning
> - point 6. >>>> in the Last Call WD we'll note that the mapping vocabulary
> may be dropped <<<<  I think is better to keep and I do not understand this
> point 6. as in my opinion may be conflicting with 1.


Marherita,

The reason that it is OWL Full is rather low-level syntactic (use of 
Dublic Core properties is not allowed, for example) and do not really 
influence computability. Also, the situation is likely to chang with OWL 
1.1/2.0, although we do not know yet precisely how. If we now force the 
scheme to be OWL DL important info has to be dropped, so that's why we 
opted for the OWL Full choice.

Guus

BTW Some people talk about OWL Full as if you can do reasoning with it. 
That's not true, we actually do it all the time. You just don't have 
certain guarantees. The reasons for being in "Full" are usually quite 
trivial and present no real computational dangers.


> 
> -----------------------------------------------------------------------------
> -
> DAY 2: 07 May 2008
> 
> - 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.
> - 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.
> - 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)
> - RESOLUTION: to postpone issue 40, due to lack of time, lack of
> implementation experience with tentative solutions, and unclear interaction
> between SKOS and OWL.
> - RESOLUTION: to not include the SKOS indexing properties (== to drop
> skos:subject, skos:isSubjectOf, skos:primarySubject and
> skos:isPrimarySubjectOf)
> - RESOLUTION: the use of concept scheme URI in DC metadata as a vocabulary
> scheme URI does not raise compatibility issues
> - RESOLUTION: to close ISSUE-52 by adding a table to the Primer with
> correspondences between ISO-2788 and SKOS constructs
> - RESOLUTION: to close ISSUE-51 by saying that we see no incompatibility
> between SKOS and ISO11179
> - RESOLUTION: to close ISSUE-82 by adding editorial changes to the documents
> highlighting the intended interpretation of broader and narrower
> - RESOLUTION: ISSUE-81 is resolved because the property in question
> "labelRelated", has been dropped.
> - RESOLUTION: Section 4.8 of the SKOS Primer resolves ISSUE-37
> - RESOLUTION: to postpone issue 45, due to lack of time, lack of
> implementation experience with tentative solutions, and unclear interaction
> between SKOS and OWL.
> - RESOLUTION: Close issue 46 as we have decided that the indexing vocabulary
> is not part of SKOS
> - 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).
> - RESOLUTION: the XL appendix provides a framework for asserting lexical
> mapping links
> - RESOLUTION: SKOS will explicitly allow all 3 patterns for documentation
> properties
> 
> MY COMMENTS:
> 
> I agree on these and:
> - if we have skos:notation then I have an idea that this may also be used for
> the symbols, in this case you may drop the symbols as skos:notation is more
> generic and can also be used for symbols. We have to check however if we can
> specify source and/or language for this skos:notation.
> 
> 
> -----------------------------------------------------------------------------
> -
> 
> 
> Hope this helps
> Margherita
>