OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

lexidma message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [lexidma] follow up on two-level senses

Hi John,

On Tue, 7 Jul 2020 at 14:18, John P. McCrae <john@mccr.ae> wrote:

Yes, I don't see that contradicting anything I've said. Perhaps a more appropriate term to be used from the computer science perspective is an equivalence relation here, but that doesn't matter and to ease understanding I stick to "similarity", however it is defined and whether it is seen as a binaryÂrelation or a real-valued metric.
Actually, my point was that this is not that this is a kind of similarity but that there is a linguistic test that can be used to distinguish subsenses from 'true' (i.e., contrastive) senses.ÂÂ

Sure, I got it -- but there is no such test that linguists or lexicographers would largely agree on. None of the theories you mention is unique or dominant in any way.

(5) this alternative solution therefore enables all this, and much more, if needed, without introducing additional complexity.

I think that the labels generally could use a similar notation that David mentioned for PoS tagging, with prefix denoting type of label, e.g. "sensegroup:1" or "sensegroup:etymology1" and similar but that is to be discussed.
From a technical point of view, there are also disadvantages to this. You are still encoding hierarchical senses, but now you are doing it in a way that is harder to work with in XPath and many other technologies, which in turn makes it harder for data creators to verify consistency.Â

I would suggest that this is implemented as an optional sense grouping tag, e.g,

 <sense id="..."><defn></defn></sense>
 <sense id="..."><defn></defn></sense>

It would be great if we could avoid any kind of XML thinking in our discussions: we propose a data model. XML will be just one of several serializations for it and once we establish the model we will thenÂdiscuss the XML serialization,Âor even XML serializations (i.e. more than one).
Sure, but your modelling seems to suggest an XML attribute or an RDF datatype property.

Ah, nah, it is a plain (very:-) old ER diagram, it shall not suggest anything like that.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]