Hello Mark, Bernard, Jakob, Johannes,
First, thanks for contributing to the discussion!
>
> > Now the question is : does that belong to SKOS (core) scope? looks
like
> > borderline. And if we open this door, who knows what is likely to
enter
> ...
>
> Without noting which things might enter it's like scaring someone with
> imaginary monsters under the bed :-)
Well there is a point in what Bernard says: if you aim at some standard
it's better if people are convinced there is nothing like a monster in
the closet ;-)
> What is a risk is that people will start using Terms to annotate with
> instead of with Concepts. But as we as a SW community should lead the
> way for others to represent thesauri etc. in RDF it is our job anyway
> to educate on the right usage.
>
> > In a modular approach, seems to me terminological aspects should be
> > dealt in later on in some specific extension, SKOS-Term, whatever.
>
> I don't understand this argument. I'd say it's the other way around:
> first the complete model that covers the requirements, then the
> simplifications. And again it is a question of perspective on what is
> complex and simple. Is adding one class to the model adding that much
> complexity?
I would say Bernard's idea of extension makes more sense to me. The
problem is that it is not really applicable to SKOS as is, at least
regarding this problem of labelling concepts with terms. Because once
you've decided that prefLabel and other have only RDFS literal as a
range, then you close the door to any Term-like extension (based on
using resources) designed by specializing standard labelling properties.
Which is a shame, and may ruin the interest of these 'extensions'.
So keeping simple and keeping the door open for extensions, yes. Keeping
simple and making further extensions almost impossible, well we have to
find serious motivations for that.
>
> And this solution allows you to get rid of the problems with
> qualifiers and UF+ etc. The current model is just too simple to deal
> with the requirements posed on SKOS in a straightforward way.
>
> > Problem if we include skos:Term in SKOS core, looks like we have to
> > revisit many things, e.g. prefLabel and altLabel.
>
> So this is an argument about the process. Then we need an estimate of
> how much time it would require to change. I don't see why it would
> take that much time. The requirements for representing UF+ etc.
> clearly show why the change is justified.
>
> > Some will use them as they stand now (datatype properties) and other
> > will use "hasTerm" (object properties). Making further federation of
> > such vocabularies very tricky.
>
> That is a "backward compatibility" argument. Is the uptake of SKOS
> already that large that this is a real problem? And as you say
> yourself: for very useful applications you already need an extension.
> Why produce something that needs extension?
It is true that the time for changing the model would be small. The
backward compatibility problem is bigger, though many applications of
SKOS are still being developed and perhaps could make the switch easily
(the problem is that if they use SKOS as is, they don't need this 'term
reification', so motivation is low for them)
In order to clarify the debate and the tradeoffs of different solutions,
it would be useful to gather cases where this term reification would be
useful. In the context of the SWD working group, I have an action on me
to formalize the problem of representing links between labels, which is
I think pretty the same fundamental aspect (you reify a term only to
link it to something else).
I think that in the process of that I will try to give references to
existing cases where these links would be useful. This may include some
use cases contributed to the call we issued, as well as things that were
contributed to this list, such as Bernard and Mark's examples. I will
also try to mine the old mails of this list, where this subject has
already been debated as Mark recalls. So if you have examples to feed us
with, do not hesitate!
Cheers,
Antoine
PS: by the way I really think that the USE+ case can be solved without
reification, as long as SKOS features coordination, as we discussed with
Jakob (see 'Implementation' section of [1]). Indeed Mark's solution is
structurally quite close to that, except that it tried to put the term
as the subject of the USE property, while we can still continue to use
it as the (literal) object of altLabel.
[1]
http://lists.w3.org/Archives/Public/public-esw-thes/2007Feb/0040.html
>
> > And I think it would be a very bad idea to enforce "term
reification"
> > (so to speak) by getting rid of prefLabel and altLabel as they
stand.
>
> Why is it a bad idea to get rid of pref/alt distinction?
>
> Cheers,
> Mark.
>
> >
> > Bernard
> >>
> >> Hi,
> >>
> >>> but I don't see the advantage of it. The second point is right -
"Z"
> is
> >>> not a concept but a term and currently skos does not allow it to
be a
> >>> subject - but the whole USE-relationship is about terms anyway.
> >>
> >> Long ago I proposed the inclusion of a skos:Term class that could
be
> >> used to solve this problem. It is very straightforward then to
manage
> >> the different kinds of links between terms, concepts and
coordinations.
> >>
> >> Having skos:Term allows to represent terms separate from concepts
that
> >> use it. Terms are then roughly equivalent to WordNet's WordSenses
and
> >> concepts to WordNet's Synsets. This allows all kinds of
relationships
> >> between Synsets/concepts (which carry non-lexical meaning) and
> >> Terms/WordSenses (which do carry lexical meaning). This includes
the
> >> various USE relationships. USE/USEFOR becomes "hasTerm" (or
separated
> >> into prefTerm and altTerm but I dont think the pref/alt distinction
to
> >> be appropriate anymore) in the example below (adapted from
Jacob's).
> >>
> >> -------------------------------------------------
> >> :abc a skos:Term ;
> >> rdfs:label "C Programming Language" .
> >>
> >> :def a skos:Term ;
> >> rdfs:label "C" .
> >>
> >> :ghi a skos:Term ;
> >> rdfs:label "Vitamin C" .
> >>
> >> :jkl a skos:Term ;
> >> rdfs:label "C" .
> >>
> >> :c1 a skos:Concept;
> >> skos:hasTerm :abc ;
> >> skos:hasTerm :def .
> >>
> >> :c2 a skos:Concept.
> >> skos:hasTerm :ghi ;
> >> skos:hasTerm :jkl .
> >> -------------------------------------------------
> >>
> >> And defining those problematic relationships becomes simple
> >>
> >> * USE X + Y
> >>
> >> -------------------------------------------------
> >> coal mining USE coal + mining
> >>
> >> :cm a skos:Term ;
> >> rdfs:label "coal mining" .
> >>
> >> :c a skos:Term ;
> >> rdfs:label "coal" .
> >>
> >> :m a skos:Term ;
> >> rdfs:label "mining" .
> >>
> >>
> >> :conceptc a skos:Concept;
> >> skos:hasTerm :c .
> >>
> >> :conceptm a skos:Concept;
> >> skos:hasTerm :m .
> >> -------------------------------------------------
> >>
> >>
> >> ... and finally the relationship:
> >>
> >> -------------------------------------------------
> >> :use1 a skos:UseAND ;
> >> skos:source :cm ;
> >> skos:target skos:ConceptAND [ skos:member :c ; skos:member :m
].
> >> -------------------------------------------------
> >>
> >> Because Terms are not used for indexing, the combination "coal
mining"
> >> as a Term can point to the appropriate coordinated concepts "coal +
> >> mining".
> >>
> >>
> >> * USE X OR Y
> >>
> >> grinding mill
> >> USE grinding house OR grindery
> >>
> >> ... well very similar, without stating the obvious concept
definitions:
> >>
> >> -------------------------------------------------
> >> :use2 a skos:UseOR ;
> >> skos:source :gm ;
> >> skos:target skos:ConceptOR [skos:member :gh ; skos:member :g].
> >> -------------------------------------------------
> >>
> >> Of course we discussed this kind of thing before and the tradeoff
is
> >> that this makes SKOS more complex, and the exposing of Terms as
> >> entities in their own right might be open to abuse (e.g. start
> >> indexing stuff with Terms). But it also allows more fine grained
> >> mappings and man'ment info to be attached to them.
> >>
> >> Cheers,
> >> Mark.
> >>
> >
>
> --
> Mark F.J. van Assem - Vrije Universiteit Amsterdam
> markREMOVE@cs.vu.nl - http://www.cs.vu.nl/~mark