[
https://issues.apache.org/jira/browse/LUCENE-9855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17315328#comment-17315328
]
Tomoko Uchida edited comment on LUCENE-9855 at 4/6/21, 8:01 AM:
----------------------------------------------------------------
I set the Fix version of the issue to 9.0, to clarify which version this
blocks; hope we can reach some conclusion.
----
Thank you [~sokolov] and [~julietibs] for your help.
I just wanted to post one more option. Not sure it's better than options
already proposed so far.
A possible design recently proposed here - {{NumericVectors}} for the
high-level generic vector format interface, and {{Lucene90HnswNumericVectors}}
for a variant (concrete class) - is an understandable idea for me (and
personally I'd like it). Meanwhile, I'm on second thought: it could pose
another big question - *multiple format implementations/variants for a codec
are acceptable at all*. Anyway we cannot easily switch the format
implementation without touching the Codec (it's hardcoded on the
Lucene90Codec), even if other NN strategies are added. Sorry if I'm missing
something.
(To me) In a way we're struggling with a gap between extendable API design and
current implementation we have... then, how about considering
"{{HnswVectorsFormat}}" and "{{Lucene90HnswVectorsFormat}}" for a starting
point. I know it's not a good "interface" name at all, but this may represent
what we provide at least for now.
We could start from a concrete implementation with some room for future
extension, once we find out better way to achieve general vector format with
multiple NN implementations, then we can change/rethink the format name?
was (Author: tomoko uchida):
I set the Fix version of the issue to 9.0, to clarify which version this
blocks; hope we can reach some conclusion.
----
Thank you [~sokolov] and [~julietibs] for your help.
I just wanted to post one more option. Not sure it's better than options
already proposed so far.
A possible design recently proposed here - {{NumericVectors}} for the
high-level generic vector format interface, and {{Lucene90HnswNumericVectors}}
for a variant (concrete class) - is an understandable idea for me (and
personally I'd like it). Meanwhile, I'm on second thought: it could pose
another big question - *multiple format implementations/variants for a codec
are acceptable at all*. Anyway we cannot easily switch the format
implementation without touching the Codec (it's hardcoded on the
Lucene90Codec), even if other NN strategies are added. Sorry if I'm missing
something.
(To me) In a way we're struggling with a gap between extendable API design and
current implementation we have... then, how about considering
"{{HnswNumericVectors}}" and "{{Lucene90HnswNumericVectors}}" for a starting
point. I know it's not a good "interface" name at all, but this may represent
what we provide at least for now.
We could start from a concrete implementation with some room for future
extension, once we find out better way to achieve general vector format with
multiple NN implementations, then we can change/rethink the format name?
> Reconsider codec name VectorFormat
> ----------------------------------
>
> Key: LUCENE-9855
> URL: https://issues.apache.org/jira/browse/LUCENE-9855
> Project: Lucene - Core
> Issue Type: Improvement
> Components: core/codecs
> Affects Versions: main (9.0)
> Reporter: Tomoko Uchida
> Assignee: Tomoko Uchida
> Priority: Blocker
> Fix For: main (9.0)
>
>
> There is some discussion about the codec name for ann search.
> https://lists.apache.org/thread.html/r3a6fa29810a1e85779de72562169e72d927d5a5dd2f9ea97705b8b2e%40%3Cdev.lucene.apache.org%3E
> Main points here are 1) use plural form for consistency, and 2) use more
> specific name for ann search (second point could be optional).
> A few alternatives were proposed:
> - VectorsFormat
> - VectorValuesFormat
> - NeighborsFormat
> - DenseVectorsFormat
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
