RE: Ontolex/Lime: minutes of last meetings and some updates

Dear John, all,

 

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.

One of the specific issues here is that it would be good to have an "ontolex-all" ontology, and thus we should avoid any inter-module name classes. Perhaps though the solution is to use the Dublin Core property and add appropriate axioms to the definition of Lexicalization/Lexicon, (Lexicalization ⊑ ∃ dc:language.String)

 

[Armando Stellato] 

No strong opposition here, Manuel too confirmed any change here is ok; we just decided to leave the examples as they were, until a different choice was definitely agreed. Though, I must say, the more I see a similar property in other vocabularies, the more I’m convinced it makes sense to have a dedicated property, with its domain and range. It is not that we must constrain Lexicalization to have the lang property (though I would do that too), it is that actually I see better to have a dedicated property (with a certain intension), to be clarified and “domained” to Lexicalization.

However, the intension of dc:language is wide enough exactly because it could be used in different contexts, so…the ones above are my thoughts, but dc:language is absolutely fine.

 

 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.

My principal concern is the ambiguity as lexicons are also datasets... the name of the group is OntoLex what is the problem of not just use the term ontology to refer to what we are lexicalizing (even if some of the targets may not be true ontologies)?

 

[Armando Stellato] 

mmm…here I’m more convinced for dataset. The name “ontolex” has a very long history, it was also the name of the very first series of workshop on these matters, dating back 10 years ago. On the other side, ontology is an ambiguous term. In Dlogics, we have a clear separation between terminology and assertion boxes, in some ontology literature, you may find “Knowledge Base” in opposition to ontology, where kb is the data, and ontology is the schema. In some other ontology literature (already in the OWL / DL intention of the word, but before the advent of linked data), ontology is just any dataset (before the term was re-coined in this scope), which may be then separated in terminology and assertions. It much depended on what the authors have “breathed” in their research life and what is easier for them to address in their papers. Not to speak about the term (owl) vocabulary, which came out to clarify something unambiguously as a scheme, and which is often redundantly strengthened as “ontology vocabulary”, to avoid further ambiguities with other kind of vocabularies.

 

So, summing up, in this lot of chaos, at least for historical reasons, I would say the name ontolex is sacred :-) but when it comes to a specific property, I would rather be stick with using a somewhat approved and shared terminology. I’m not dogmatic into this neither…just more convinced.

 

 

 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.

Shall we not follow VoID here and call the object a "partition"? 

 

[Armando Stellato] 

I wouldn’t, because in VoID you may address a partition as a whole new dataset description, just addressing the fact that its content is a partition of another one (in general, the main dataset being described in the file). In lime, the focus is not on the partition itself (we don’t add any more descriptions about it), but on how that certain partition has been lexicalized. 

 

Cheers,

 

Armando