Re: LIME Final Model

Yep, I agree I just couldn't put the axiom on the diagram.

The range of partition is thus LexicalizationSet or LexicalLinkSet, right?

Regards,
John

On Fri, Jan 30, 2015 at 12:15 PM, Armando Stellato <
stellato@info.uniroma2.it> wrote:

> 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> 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
>
>
>