Ontolex/Lime: minutes of last meetings and some updates

Dear all,

 

since we'll be working via email in these weeks, just a quick minute of what
has been said at the last call (in particular, what is pending decision),
and then one updates and.request for opinions on open aspects:

 

As a general observation, we are at a good point. In the last call wee
agreed on the overall structure, and also agreed on which part of the
terminology can be improved.

 

As for the last time, instead of presenting the model, I present a small
example of its use, as it is shorter to be shown and more intuitive to be
followed:

 

/** inside the void file of the Lexicalization

myItLex:myItalianLexicalizationOfDat

  a lime:Lexicalization;

  lime:lang "it";  // important to be here, this is the focus of search by
agents!!! Not the lexicon!

  lime:lexicalizedDataset :dat ;

  lime:lexicalModel ontolex: ;  
  lime:lexicon :italianWordnet;
  lime:resourceCoverage [   // see discussion later in sections 5
    lime:class owl:Class;
    lime:percentage .;
    lime:avgNumOfEntries .
  ].

 

We already agreed in previous calls to leave aside discussion on the
percentages/averages vs counts as the last thing so, obviously, these two
properties:

    lime:percentage .;
    lime:avgNumOfEntries .

may change also depending on which values they will host.

 

lime:lang has already been agreed which can be replaced with some
ontolex:lang. Actually, the general trend is to reinvent a lang property
(exactly, by changing only the namespace) for each vocabulary, so to
identify its specific use. So, for instance, dcat has its own one, with its
dedicated domain and range, and so we could, by setting up domain of
lime:lang to lime:Lexicalizaton. Apart from that, I've no strong objection
against reusing another one.

 

lime:lexicalizedDataset: we more or less agreed on its name, providing that
the term Dataset was proven to be including ontology vocabularies. In the
meanwhile I did check on some mailing lists, and the reply from Richard
Cyganiak (one of the authors of void) is affirmative: Dataset does include
ontology vocabularies. This is his reply on the LOD ml:
http://lists.w3.org/Archives/Public/public-lod/2014Jul/0012.html

Note: I think there was also a proposal (maybe from Philipp) to use
targetDataset. Not sure which one won, however, targetDataset is for me fine
as well: more, if we have a Lexicalization, it *almost* immediately follows
that its target is the dataset to be lexicalized, so maybe even nicer to use
targetDataset. The only formal opposition to that would be that a Lexicon is
a dataset too, and a lexicalization exactly binds a Lexicon and a Dataset to
be lexicalized, so targetDataset would be slightly ambiguous.

 

lime:resourceCoverage: we agreed on its structure: it allows to factorize
all the elements of a lexicalization in a single point (the Lexicalization
object) and then have multiple partitions identified by it. However, we also
agree that we may try to look for a better name :-) Suggestions?

Actually this may be depending on that final decision on
percentages/averages vs counts. resourceCoverage is evoked in my mind
(though may be changed as well) if, like in this example, we have
percentages/averages. With counts, I would be ever more tempted to look for
something else.

 

Oh, one last thing, which was left over from discussion: LexicalLinkSets.

I get back an example from a previous email: suppose that I'm (implicitly)
lexicalizing an ontology by writing links between LexicalConcepts of WordNet
(synsets) and the resources of the ontology. We thus have links between
semantic entities on both sides (Lexicon and Dataset) so this cannot be
expressed through a Lexicalization object (unless we want to count the
non-OWL inferable lexical derivations of this semantic linking). So, we have
the properties in ontolex core for that and I assume thus this is relevant
for our model, and then probably it would be important to tell it somehow in
the metadata. That's where I suggested this lime:LexicalLinkSet as a
subclass of void:LinkSet.

 

Think that's all,

 

Armando