uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marshall Schor <...@schor.com>
Subject Re: [jira] [Commented] (UIMA-2409) CasCopier.copyCasView should be able to copy into a view with a different name
Date Tue, 18 Jun 2013 20:44:10 GMT
Hmmm, I didn't see this in time...

I would need to think through the implications.  One thing to watch out for -
the copyCasView is used as a subroutine for the full cas copy - which iterates
over all views calling this.  The full cas copy should be a faithful copy - so
this would need thinking through.

I'm tempted though to move on, unless there's some issues that come up.

(I look forward to others testing / wringing-out-the-bugs :-) )

-Marshall

On 6/18/2013 2:18 PM, Richard Eckart de Castilho wrote:
> I think a conservative approach may be wise. Just copy the source view
> to the target view and not create any cross-linked views. Either throw
> an error when data is cross-linked, or just leave the linking features
> empty (null).
>
> I think feature for copying cross-lnks would be worth an additional feature
> request. If linked features be copied to the target CAS (we are no longer
> talking about view-to-view copying here), then it should be controllable.
> E.g. the user should be able to provide the CasCopier with a callback that
> can decide if a particular link (across a view boundary) should be followed
> or not.
>
> I believe the use-cases we have right now are:
>
> 1) copy view X from Base-CAS A to Base-CAS B
> 2) copy view X to view Y in same Base-CAS
>
> I'd suggest to not do more than exactly that.
>
> -- Richard
>
> Am 18.06.2013 um 19:26 schrieb Marshall Schor <msa@schor.com>:
>
>> An edge case involving cross-view references:
>>
>> Each AnnotationBaseFS (or subtype) holds a reference to the SofaFS it is an
>> annotation over.
>>
>> Although these annotations may only be indexed in the view having the sofa they
>> are annotations over, it is possible that Instances of these may be referenced
>> in other views (cross-view linking).
>>
>> When just one "view" is copied, these references end up referring to SofaFS
>> representing other views.  The current copier implementation is to get/create
>> these views in the target.  The sofas, if created, have no Sofa Data.   This is
>> one thing that could be changed: we could honor the boolean flag, aCopySofa, in
>> the API which controls whether or not the top level sofa for the view being
>> copied, has its data copied. 
>>
>> When doing a view copy to another view with a different name, I think the
>> implementation needs to
>>  - check if the view associated in the source is the view being copied, and if so,
>>      - it should use the new target view.
>>  - if the view is not the same as the source being copied, then we could either
>> throw an exception, or silent/under-the-covers, create this additional view
>> (with the same name as in the source) in the target.  An ambiguity might occur
>> if the source's view name just happened to match the new target view name, I
>> suppose, but normally, this would result in additional views (other than the one
>> specified) being created as a side effect of copyCasView.  My suggestion is to
>> not throw an exception, but just to go ahead and create (or reuse) the
>> samed-named views in this case.  My rational is that this is an unlikely case in
>> the first place (it requires an advanced concept - cross-view linking), and so
>> accidental occurrences should be rare; it also has potentially some benefits -
>> allowing cas view copying in these cases, where it's probably unlikely the user
>> would even be referencing these cross-view links.   Also, for this case we have
>> the same issue of not setting in the destination CAS the sofa data that might be
>> present for these other views.
>>
>> I plan to follow the current impl in *not* copying the sofa data for any new
>> views we might create via cross linking.  If a user wanted these, they can
>> always set the sofa data explicitly from the other CAS (a manual copy); but I
>> think it's unlikely they's  be wanted.
>>
>> -----------
>> A similar special case exists for the DocumentAnnotation - there can be 0 or 1
>> of these per view in the CAS.  But other FSs (perhaps in other views) can hold
>> references to this FS (cross linking).  The same kind of view-switching (if the
>> source view is the view being copied, use the target view name instead) would be
>> used for this.
>>
>> WDYT?
>>
>> -Marshall
>>
>


Mime
View raw message