jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eren Erdemli <erenerde...@gmail.com>
Subject Re: Assessing Oak for Dictionary App
Date Mon, 07 May 2018 02:07:47 GMT
Been travelling lately, just managed to see this,



How about something like this in context of English and French

  /dict/ax/axe
                    en/jcr:title
                    en/jcr:description
                    en/xx:synonyms
                    en/xx:antonyms
                    fr:name (French Reference by name i.e hache )
                    es:name (Spanish Reference by name)

                    fr/jcr:title (Same Spelling different meaning)
                    fr/jcr:description (Same Spelling)


Can you see any disadvantages to this


Eren




On 3 May 2018 at 17:51, Robert Munteanu <rombert@apache.org> wrote:

> On Wed, 2018-05-02 at 17:54 +0000, Eren Erdemli wrote:
> > Hi Robert,
> >
> > :) I suppose this is where it gets confusing
> >
> > I am thinking of structuring it with BT 2x2 max depth and length,
> >
> > i.e
> >
> > "a"     -> /dict/a (virtual=false)
> > "axe"  -> /dict/ax/axe
> > "apache" -> /dict/ap/ac/apache
>
> Where would the language fit it. Is it a property of the word entry
> node? If it is, how would you handle multiple languages?
>
> >
> >
> > Another question arises with this is how do we back reference in to
> > foreign
> > representation.
> > i.e where lets say axe = hache,
> >
> > maybe use of  mix:referencable and reference to it
> > "apache" -> /dict/ap/ac/apache/@references['xxxxxxx-xxxxxx']
> >
> > or when you have a word that has same spelling in multiple languages
>
> I would use simple path properties rather than references. References
> tend to bloat the UUID index.
>
> One option is to structure by language, e.g.
>
> /dict/en_EN/ax/axe
>
> You could add mix:title for title and description properties [1] to
> your node. Also you could have a multi-valued 'translations' properties
> which is of type path and points to the translations. Not sure if that
> is enough and maybe you want to have a node per translation to add more
> metadata.
>
> Robert
>
>
> [1]: https://docs.adobe.com/docs/en/spec/jsr170/javadocs/jcr-2.0/javax/
> jcr/nodetype/package-summary.html#mix:title
> <https://docs.adobe.com/docs/en/spec/jsr170/javadocs/jcr-2.0/javax/jcr/nodetype/package-summary.html#mix:title>
> >
> >
> > Eren
> >
> >
> > On 2 May 2018 at 14:28, Robert Munteanu <rombert@apache.org> wrote:
> >
> > > Hi Eren,
> > >
> > > On Mon, 2018-04-30 at 20:36 +0300, Eren Erdemli wrote:
> > > > Greetings,
> > > >
> > > > Might be a naive question,
> > > >
> > > > I have a multi dictionary app built on mysql which is around 15
> > > > years
> > > > old.
> > > > and have around 500GB of data
> > > >
> > > > I wonder if using oak mongomk is suitable option for porting this
> > > > app,
> > >
> > > Maybe :-)
> > >
> > > How do you see the data structured in Oak? I guess the first idea
> > > would
> > > be to somehow avoid having a large number (>10k) of orderable child
> > > nodes directly below a single node.
> > >
> > > Robert
> > >
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message