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
>