Serialization API appears not to be in line with LAPPS Type Hierarchy.

[reckart]

All the methods work on the level of Annotation and the Annotation type in the serialization API always has start and end offsets. However, the Annotation type in the LAPPS Type Hierarchy doesn't have that. Offsets are only introduced in the Region type.

[ksuderman]

Yes, there is not (yet) a one-to-one correspondence between the types in the serialization API and the LAPPS type hierarchy. There are a couple of reasons for this:

1. We tend to update the type hierarchy more frequently and faster than the serialization API. For example, Region is a relatively recent addition.
2. We want to keep the number of classes in the serialization API as small as possible and only add/break things in the code once the type hierarchy is more or less stable.

The idea (good or bad) is that the Annotation class can do all the heavy lifting even if it means it carries around some baggage it doesn't need (e.g. start/end offsets). This way when someone comes up with a new annotation type there is no need to introduce a new class into the API.

[reckart]

I understand. I just kind of stumbled other that as an afterthought because in DKPro Core, Constituents and Dependencies have offsets and when I converted these types to LIF, I also added the offsets - only then I realized that the LAPPS Type Hierarchy doesn't define offsets on these types.

[reckart]

Hm. Now I have tried creating constituent and dependency annotations without offsets, but this doesn't give the desired result in the serialization:

Expected:

{
      "id" : "dep-1",
      "@type" : "http://vocab.lappsgrid.org/Dependency",
      "label" : "attr",
      "features" : {
        "governor" : "tok-2",
        "dependent" : "tok-1"
      }
}

Actual:

{
      "id" : "dep-1",
      "start" : -1,
      "end" : -1,
      "@type" : "http://vocab.lappsgrid.org/Dependency",
      "label" : "attr",
      "features" : {
        "governor" : "tok-2",
        "dependent" : "tok-1"
      }
}

[reckart]

Opened a separate issue for the last comment: #17

[ksuderman]

Thanks, #17 is definitely a bug.

It might be a good idea to get @marcverhagen and @nancyide involved here, but the LAPPS Type Hierarchy is meant to represent what we (LAPPS services) expect at a minimum in a JSON-LD document. Including more is not an error it just means the data may not be propagated as expected. For example, we won't (shouldn't) throw an error if you include start/end offsets on a Dependency, but those offsets may not be there after a round-trip.

[reckart]

Is it an official LAPPS policy that unknown content is not guaranteed to be preserved?

[ksuderman]

No, I misspoke.

Unknown content should be preserved, it just may not be understood. If you include start/end offsets with your Dependencies those should always be there after a round-trip, but the offsets may not be included in the output of a LAPPS service that processes your dependencies.