Framing doesn't compact a property if it is missing from the data (even when default is provided)

[cboettig]

@gkellogg sorry to bother you once more, I think this should be my last issue in my (miss)-handling of "@type" that causes me to get unexpected behavior.

Consider this data:

{
  "@context": {
    "schema": "http://schema.org/",
    "name": "schema:name",
    "url": {"@id": "schema:url", "@type": "schema:URL"}
  },
  "name": "Jane Doe"
}

Under this frame:

{
  "@context": {
    "schema": "http://schema.org/",
    "name": "schema:name",
    "url": { "@id": "schema:url", "@type": "schema:URL"}
  },
  "name": {},
  "url": {"@default": "http://example.com"}
}

The output url property cannot be compacted and remains as schema:url.

On one hand, this makes sense -- this is the same compaction behavior we would get if the input data did contain url but with a different type. Because the element is not present, that's kinda like not knowing it is typed correctly.

However, it would seem that this is clearly not the desired behavior for the developer, who expects to still be able to reference url and get back the default value. This all works as expected if the context doesn't declare an explicit data type for url. Perhaps a bug? But again I'm likely missing something. Thanks!

Playground

[gkellogg]

@cboettig: The first thing that occurred to me is that there's a datatype mismatch between the default value and the datatype associated with url, but it seems reasonable to expect that the value of @default would be expanded using the term definition for url. But, if you use the expanded form for @default, it still does not compact properly:

{
  "@context": {
    "schema": "http://schema.org/",
    "Person": "schema:Person",
    "name": "schema:name",
    "url": {
      "@id": "schema:url",
      "@type": "schema:URL"
    }
  },
  "@type": "Person",
  "name": {},
  "url": {
    "@default": {"@value": "http://example.com", "@type": "schema:URL"}
  }
}

Results in:

{
  "@context": {
    "schema": "http://schema.org/",
    "Person": "schema:Person",
    "name": "schema:name",
    "url": {
      "@id": "schema:url",
      "@type": "schema:URL"
    }
  },
  "@graph": [
    {
      "@id": "_:b0",
      "@type": "Person",
      "name": "Jane Doe",
      "schema:url": {
        "@type": "http://schema.org/URL",
        "@value": "http://example.com"
      }
    }
  ]
}

This requires some more investigation, and likely relates to the details of the way that @default values are handled in expansion and some other issue involving compaction. Needs further investigation.

cc/ @dlongley

[gkellogg]

So, the fact that the key containing @default is not used when expanding the value of @default comes from the Expansion algorithm. It seems reasonable to require that values of @default not rely on anything in the context, so using {"@default": {"@value": "http://example.com", "@type": "schema:URL"}} in this case seems perfectly reasonable. However, a note to that effect should be added.

For compaction, the existing algorithm does not use the value of @preserve when selecting a term, this it's using schema:url in this case. A couple of tweaks to the algorithms seems to correct this:

• In Compaction: if expanded_property is @preserve, create compacted_value by calling compact using expanded_value and the existing value of property, rather than @preserve.
• In Compact IRI: if value is a dictionary containing the key @preserve, set value to the first value of @preserve.

This allows the proper term to be selected, and ensures that that term is used when compacting the value of @preserve.

There's likely more to it, as this change causes some other tests to fail, but that should be the gist of it.

@dlongley @lanthaler Does this seem reasonable?