Value Compaction broken #171

Closed
gkellogg opened this Issue Oct 21, 2012 · 5 comments

Comments

Projects
None yet
4 participants
Owner

gkellogg commented Oct 21, 2012

Back in June, I made a comment on a change made by @dlongley to Value Compaction in commit fdb3371. There was a small change made, but I think it's still seriously wrong.

Step 1 was updated slightly, but it now says the following:

If value only has one property and the active context has no default language, then the compacted value is the value of @value.

Note that this doesn't look at term coercion at all.

Step 4 indicates that {"@id": "foo"} can always be compacted to the IRI Compacted form of "foo", which is only true if the active property is coerced to @id.

Otherwise, if_ value_ contains an @id key, the compacted value is_ value_ with the value of @id processed according to the IRI Compaction steps.

There is no provision for native values, except in the last step.

This came to light, as I was tracking down a bug in compact-0018 where the expected value in a list of term5 is {"@value": 4}, not just 4. IMO, it should be just 4, as it has unambigious meaning, and doesn't need to be represented in value form.

Value compaction will require other changes to handle language conatiner terms, but I don't understand how it could be so far off, and not match the rest of the compaction tests.

Member

lanthaler commented Oct 22, 2012

This came to light, as I was tracking down a bug in compact-0018 where the expected value in a list of term5 is {"@value": 4}, not just 4. IMO, it should be just 4, as it has unambigious meaning, and doesn't need to be represented in value form.

No, that's not true anymore. When we moved all the magic around native types to fromRDF/toRDF we changed the behavior to also allow type coercion of native types, i.e., also a JSON number will expand to a value object with a datatype if it is found in a type-coerced term. I will add a test to document this.

@lanthaler lanthaler added a commit that referenced this issue Oct 22, 2012

@lanthaler lanthaler Test expansion of native types in type-coerced terms
This addresses #171.
1b5fdca
Owner

msporny commented Nov 20, 2012

@gkellogg @dlongley @lanthaler Where are we on this issue? It seems as if it is resolved, but I don't see how it was resolved (other than adding a test underscoring that the current spec text is correct). Can we close this issue? Is the addition of the test that Markus' added enough?

Owner

msporny commented Nov 20, 2012

We need to update all of the algorithms to take things like language maps and property generators into account. The value compaction algorithm assumes too much about the input and needs to be updated to take things like type coercion, language maps, and property generators into account.

Owner

dlongley commented Nov 27, 2012

One of the things to remember about the algorithm is that it is simplified because of assumptions made by term selection. If a particular term cannot be selected due to the term ranking algorithm, then we don't have to worry about losing information/conflating plain vs. typed literals when simplifying @value. This is why we can avoid having to consider @type coercion information here -- it has already been considered by the term ranking algorithm. The same likely applies (or we'd like it to apply to keep things simple at this step) to language maps and property generators.

@lanthaler lanthaler added a commit that referenced this issue Dec 20, 2012

@lanthaler lanthaler Update Value Compaction algorithm
This addresses #171.
9b731ac

@lanthaler lanthaler added a commit that referenced this issue Dec 20, 2012

@lanthaler lanthaler Update Value Compaction to work with containers
This addresses #171.
975ef07
Member

lanthaler commented Dec 20, 2012

I've just updated the Value Compaction algorithm to take everything into account we changed since the last update (language maps, annotations, etc.). I will therefore close this issue in 24 hours unless I hear objections.

lanthaler closed this Dec 21, 2012

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment