Re: LIME proposal for the OntoLex W3C Community Group

Hi,

So this troubles me:


> The values for most of these values could be calculated using SPARQL
> construct statements it seems in the sense that some information is
> aggregated and added as explicit value of some lime property. Fair enough,
> it saves people the effort to run the SPARQL queries over the dataset
> themselves, making this information readily accessible.


The point of metadata is not to optimize commonly run SPARQL queries, for
two primary reasons, firstly it bulks up the model and instances of the
model with triples for these 'pre-compiled' queries and secondly it is very
hard to predict what queries an end-user will want to run. It seems that
the kind of metadata we are proposing to model is nearly entirely
pre-compiled queries, and are of questionable practical application. That
is, I ask a simple question: *if we can achieve resource interoperability
for OntoLex already with SPARQL why the heck do we need metadata anyway??*

As such, I have been reading a few papers and trying to figure out what
metadata we can reasonably expect most users of the model to use. In
particular, following this
paper<http://www.niso.org/publications/press/UnderstandingMetadata.pdf>,
I propose a list of metadata 'desiderata' and divide them into three
categories:

   - *Descriptive Metadata*
      - Name*
      - Author(s)*
      - Size (Entry count, Sense count, Reference count etc.)
   - *Structural Metadata*
      - Which Linguistic Description Ontology is used
      - Module coverage. e.g., Does this resource have syn-sem modelling
   - *Administrative Metadata*
      - When published*
      - Where published*
      - Formats*
      - SPARQL endpoint*
      - Previous version*

* The vocabulary already exists, e.g., Dublin Core, VoID

This list above are things that are vital for understanding a resource and
which in most cases cannot be inferred from examining the dataset alone,
and the rest especially entry counts are useful for resource repositories
such as DataHub.

Regards,
John


On Sat, Mar 8, 2014 at 5:06 AM, Armando Stellato
<stellato@info.uniroma2.it>wrote:

>  Dear Philipp, John, all,
>
> Yes, absolutely agree that we should provide the SPARQL constructs, as an
> operational way to express their semantics. I think we already have them,
> as Manuel has written them in a LIME exporter component (we should just
> readjust the output according to the structure we want to build..see
> previous emails).
> Regarding the fact that the metadata should be obtainable from the data
> present in the content, in general I agree, and the general idea is that
> those sort of linksets could be subset of different datasets and thus
> appear in the most appropriate void file (from the case of three distinct
> datasets up to the case in which ontology, lexicon and lexicalization
> collapse into one dataset, yet with the lexicalization being identifiable
> at the metadata level as a specific subset of the whole).
> Yet, to strictly respect your rule, a problematic case is: providing that
> it is important to express the lexical coverage for resource R (for Rs
> belonging to an ontology) and that this requires to be able to enumerate
> the instances of R, this amounts to say that, in the case of a separated
> lexicon and ontology, the metadata should be in the void of the lexicon,
> and thus, to iterate Rs, the lexicon should necessarily owl:import the
> ontology, or the data from onto would not be available and this would break
> your rule for which the metadata should be always calculable in terms of
> available data.
>
> I think our view here is pretty simple:
> we consider the triad: <ontology, lexicon, lexicalization>. In this triad,
> ontology and lexicon may happen to be independent, but the lexicalization
> will always have (at least conceptually) a known dependency to the content
> of the other two (I.e. whoever wrote the lexicalization, did it with the
> target ontology and chosen lexicon at hand). Thus I think it should be in
> any case legal that the metadata about the lexicalization is able to tell
> which percentage of (all) the Rs from the ontology is covered by the
> lexicalization.
>
> Would that work?
>
> Cheers,
>
> Armando
>
>
>
>
>  ------------------------------
> Da: Philipp Cimiano <cimiano@cit-ec.uni-bielefeld.de>
> Inviato: ‎07/‎03/‎2014 22.43
> A: Armando Stellato <stellato@info.uniroma2.it>; 'John McCrae'<jmccrae@cit-ec.uni-bielefeld.de>
> Cc: 'Manuel Fiorelli' <fiorelli@info.uniroma2.it>; public-ontolex@w3.org
> Oggetto: Re: LIME proposal for the OntoLex W3C Community Group
>
> Dear Armando, all,
>
>  second email on the metadata, referring in particular to the aggregating
> properties.
>
> Many of the properties that we are proposing in the metadata module are
> aggregating properties: number of lexical entries, average number of
> lexical entries etc.
>
> We sort of agreed that these are computed locally for the dataset in
> question without consulting external lexica etc. right?
>
>
>
> However, in order to properly document the semantics of the lime poperties
> we introduce, would it not be feasible to indicate a SPARQL construct query
> that computes the property value? In that sense we would clearly define the
> semantics of these metadata properties.
>
> What do you think?
>
> Philipp.
>
>
> Am 06.03.14 20:17, schrieb Armando Stellato:
>
>  Dear Philipp and John,
>
>
>
> no need to say sorry, you are coordinating a whole community group, we
> cannot say the same on our side, yet we are no quicker than you in replying
> :D
>
>
>
> You raise an important point, the solution of which actually raises up an
> interesting opportunity for other important aspects of at the level of the
> web architecture of Ontolex.
>
>
>
> Before we delve further into the details, let us ask one more question:
>
>
>
> What is the relationship between ontologies and the lexica, is it 1:n (an
> ontology may have multiple lexica) or m:n (as before, plus the same lexicon
> may be connected to multiple ontologies) ?. A strictly related question is:
> “is a lexicon built specifically for an ontology?”.
>
> Having ported WordNet in Ontolex should already give the answer to that
> (WordNet exists a-priori from any ontology, and thus it should be one
> example in favor of the m:n hypothesis, though we may think of a Lexicon as
> something importing WordNet and extending it for being a lexicon for a
> given ontology).
>
>
>
> In case the m:n hypothesis is confirmed, we should think about some form
> of binding, as a third object implementing the connection between an
> independent lexicon and an ontology.
>
>
>
> I think I already asked something related to that when I had some doubts
> about how to deal with compound terms: if a lexicon exists independently,
> it will probably not contain some compounds needed to describe resources of
> the ontology, so we cannot assume these should be always available (at the
> time of my question, I remember I was told: “for things like “red car”, you
> should foresee a dedicated entry in the lexicon, though it can then be
> decomposed through the decomposition module”, thus implying that the
> lexicon has to exist FOR a given ontology.
>
>
>
> Probably I’m missing something here, but I think these are fundamental
> aspects which should be made clear in the wiki pages about the overall
> architecture and the usage of the model.
>
>
>
> Ok, sorry for the long introduction, but how you will see, it is related
> to our topic…we however maybe managed to handle this independently of the
> above. So, back to the topic…
>
>  …Our model relates to a void file, but this file could be, for instance,
> not the void file of an ontology, but the void file of (something similar
> to) a void:linkset which binds a lexicon to an ontology. To cover also the
> need you express at the end of the email, we could propose the following
> changes:
>
>
>
> <!--[if !supportLists]-->1)      <!--[endif]-->A lime:lexicon property,
>
> <!--[if !supportLists]-->a.       <!--[endif]-->domain:
> lime:LanguageCoverage (the class obviously)
>
> <!--[if !supportLists]-->b.      <!--[endif]-->range:     void:Dataset
> (or an appropriate subclass lime:Lexicon to define a dataset which contains
> linguistic expressions for some dataset. Note that a void:Dataset
> containing both conceptual and lexical info would be the lexicon of itself!
>
> <!--[if !supportLists]-->2)      <!--[endif]-->lime:lexicalModel (old
> linguisticModel, moved to having domain set to languageConverage)
>
>
>
> so we could have a structure like that:
>
>
>
> void:Dataset  --lime:languageCoverage--> lime:LanguageCoverage
> --lime:lexicon--> void:Dataset
>
>
> --lime:lexicalModel--> (rdfs:, skos:, skosxl:, ontolex: )
>
>
> --lime:resourceCoverage--> (usual stat info)
>
>
>
> But then, we would have another issue…what is a lexicon? If a lexicon is
> something independent of the “enrichment” of an ontology with respect to a
> language, and lives on its own, then, here, in our case, we are more
> interested in knowing the third element we were mentioning above, that is,
> the “man in the middle” providing links between a conceptual resource and a
> lexicon. Thus, with just a terminological change, (lexicon -->
> lexicalization), and relying on the fact that this representation delegates
> to the lexicalization the pointers to the lexicon:
>
>
>
> void:Dataset --lime:languageCoverage--> lime:Lan
>
>
> [il messaggio originale non è incluso]
>