compact-0034

Compact-0034 tests a corner-case for property generator compaction, which essentially requires that multiple property generators which could otherwise match a set of key/values be chosen be distinguished on how closely they match; essentially using the logic from the (former) term rank algorithm. IMO, this adds needless complexity, and does not fall out of the algorithm we decided upon:

	• For each term pg in the active context which is a property generator:
		• Using the first expanded IRI p associated with the property generator:
		• Skip to the next property generator term unless p is a property of element.
		• For each node n which is a value of p in element:
			• For each expanded IRI pi associated with the property generator other than p
			• Skip to the next value in p if pi is not a property of element or n is not a value of pi (usingnodeEquivalence).
			• Remove n as a value of all p and pi in element.
			• Add the result of performing the compaction algorithm on n to pg to output.

This algorithm essentially goes for the first match, all though the order in which we go through the property generator terms is not specified. Trying to be so discriminating on choosing the best possible term from among several that have the same mapping, is partly what makes IRI compaction complex. For the general use, I think it's probably warranted, but extending this for property generators is going too far, IMO, as it really requires that every property generator be tested against the keys in an object, and not just the first matching property generator. I suggest that we simplify this by just selecting the order in which we iterate through the potential property generator terms in lexical order. For this compact-0034, this would result in the following:

{
  "@context": { ... },
  "@id": "site:node/1",
  "field_related_list": [
    {"@id": "site:node/this-is-related-news"},
    {"@value": "This is a related string", "@language": "en"}
  ],
  "field_tags_nc": {"@id": "site:term/this-is-a-tag"}
}

Actually, pretty much the same as the current test results:

{
  "@id": "site:node/1",
  "field_tags_set_id": ["site:term/this-is-a-tag"],
  "field_related_list": [
    {"@id": "site:node/this-is-related-news"},
    {"@value": "This is a related string", "@language": "en"}
  ]
}

except for using field_tags_nc instead of field_tags_set_id.

The use of property generator terms is somewhat specialized and marginal, and I really don't think that a real world use would include essentially the same property generators varying in such minor details.

Using lexical order would also effect (and negate) compact-0033, which looks for shortest terms rather than lexically first. Again, I don't think that this level of discrimination serves any useful purpose.

compact-0032 looks to use property generator terms as prefixes, so that keys generated as CURIEs using the property generator base term take on the effects of the property generator. This was not anticipated in the algorithm, which looks for exact match of terms against expanded keys, and not prefix matches. As such, I think that this use is specifically dis-allowed, and likewise serves no real-world purpose.

Other than these, my implementation, using the original algorithm, passes all the compaction tests.

Gregg Kellogg
gregg@greggkellogg.net

Received on Friday, 4 January 2013 21:54:24 UTC