This HTML5 document contains 6 embedded RDF statements represented using HTML+Microdata notation.

The embedded RDF content will be recognized by any processor of HTML5 Microdata.

Subject Item

fn15schema:hasSubFE

rdf:type

owl:ObjectProperty

rdfs:subPropertyOf

fn15schema:hasFERelation

owl:inverseOf

fn15schema:hasSuperFE

rdfs:domain

fn15schema:FrameElement

rdfs:range

fn15schema:FrameElement

rdfs:comment

We have no explicit treatment of the idea of proto-frame elements, of which other frame elements are more specialized expressions. In cases like (28), we would prefer not to have to pick either specifically Agent or Cause as constructionally null instantiated, since the context might not provide enough information to resolve that question. Instead we would make reference to a superordinate frame element (call it *Force) that is vague about intentionality and the event-person distinction. Likewise in (29), where B answers a question about a new employee, we would prefer to use a superordinate frame element (which might be named *Field in this case), rather than choosing among the frame elements Role, Skill, Knowledge, or Focal participant for constructional null instantiation relative to the predicate good in the Expertise frame. (28) The car got damaged while parked outside of our house. (29) A. How’s Susan working out? B. She’s very good. Having an explicit representation of proto-frame elements would also be useful in dealing with certain linguistic expressions that seem to instantiate the superordinate proto-frame element rather than one of its more specific manifestations. Consider the phrase trench to trench in (30): it does not refer to the Source or Goal of a Path but neither does it refer to a middle Path which would be compatible with the specification of a final Goal. A proto-frame element Full path would provide the most adequate treatment. (30) He crawled [trench to trench], looking for some sign of Stephen. Another use for Proto-frame elements involves inheritance relations. In some cases, an inheriting frame will allow only one FE from an Excludes or CoreSet group in the parent frame. Superficially, this violates the rule that requires child frames to have a corresponding FE for each core/peripheral FE of the parent. In a deeper sense, however, inheriting only one member of a frame element set should be permitted on the understanding of inheritance as subtyping. This is so because the child frame is fulfilling every constraint of the parent, merely adding a constraint that prevents one of the construals possible in the more generic case. If we state the frame element restriction on inheritance so that it pays attention only to the most generic level of FEs, then mappings from subsidiary FEs are allowable, but not required. This would make it possible, for instance, to have a *Murder frame (with only agentive causes) as a child frame of the Killing frame (which allows Causes or Agents).