- From: John P. McCrae <jmccrae@cit-ec.uni-bielefeld.de>
- Date: Fri, 23 Jan 2015 15:48:20 +0100
- To: Manuel Fiorelli <manuel.fiorelli@gmail.com>
- Cc: public-ontolex <public-ontolex@w3.org>, Armando Stellato <stellato@info.uniroma2.it>
- Message-ID: <CAC5njqqbQph=3mqVFFe962U9oowpwMOdnLmGsVWhcmUBnZj9Jg@mail.gmail.com>
On Fri, Jan 23, 2015 at 3:17 PM, Manuel Fiorelli <manuel.fiorelli@gmail.com> wrote: > Dear John, All > > see my answer below. > > 2015-01-23 14:59 GMT+01:00 John P. McCrae <jmccrae@cit-ec.uni-bielefeld.de > >: > >> >> On Fri, Jan 23, 2015 at 2:50 PM, Manuel Fiorelli < >> manuel.fiorelli@gmail.com> wrote: >> >> *7. Properties avgNumOfLexicalization, percentage, lexicalizations no >> longer on Lexicalization* >>> >>> This is something that (if I remember correctly) was still under >>> discussion. However, in the attached document I was open to the possibility >>> to include these properties the LexicalizationSet. >>> >>> The change you propose would dramatically change the semantics of the >>> model. Currently, a coverage is only a container of statistics. With your >>> change in place, a coverage would be a dataset, which contains (I presume) >>> the lexicalization triples. >>> >> OK, I think the important thing is that properties such as >> lexicalizations can be added to the Lexicalization, it didn't look like >> that from the diagram >> >> As for changing the semantics, I disagree. The lexicalization is not >> truly a 'dataset' in most cases as it is instead may be published as part >> of a lexicon (or even part of an ontology). Instead it is a dataset in the >> sense that it some set of triples, in this case the triples linking an >> ontology to a lexicon, thus for me a resource coverage is also a dataset, >> that is the set of triples linking a lexicon to a selection of the >> ontology's entities by type. >> > > In the model, we have the following axiom > > lime:LexicalizationSet rdfs:subClass void:Dataset > > therefore, each lexicalizationSet is a dataset, in the sense of being a > set of triples, i.e. representing the association between ontology entities > and lexical entries. > > As you argue, it may be a subset of another dataset. On this last point, > maybe we were a bit ambiguous in previous telcos/emails. Suppose that I > want to distribute an ontolex:Lexicon together with a > lime:LexicalizationSet, what is the appropriate structure of the data? > > a) > > > *The lexicon also contains the triples related to the lexicalizationSet* > :myLexicon a ontolex:Lexicon . > :myLexicon void:subset :myLexicalizationSet . > > :myLexicalizationSet a lime:LexicalizationSet. > > b) > > *The lexicon does not contain the triples related to the lexicalization; > instead, both the lexicon and the lexicalizationSet are part of a larger > dataset.* > > :myDataset a void:Dataset . > :myDataset void:subset :myLexicon . > :myDataset void:subset :myLexicalizationSet . > > :myLexicon a ontolex:Lexicon . > :myLexicalizationSet a lime:LexicaliztionSet. > > > I thought that we agreed on the solution b), in order to completely remove > "semantic" information from the lexicon. What is your position? > I think both solutions are in principle fine but would also prefer (b)... I'm not quite sure about the relevance here. By 'true dataset' I mean a collection of triples grouped together and made available as a single download, the semantics of VoID are much weaker making parts of a single download a dataset as well (although the definition <http://vocab.deri.ie/void#Dataset> of void:Dataset seems to be a 'true dataset') For example VoID's classPartition property, which for me is closely related to lime:coverage, is a subproperty of void:subset, and hence any class partition is thus a void:Dataset. By the same principle I would say that the range of lime:coverage is also a void:Dataset as it is also a partition of the lexicalization. We could even go further and claim lime:coverage ⊑ void:subset! See: http://www.w3.org/TR/void/#class-property-partitions http://vocab.deri.ie/void#classPartition Regards, John > > -- > Manuel Fiorelli >
Received on Friday, 23 January 2015 14:48:48 UTC