- 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>
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