define a MMIF format for structure parsing results

[keighrim]

New Feature Summary

As we're approaching an app version of RFB (https://github.com/clamsproject/app-role-filler-binder-old/issues/8, and https://github.com/clamsproject/app-role-filler-binder-new , we want to decide the MMIF format for structure parsing results such as the RFB app. This issue is for discussion to decide the representation, including what annotation types and their properties to use.

Related

No response

Alternatives

No response

Additional context

No response

[marcverhagen]

Some notes on this with some options, after a discussion with @keighrim.

The JSON option

Similar to having a CSV hidden in a MMIF property we could allow arbitrary JSON, either real JSON or in its string representations. I do like the freedom to be able to do that, and as long as individual apps that create this kind of output do document this well it certainly does not violate any MMIF directive. But it completely bypasses our general approach to use the vocabulary to impose clear and documented structure to MMIF output. A JSON-based solution will have the flavor of an ad hoc solution and probably remain obscure.

Currently available annotation types

Candidates are:

• https://mmif.clams.ai/vocabulary/Relation/v4/.
• https://mmif.clams.ai/vocabulary/Span/v4/.
• http://vocab.lappsgrid.org/NamedEntity.html.
• http://vocab.lappsgrid.org/Relation.html.
• http://vocab.lappsgrid.org/GenericRelation.html.
• SemanticTag. Proposed but never added to the LAPPS Vocabulary.

The Relation types are typically under-specified or a bit clunky for our purposes. For example, GenericRelation has a head and a list of arguments, which does not feel appropriate. The Span type and its subtypes like Token are generated by the OCR app and can potentially be referred to. The NamedEntity type seems useful and is used below.

That what was on the whiteboard

Scribbled down there by Keigh on May 15th. Also included in the notes and scratchpad document for the CLAMS Tech meeting. Basically:

{
	"@type": "NamedEntity",
	"properties": {
		"label": "role",
		"targets" : ["some-token-id-from-doctr", ...],
		"normalized-form" : "director" }
}

{
	"@type": "NamedEntity",
	"properties": {
		"label": "filler",
		"targets" : ["some-other-token-id-from-doctr", ...],
		"text" : "1/1/96" }
}

This uses an existing annotation type, but the use of the label property is odd.

Using SemanticTag

{
	"@type": "NamedEntity",
	"properties": {
		"id": "ne12",
		"category": "Person",
		"start" : 18,
		"end": 27 }
}

{
	"@type": "SemanticTag",
	"properties": {
		"label": "director",
		"targets" : ["ne12"] }
}

You could also introduce a subtype Role of SemanticTag and define what role labels are available. This is fairly simple and works well for many cases. However, things become uncomfortable when you look at cases like "X is Directory of Y". To deal with Y you need to add another property that probable refers to the NamedEntity type for Y. But that introduces a non-standard way of adding a relation and complicates what a SemanticTag is.

Using a generic type for key-value pairs

Named KeyValuePair or KeyValue or KeyedInformation.

{
	"@type": "KeyedInformation",
	"properties": {
		"role": "director" }
}

It would need more than just the one property though.

Using some kind of relation

Using a new relation type and consider a role to be a relation between two named entities.

{
	"@type": "NamedEntity",
	"properties": {
		"id": "ne12",
		"category": "Person",
		"start" : 18,
		"end": 27 }
}

{
	"@type": "NamedEntity",
	"properties": {
		"id": "ne13",
		"category": "Organization",
		"start" : 34,
		"end": 48 }
}

{
	"@type": "Role",
	"properties": {
		"label": "director",
		"person" : "ne12",
		"organization": "ne13" }
}

This deals directly with the "X is Director of Y" example. If the organization is not expressed you can just keep it underspecified:

{
	"@type": "Role",
	"properties": {
		"label": "director",
		"person" : "ne12",
		"organization": null }
}

The label is the canocical name of the role, possible values can be documented on the annotation type.

There is unease with the person and organization properties because they seem too restrictive. Other options are source/target and arg1/arg2, both too generic. Yet another option is the use targets or arguments, which leaves us with the issue of how to specify the order. Using filler instead of person/arg1 might work. Good names are needed.

An even more complicated example: "Joe, sales at company X".

Schematically this is:

• NamedEntity(Joe) member-of Organization(sales)
• Organization(sales) part-of Organization(company X)

We can only deal with this fully if we have a part-of relation. Alternatively we could just bundle the organizations and then we are done:

• NamedEntity(Joe) member-of Organization(sales at company X)

Note the difference between "X is Director of Y" and "Joe, sales at company X". In the former the name of the role is expressed in the text, which does not happen in the latter. And in the former case we do not express that the token "Director" is involved in the relation at all. We may or may not care about that but if we do we can somehow use an old TimeML property for temporal relations named Signal, which pointed at textual evidence for a temporal relations (for example "before" in "she left before noon").