R: LIME Final Model

Hi John,

 

Thanks for the resume, and fine with everything, except that partition does not point merely to the original class.

We should restrict LexicalizationSet and LexicalLinkSet this way:

 

LexicalizationSet ⊑ ∀ partition.( LexicalizationSet ⊓ =1.resourceType)



The only difference was that we do not give this Restriction a URI, as it will never really be used as a Name.

 

Cheers,

 

Armando

 

P.S: we will reply soon to the other email about conceptualizations, but we will probably not make it in time by today

 

 

 

Da: johnmccrae@gmail.com [mailto:johnmccrae@gmail.com] Per conto di John P. McCrae
Inviato: venerdì 30 gennaio 2015 11:18
A: Armando Stellato
Cc: public-ontolex
Oggetto: Re: LIME Final Model

 

OK, so I see that we roughly agree, so to summarize

1. The class ResourceCoverage is removed, and replaced with a partition, which is just a lexicalization set or lexical link set
2. The property coverage is now renamed partition, its range is now LexicalizationSet or LexicalLinkSet (range should match domain)
3. We keep resourceType property and it can now be attached to either the LexicalizationSet or LexicalLinkSet

I have attached an updated diagram summarizing this:

Regards,

John

 

On Thu, Jan 29, 2015 at 7:34 PM, Armando Stellato <stellato@info.uniroma2.it <mailto:stellato@info.uniroma2.it> > wrote:

Dear John,

.       Class for the “coverage”. It’s not clear to us what’s your final decision on the use of a named class for it. You said you agreed on removing the named class to save URIs (“fewer URIs always better”) so we would say it’s ok to just use an anonymous class for the restriction, like we proposed: 
LexicalizationSet ⊑ ∀ <?coverage?>.( LexicalizationSet ⊓ =1 <?typeProperty?>)
but then you suggest (“I would do as follows”) again: LexicalizationSet ⊑ ∀ <?coverage?>.(LexicalizationSet ⊓ ResourceCoverage) where ResourceCoverage represents our same restriction on the <?typeProperty?>. 
Our considerations here in favor of not giving it a name:

                                                               i.      VoID does the same for its partitions. It defines the various xxxPartition props but then simply points to a Dataset which is implied being a subset of the above.

                                                             ii.      In any case, the name ResourceCoverage is, after the move to the subset approach that we agreed, inappropriate. Indeed, it was a coverage before, because it described particular coverages of the dataset it was attached too. Now, the coverage statistics are directly attached to the LexicalizationSet (LexicalLinkSet etc..) so all LexicalizationSets are already expressing coverages and, as yourself said, what we are adding now is only the possibility to partition these sets. So, should we call it Partition? I would go back to the considerations in point i. then.

Ah... I meant remove the specific subclasses LexicalizationCoverage and LinkSetCoverage.... removing the parent class ResourceCoverage is also an option. I am ambivalent about this, it removes a definition from the model, which is good, but it also makes the usage a little less clear.

 

 

As said before, in case we retain the idea of having names for those partitions, the name should definitely be changed (as the coverage is present even in any LexicalizationSet/LexicalLinkSet).

But frankly, in terms of ease of use, I think it’s exactly the use that drives simplicity, and not the model. If you go along the VoID references (which do not give names to these partition classes), you will see just these bnodes representing the partitions, used with the additional required properties, such as void:class, and there is no need for specifying a class for them (indeed there is no rdf:type statement as VoID provides no class for them). 

Intuitively, it is the chaining from the void:xxxPartition properties which evokes the idea of putting on them the additional properties required by a partition, so in this case the axiomatization with the unnamed restriction just saves you one URI which you would never use.

I would really follow the same approach in Ontolex/Lime.

 

 

b.      Property: <?coverage?>. Same as for point ii. above. “coverage” is not appropriate as now it merely describes a partition. We agreed void:classPartition is not appropriate so, a few possibilities:

                                                               i.      lime:classPartition. I (Armando) personally like the idea of using a same (local)name with a related though slightly different semantics. The reason is: it is easy to remember, and you are actually using it much probably in place of the other when using lime. The fact that the full name is formally different (lime:classPartition is not formally related to void:classPartition) completes (in my view) the approach.

                                                             ii.      lime:partition. Ok with such a name, we are losing here the possibility to do other kind of partitioning. Would it be a serious loss? After all, we still have the void partitions for them, while for our needs probably this is the only kind of partitioning we need

I would prefer partition, as it is shorter and we can do other kind of partitioning (in contrast to your claim)... this is as we assume that the partitioning is not by 'classes' in the ontological sense, but by the value of the rdf:type triple, e.g., when we have resourceType=rdfs:Property for example we select all properties. 

See lime/example5 in the final spec <https://www.w3.org/community/ontolex/wiki/Final_Model_Specification#Lexicalization> 

 

 

I’ve seen the examples, but to me this is still a class partition :-D (whether you partition on a class, such as Country, or a “metaclass” such as owl:Class). What we were saying is that just “partition” is a big hat over the specific case of partitioning over classes only (still under the wider interpretation that we share, and not under the VoID one which limits to triples having instances of that class as the subject).

In any case, fine for us to call it partition, we don’t really see other cases.

 

c.       <?typeProperty?>. we can live with lime:resourceType, however after this shift, again we might reconsider:

                                                               i.      lime:class which better evokes the analogy with the (more general) partitioning of void (same consideration as for lime:classPartition).

Let's live with resourceType for the same reason as above.

 

Call it a sense of aesthetics or “feeling a disturbance in the Force” :-) but just that name seems sooooo long giving the context that it has around which already clarifies its scope.

Anyway, if you really prefer it, ok let’s go with it.

 

Cheers,

 

Armando