You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jackrabbit.apache.org by Eren Erdemli <er...@gmail.com> on 2018/04/30 17:36:56 UTC
Assessing Oak for Dictionary App
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,
I am quite familiar with sling however trying to get my head around how
will such an app will fit into this context..
Eren
Re: Assessing Oak for Dictionary App
Posted by Eren Erdemli <er...@gmail.com>.
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 <ro...@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 <ro...@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
> > >
>
>
Re: Assessing Oak for Dictionary App
Posted by Robert Munteanu <ro...@apache.org>.
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
>
>
> Eren
>
>
> On 2 May 2018 at 14:28, Robert Munteanu <ro...@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
> >
Re: Assessing Oak for Dictionary App
Posted by Eren Erdemli <er...@gmail.com>.
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
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
Eren
On 2 May 2018 at 14:28, Robert Munteanu <ro...@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
>
Re: Assessing Oak for Dictionary App
Posted by Robert Munteanu <ro...@apache.org>.
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