Re: synsem module ready

Hi Manuel,

  reading the thread between you and John, it seems to me that most 
issues have been addressed / solved.

The only open points seems to be:

1) Example 8 uses isA but should be made clearer.

2) In the definition you use the words "subjects" and "objects" at 
plural: not sure, if it more appropriate to use the singular form.

3) I fear that the use of the inverseOf construct could be not very 
readable. A simpler solution could be simply use "fatherOf", although I 
suspect that this name does not conform with current best practices.

Talk to you tomorrow,

Philipp.



Am 18.05.15 um 16:06 schrieb Manuel Fiorelli:
> Hi John,
>
> please read my answers below.
>
> 2015-05-18 15:50 GMT+02:00 John P. McCrae 
> <jmccrae@cit-ec.uni-bielefeld.de 
> <mailto:jmccrae@cit-ec.uni-bielefeld.de>>:
>
>
>
>     On Mon, May 18, 2015 at 10:41 AM, Manuel Fiorelli
>     <manuel.fiorelli@gmail.com <mailto:manuel.fiorelli@gmail.com>> wrote:
>
>         There is no example (just below the definition of
>         synsem:isA)about the representation of unary predicates. Nor
>         is there any example about the representation of individuals.
>
>     Example 8 uses isA... but perhaps we should make this clearer
>
>
> I would suggest a preliminary example, and then clarify the role of 
> isA in example 8.
>
>
>         The definitions of synsem:{subj|obj}OfProp use the following
>         wording:
>         "...property represents the semantic argument with represents"
>
>
> In the definition you use the words "subjects" and "objects" at 
> plural: not sure, if it more appropriate to use the singular form.
>
>
>         Just below Example synsem/example7, there is an example
>         involving the property father: the property should point to
>         the child; however, the name of the property suggests to me
>         that the object is the father (just in the same manner
>         skos:broader points to the broader of a given concept).
>
>     I agree, fixed
>
>
> I fear that the use of the inverseOf construct could be not very 
> readable. A simpler solution could be simply use "fatherOf", although 
> I suspect that this name does not conform with current best practices.
>
>         I think that Example synsem/example9  should be explained in
>         more detail.
>
>     Removed (it does not concern OntoLex)
>
>
> :-D
>
>
>         I didn't find the definition of synsem:propertyDomain and
>         synsem:propertyRange; then, I realized that they were moved to
>         the core module. The diagram of the core module must be
>         updated to include these properties, as well as the diagram of
>         the synsem module to remove them.
>
>         I noticed that in the infobox providing the definition of
>         propertyRange and propertyDomain, the URI still uses the
>         synsem namespace instead of the core ontolex namespace.
>
>
>     Yeah thinking about it makes absolutely no sense to have
>     propertyRange and propertyDomain in the core, for the very simple
>     reason: how can you restrict the range/domain of arguments when
>     you can't define whether there are arguments in the first place!?
>     There is also a technical dependency as the domain of
>     propertyRange and propertyDomain should be synsem:SemanticFrame.
>     As such, I have made the unilateral decision to restore condition,
>     propertyRange and propertyDomain to the synsem module and to
>     introduce them all as subproperties of ontolex:usage.
>
>
> I think that the problem you describe is analogous to the problem we 
> had with the domain of ontolex:language, and the solution you applied 
> seems good to me.
>
> -- 
> 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