Re: [ontolex] Lexicography Module Specification complete and ready for review

Dear all,

We processed all the corrections sent by Ilan, Sander, and Fahad and
updated a new version. Thanks a lot for the useful feedback!

In the following lines, I answer some of the doubts/remarks raised by some
group members:

John> "One comment is that there is a namespace clash between lime:entry
and lexicog:entry, which may cause some confusion. Could we consider
renaming this property to something like dictEntry?"

In fact, introducing lexicog:entry as it was agreed in Leiden, has its pros
and cons. Actually, the optimal solution would be to overload lime:entry
with a new domain and range (LexicographicResource/Entry) but, as far as I
understand, we cannot touch the lemon core and the other consolidated
modules. This is the same reason why we cannot use lime:language and we use
dct:language instead. An additional issue with "dictEntry" is that we are
trying to avoid "dictionary-related" naming.

Fahad> "we should add a describes property between Lexicon and
LexicographicResource (otherwise there is no link between them) -- although
this would mean changing the domain of describes."

We can connect Lexicon to its associated LexicographicResource through
dct:source, thus avoiding changing the semantics of lexicog:describes

Fahad> "inverse property for entry?"

The reason of not having inverse for lexicog:entry is that we "mimic" here
the lime:entry property and lime:entry has no inverse property. However, if
you foresee a use case in which an inverse would be necessary we can
consider it.

Fahad> "Not comfortable with the dictionary's language being specified two
different times... why would the lexicographic resource have different
associated languages from the lexicon?"

Consider, for instance, a single multilingual LexicographicResource (with
several values for dct:language) that is associated to several monolingual
Lexicons (each of them with a single value for lime:language). In that case
the language information will not be the same.

Sander> "I'm no longer sure, however, what the actual use is of the
subComponent relation. Its description suggests it is completely redundant,
and therefore doesn't seem to follow the "rule of thumb" mentioned at the
start of the documentation?"

I agree that this relation is somehow redundant with respect to
rdfs:member. However, some community members wanted to include it
explicitly to cover situations in which you want to state that the
connected super/subcomponents are of lexicographic nature, which you can do
with lexicog:subComponent. In my view, the application of the "rule of
thumb" mentioned at the beginning implies that in many cases (maybe in most
cases) the use of lexicog:subComponent will not be needed. But, in the end,
this is a modelling choice and some people will find it more useful than
others.

Sander> "I also wonder whether it would be good to divide the terminology
over two main sections: "lexicographic" and "lexicon". This would follow
the approach in Figure 1 and would more clearly separate the two
uses/contexts."

We will think how to do this while minimising changes in the report. Maybe
a clearer introduction to figure 1 will help to clarify the
lexicographic/lexicon division.

Sander> "I would still very much like to add a 'usage guide' (as you
suggested earlier, Julia) with examples from lexicographic resources."

Indeed, this is still necessary. One of our agreements was to create a
second report on "guidelines and best practises" to complement the Lexicog
module with more examples and usage advise. Any volunteer to help in
editing the document and coordinating the efforts? Sander? ;-)

Best regards,

Jorge



El mié., 6 feb. 2019 a las 9:57, Sander Stolk (<ssstolk@gmail.com>)
escribió:

> Dear Julia and Jorge,
>
> Thank you for your hard work! I only now got to reading through the
> document.
> It very much reflects our conclusions, and it makes for a very readable
> and cohesive whole.
> Much like Fahad, I mostly came up with typos or odd phrasings. You'll find
> these below.
>
> I'm no longer sure, however, what the actual use is of the subComponent
> relation.
> Its description suggests it is completely redundant, and therefore doesn't
> seem to follow the "rule of thumb" mentioned at the start of the
> documentation?
>
> I also wonder whether it would be good to divide the terminology over two
> main sections: "lexicographic" and "lexicon".
> This would follow the approach in Figure 1 and would more clearly separate
> the two uses/contexts.
> I'd like to hear your thoughts on the matter!
>
> Kind regards,
> Sander
>
> P.S. I would still very much like to add a 'usage guide' (as you suggested
> earlier, Julia) with examples from lexicographic resources.
>
> -------
>
> associated to -> associated with / related to
> comes as a logical step -> is a logical next step
> allow to build -> allow for building / allow us to build   (similar
> patterns elsewhere)
> keep trace -> keep track / trace  (occurs multiple times)
> tranlsations -> translations
>
> EXAMPLE 1 seems to have a redundant extra space preceding the LexicalEntry
> statements?
>
> in a specific ordered and/or a hierarchy. -> in a specific order and/or
> hierarchy
>
> EXAMPLE 2 uses ';' with rdfs:member even though ',' could be used
>           (which would be more in line with previous examples).
>
> EXAMPLE 3 goes slightly amiss with spaces and lack of '.' in the final
> statements.
>           Additionally, perhaps it makes for an easier read to do
> something like the following:
>           :animal_n_comp
>               rdf:_1 :animal_n_sense_1_comp ;
>               rdf:_2 :animal_n_sense_2_comp .
>           (i.e. leave any non-rdf:type statements below the subject rather
> than behind it)
>
> subComponent SubClassOf: rdfs:member   ->  SubPropertyOf
>
>
>
> On Mon, 4 Feb 2019 at 17:58, Fahad Khan <anasfkhan81@gmail.com> wrote:
>
>> Dear Julia/Jorge,
>>
>> Thanks for all of your hard work over the last few months. I've left some
>> comments below, pretty much just pointing out some minor typos that I've
>> found.
>> Cheers,
>> Fahad
>>
>>
>> Section 1.1 2nd Paragraph
>>
>> ...used in the context of the work in...
>> -> ...used in the context of work in...
>>
>> 3rd Paragraph
>> Being interoperability...
>> -> Interoperability being
>>
>> the nature of the lemon model being descriptive but not prescriptive,
>> which facili neutrality towards different lexicographic views
>> ->
>> the nature of the lemon model being descriptive but not prescriptive,
>> which facilitates neutrality towards different lexicographic views
>>
>> Note
>> duplicities -> duplicates
>>
>> Section 2
>>
>> Choose a better name for the Figure 1 caption :)
>> Section 2.1
>> but complement, -> but complements
>>
>> Section 2.3
>> In the diagram + examples we should add a describes property between
>> Lexicon and LexicographicResource (otherwise there is no link between them)
>> -- although this would mean changing the domain of describes.
>>
>> inverse property for entry?
>>
>> Section 2.4
>> Not comfortable with the dictionary's language being specified two
>> different times... why would the lexicographic resource have different
>> associated languages from the lexicon?
>>
>> Section 2.5
>> Example
>> "en&"?
>> Note
>> arrengement -> arrangement
>>
>> Section 2.7
>> 2nd paragraph
>> glassses ->glasses
>>
>>>
>
> --
> Sander Stolk, MSc MA
>


-- 
Jorge Gracia, PhD
Department of Computer Science and Systems Engineering
University of Zaragoza
http://jogracia.url.ph/web/