Re: ontolex.owl

Dear all,

  thanks for all your comments.

A new version of ontolex.owl is on GIT.

Thierry: I corrected the mistake you spotted both on the wiki and in the 
GIT.

Manuel: Inverse of IsEvokedBy is added

Manuel: SKOS vocabulary imported, added LexicalConcept subClassOf 
skos:Concept.

More next week.

Have a good weekend!

Philipp.


Am 27.06.14 14:46, schrieb Manuel Fiorelli:
> Dear Philipp, All
>
> please my answers below.
>
> 2014-06-27 10:37 GMT+02:00 Philipp Cimiano 
> <cimiano@cit-ec.uni-bielefeld.de 
> <mailto:cimiano@cit-ec.uni-bielefeld.de>>:
>
>     Dear Manuel, all,
>
>      see my answers below....
>
>     Am 23.06.14 16:30, schrieb Manuel Fiorelli:
>>     Dear Philipp,
>>
>>     I reviewed the final specification
>>     (http://www.w3.org/community/ontolex/wiki/Final_Model_Specification)
>>     and the OWL ontology
>>     (https://github.com/cimiano/ontolex/blob/master/Ontologies/ontolex.owl),
>>     for what concerns with the core module. The following paragraphs
>>     follows the structure of the final specification; However, I
>>     interweave comments on the OWL ontology as well.
>>
>>     *Comments on the ontology (ontolex.owl):*
>>
>>     The comments on the defined entities are represented as
>>     xsd:string typed literal. In fact, they should be plain literals
>>     (or language tagged literals, in RDF 1.1) with language tag en.
>
>     You are right, a changed the range of all comments to xsd:string
>
>
> In the old RDF parlance, a comment should be a plain literal (without 
> datatype) with a given language tag (in our case "en"). In RDF 1.1, 
> such literals have, in fact, datatype rdf:langString. However, it 
> seems that the XML serialization is able to infer such datatype from 
> the presence of a language tag 
> (http://www.w3.org/TR/rdf-syntax-grammar/#section-literal-node). 
> Therefore, for the sake of compatibility, I would say that a comment 
> should be like this:
>         <rdfs:comment xml:lang="en">The Form class represents one 
> lexical variant of the written representation of a lexical 
> entry.</rdfs:comment>
>
>
>>
>>     *Section "Core*"
>>
>>     In the previous section you associate the ontolex: prefix to the
>>     namespace <http://www.w3.org/ns/lemon/ontolex#>.
>>     However, in the vocabulary description, you use URIs such
>>     as<http://www.w3.org/ns/lemon/ontolex/LexicalEntry>, which
>>     assumes a different namespace <http://www.w3.org/ns/lemon/ontolex/>.
>>
>     OK, I am not sure which namespace we should choose, we should
>     briefly discuss this today.
>
>
> As a starting point, we could consider this: 
> http://www.w3.org/TR/cooluris/#choosing
>
> I just noticed that many popular vocabularies (RDF, RDFS, OWL, ...) 
> use the #, but there are some significant exceptions, such as foaf and 
> dc terms.
>
>>
>>     *Section "Core" / "Forms"*
>>
>>     In the specification of the class Form, you use a qualified
>>     number restriction, while in the ontology you use an ordinary
>>     number restriction. Moreover, the examples following the class
>>     definition don't explain to me, when a form may have two or more
>>     written representations.
>
>     In the ontology I use a qualified number restriction, can you
>     please check again?
>
>
> On github it seems that you use an ordinary number restriction 
> (https://github.com/cimiano/ontolex/blob/master/Ontologies/ontolex.owl#L373).
>
> In fact, I am not sure which form is preferable.
>
>>
>>>     I would be more explicit about the possibility to mix language
>>>     tags: for example, "en" for the Lexicon and "en-GB"/"en-US" for
>>>     morphological variations of a lexical entry. I don't know if it
>>>     is the case to explicitly asserting that you should not have a
>>>     lexicon for english containing a lexical form in French.
>>>
>     In principle all lexical entries in a lexicon should have the same
>     language, but we can not enforce this at the ontology level, so
>     this should be something that we add to the definition of a
>     lexicon, what do you think?
>
>
> I agree with you that some constraints cannot be formalized in OWL. 
> However, I would like to see some mention of this constraint somewhere 
> in the spec (but probably not in the definition itself).
>
>
>>
>>     *Section "Core" / "Lexical Concept"*
>>
>>     In the ontology, there is no axiom relating
>>     ontolex:LexicalConcept to skos:Concept.
>>
>     I had trouble importing the SKOS ontology. Can you maybe help and
>     try to import the SKOS ontology, add the axiom and then create a
>     merge request on GIT?
>
>
> I will try later, this evening.
>
>>     In the ontology, ontolex:isEvokedBy has no inverse property axiom.
>
>     It has, can you check it again?
>
>
> Assuming that the serializer has not scattered the element 
> description, I don't find on github the axiom 
> (https://github.com/cimiano/ontolex/blob/master/Ontologies/ontolex.owl#L160). 
> It may be the case you see an inferred axiom.
>
> -- 
> Manuel Fiorelli

-- 
--
Prof. Dr. Philipp Cimiano
AG Semantic Computing
Exzellenzcluster für Cognitive Interaction Technology (CITEC)
Universität Bielefeld

Tel: +49 521 106 12249
Fax: +49 521 106 6560
Mail: cimiano@cit-ec.uni-bielefeld.de

Office CITEC-2.307
Universitätsstr. 21-25
33615 Bielefeld, NRW
Germany