W3C home > Mailing lists > Public > public-linked-json@w3.org > October 2012

Re: compact-0018

From: Gregg Kellogg <gregg@greggkellogg.net>
Date: Sun, 21 Oct 2012 13:28:37 -0400
To: Markus Lanthaler <markus.lanthaler@gmx.net>
CC: Dave Longley <dlongley@digitalbazaar.com>, Linked JSON <public-linked-json@w3.org>
Message-ID: <220CEBBF-01CB-47B0-B853-FB5F8B3C86B5@greggkellogg.net>
On Oct 21, 2012, at 6:00 AM, Markus Lanthaler <markus.lanthaler@gmx.net> wrote:

> My implementation calculates term ranks as follows:
>  
>  
> term1
> term2
> itís a term
> +1
> +1
> @list container matches
> +1
> +1
> { "@value": "v1.1", "@language": "de" }
> +1
> -1
> { "@value": "v1.2", "@language": "de" }
> +1
> -1
> { "@value": "v1.3", "@language": "de" }
> +1
> -1
> 4
> +1
> +1
> { "@value": "v1.5", "@language": "en" }
> -1
> +1
> { "@value": "v1.6", "@language": "en" }
> -1
> +1
> total (list 1)
> 4
> 2
>  
>  
>  
>  
> term1
> term2
> itís a term
> +1
> +1
> @list container matches
> +1
> +1
> { "@value": "v2.1", "@language": "en" }
> -1
> +1
> { "@value": "v2.2", "@language": "en" }
> -1
> +1
> { "@value": "v2.3", "@language": "en" }
> -1
> +1
> 4
> +1
> +1
> { "@value": "v2.5", "@language": "de" }
> -1
> +1
> { "@value": "v2.6", "@language": "de" }
> -1
> +1
> total (list 2)
> 2
> 4
>  
> +1 are given to values that can be compacted, -1 to values that canít.

Well, that's not how the algorithm's written in the API spec. Shouldn't the tests test what the API spec says?

Gregg

> --
> Markus Lanthaler
> @markuslanthaler
>  
>  
>  
>  
> From: Gregg Kellogg [mailto:gregg@greggkellogg.net] 
> Sent: Saturday, October 20, 2012 11:47 PM
> To: Dave Longley; Markus Lanthaler
> Cc: Linked JSON
> Subject: compact-0018
>  
> I think there's a problem in compact-0018 regarding finding the appropriate terms for term1 and term2.
>  
> The test includes two lists, associated with an IRI shared between term1 and term2. The difference is that term1 and no language defined, and term2 has a language different from the default of the context ("en" vs "de").
>  
> The result comes down to calculating the term ranks for each value in the list. I come up with the following calculations:
>  
>  
> value
> term1
> term2
> { "@value": "v1.1", "@language": "de" },
> 3
> 0
> { "@value": "v1.2", "@language": "de" },
> 3
> 0
> { "@value": "v1.3", "@language": "de" },
> 3
> 0
> 4,
> 2
> 1
> { "@value": "v1.5", "@language": "en" },
> 1
> 3
> { "@value": "v1.6", "@language": "en" }
> 1
> 3
> total (term1)
> 13
> 7
> { "@value": "v2.1", "@language": "en" },
> 1
> 3
> { "@value": "v2.2", "@language": "en" },
> 1
> 3
> { "@value": "v2.3", "@language": "en" },
> 1
> 3
> 4,
> 2
> 1
> { "@value": "v2.5", "@language": "de" },
> 3
> 0
> { "@value": "v2.6", "@language": "de" }
> 3
> 0
> total (term2)
> 11
> 10
>  
> (pardon the formatting)
>  
> Basically, I find that term1 is selected in both cases, which results in an illegal compaction, as a term with @container: @list can't have two list values.
>  
> The playground, and presumably Markus' implementation does allocate between term1 and term2, so it seems that there's an inconsistency.
>  
> I think the test would be just as valid if v1.5 were "de" and v2.5 were "en", which would give the totals of 15 and 4 for the v1.x values and 9 and 13 for the v2.x values, which would result in the proper allocation.
>  
> Am I missing some detail in the algorithms?
>  
> Gregg Kellogg
> gregg@greggkellogg.net
Received on Sunday, 21 October 2012 17:29:30 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:18:35 UTC