RE: some minor issues

Hi Philipp,

thanks a lot for this reassuming email ...and not long at all, the
content/length ratio is absolutely perfect :-)

a couple comments:

1) agree
2) agree, and think we really need an inverse. These same people you speak
about, will mostly like to go from ontology entities to lexicalizations.

3) Clear, I understand that people having badly written labels (I cannot
count the skos datasets which are full of codes in the labels, such as "838
lorem ipsum...", just because the original thesaurus they have been built
from had them hard coded and these have not been processed in the conversion
to RDF..) which were acceptable for skos but clearly not for ontolex, has to
make some reengineering. Also the kind of reengineering you speak about
(dividing into lemmas) is necessary. But it is clear that "if" I want to
embrace this model, I have to accept its finer granularity and make this
work, so no issue for this. What I'm more concerned about is the opposite.
If we want that, at data level, this will not imply any duplicate effort, we
must guarantee:
  - *at least* derivation rdfs:label
  - *at least* compliancy with skos:pref/alt/hiddenLabel (not derivation is
possible, as this distinction is more informative on the skos side, as we
have no pref/alt/hidden distinction)
  - as you say, *not necessarily*, compliancy with skosxl labelling support
what I actually say is that skosxl could be a good vessel for the (imho)
required skos compatibility and derivation. Your intuition about LexicalForm
is ok (sorry I must admit I didn't pay much attention on the lexical side of
our model). So for sure we need some (series of) chains like:

<aontologyentity>-->denotes-1--><LexicalEntry> --> form --> <LexicalForm>
--> writtenFrom --> "lorem ipsum"
=====>
<aontologyentity> --> rdfs:label --> "lorem ipsum"

Where denotes-1 is the inverse of denotes. But I would think maybe of having
something like pref/alt/hidden as subprops of this inverse of denotes.

4) agree
5) agree

6) yes...there were no 6, I'm adding it :-)
I'm just thinking...for those poor guys who like to publish linked data by
using a reasoned for materializing more facts, but are sometimes scared
about the explosion of facts...shouldn't we put the mappings to semio in a
dedicated mapping module? As I said to Aldo, while I agree on the links to
semio, I don't find practical applications in many cases (I'm not saying it
is worthless though, just not strictly necessary in all the cases), and I'm
thinking about the many many more triples that would be generated...think
this is important when we have to think about the publication of datasets
with respect to our vocabulary.

Cheers,

Armando


> -----Original Message-----
> From: Philipp Cimiano [mailto:cimiano@cit-ec.uni-bielefeld.de]
> Sent: Thursday, July 18, 2013 9:23 AM
> To: public-ontolex@w3.org
> Subject: some minor issues
> 
> Dear all,
> 
>   here are some minor issues that have been raised:
> 
> 1) Glosses of senses (brought up by Guido and supported by Aldo, Armando
and
> Alessandro I think, the Liga Italia so too speak ;-)
> 
> Sure, senses have meanings much as lexical concepts that can be described
via
> a gloss. An of course, we can define lexical relations between senses.
Fully
> agreed and this is compatible with the model. I propose we work the
details out
> in a "lexical semantic networks" module or similar.
> 
> 2) Need for denotes
> 
> We need it. Of course the chain of sense o reference is sufficient, but as
I said
> in many cases people would simply want to say that this lemma means this
> class/property/individual in the context of a given ontology.
> We should make this very simple to people that do not care about sense,
> reference and all that. We need an extremely simple path that is used by
all
> the Linked Data crowd that will laugh at our model (and its technical and
> philosophical / linguistic complexity) anyway. Let us remember that most
> people out there are not aware of the distinctions that we are discussing
here
> for most of the time. We have to be pragmatic here. I agree, it is not
needed,
> but surely practical.
> 
> 3) Linking to SKOS-XL
> 
> I see the possibility of declaring ontolex:Forms as subclassOf
skosxl:Label. Note
> that literalForm is functional, as is ontolex:writtenForm. So I do not see
any
> issues in principle with this.
> However, I do not see a lot of practical gain in this honestly. It would
suggest
> that our model in some sense plays together with SKOS, while in my view,
the
> intersection is actually quite low. As I said, if people are happy with
SKOS, they
> should use it. If they need more than SKOS, they should use the ontolex
model.
> 
>  From a practical point of view, if people have a SKOS model already, they
will
> need to re-engineer their labels anyway, dividing them into proper lemmas,
> inflected forms etc. as all these distinctions are not made in SKOS. So no
matter
> which links we create, there will be no simple way to import SKOS
instances
> into ontolex instances IMHO. The other way is the same. One would need
> heuristics to map written forms of different kinds to prefLabels,
altLabels and
> hiddenLabels for instances as the particular type of label can not be
> underspecified.
> 
> So my proposal is that we simply write convertors between SKOS and lemon
> which make a number of heuristic assumptions but do not formally commit to
> any relation between the models.
> 
> The other question is how to link "Lexical Concepts", which we have
declared to
> be skos:Concepts, to their skosxl:Label. SKOS makes use of three
properties:
> prefLabel, altLabel and hiddenLabel, but there is no way to underspecify
this
> relation in my understanding.
> 
> So we could add a property chain as follows:
> 
> contains^- o sense^- form -> ontolex:label
> 
> where
> 
> skosxl:preflabel -> ontolex:label
> skosxl:altLable -> ontolex:label
> skosxl:hiddenLabel -> ontolex:label
> 
> However, the inferences we get from this are rather limited, because there
> might be in principle other subclasses of labels as well. Does anyone know
how
> to close this in OWL so that only these three properties are subproperties
of
> ontolex:labe? I am not sure how to do it or if it is possible.
> 
> 4) Need of Lexical Concepts
> 
> Lexical Concepts are collections of senses that have a common meaning.
> By introducing this collection as a first-order citizen (a constant) we
can cross-
> link to other resources where such things are first-order citizens as well
(e.g.
> Wordnet were a Synset is a first-order citizen per excellence!).
> 
> 5) Interpreting glosses to generate axioms
> 
> Very interesting, but clearly outside of the model for now. Let's skip
this very
> interesting possibility for now.
> 
> 
> Sorry for the lenghty email. I wanted to summarized the main issues and
> make some proposals, and clarify my own standpoint while doing this
> exercise ;-)
> 
> Talk to you tomorrow, 15:00 (CET).
> 
> P.S. I fear that with this email I have raised more issues than closed,
> but so be it.
> 
> --
> Prof. Dr. Philipp Cimiano
> Semantic Computing Group
> Excellence Cluster - Cognitive Interaction Technology (CITEC)
> University of Bielefeld
> 
> Phone: +49 521 106 12249
> Fax: +49 521 106 12412
> Mail: cimiano@cit-ec.uni-bielefeld.de
> 
> Room H-127
> Morgenbreede 39
> 33615 Bielefeld

Received on Friday, 19 July 2013 11:02:10 UTC