►
From YouTube: 2018-09-11 : DSpace 7 Entities Working Group Meeting
A
A
So
for
this
meeting,
the
plan
was
to
go
through
discussions
and
documentation
about
the
configuration
of
the
entity
types
and
the
relations
for
the
first
two
sections
and
then
the
J
Java
API,
considering
the
team
is
not
a
hundred
percent
today,
the
suggestion
would
be
to
go
through
the
document
that-
and
they
are
linked
to
the
main
document
this
morning
with
the
alternative
suggestion
and
proposal
for
the
document.
So
I'm
not
sure
all
of
you
already
had
a
chance
to
read
the
document.
A
A
B
It
may
not
necessarily
be
a
consensus,
but
at
least
we'll
get
more
feedback
in
and
make
a
better
solution
for
for
all
everybody,
Hughes's
dspace.
So
with
that
said,
that's
all
I
wanted
to
add.
I
just
want
to
remind
that.
That
is
our
scope
here:
we're
not
trying
to
to
bang
on
getting
at
Mayer
and
for
science
to
answer
questions
on
their
proposal,
but
they
are
more
than
welcome
to
thank.
C
So
if
no
one
has
to
add
out
their
topic
to
the
agenda,
I
just
shared
it
again.
The
link
to
data
comment
on
the
zoom
chat,
but
you
also
have
to
link
on
on
slack
I,
see
that
a
lot
of
people
I'm
joined
now
to
Google
Docs
I,
guess
that
everyone
is
here
now
yet
idea
is
quite
simple
and
is
it's
bigger
than
Texas
and
prototype
for
mattify.
So
the
basic
idea
is
what
was
the
suggestion
of
the
working
group
so
essentially
to
use
the
the
space
item
as
storage
for
any
kind
of
entity?
C
This
is
the
commonality
with
the
admirer
or
prototype.
What
we
suggest
you
to
change
is
the
way
that
the
relationship
between
entities
are
stored
in
the
system.
Our
suggestion
is
to
use
a
feature
that
is
a
red
exist
in
the
space
is
a
very
use.
It
is
the
authority
framework.
This
is
a
feature
that
the
inter
previous
version
was
not
so
known,
but
it
was
introduced
in
1.6.
So
is
a
long
time
feature
in
the
space.
C
So
thirteen
framework,
the
major
use
of
two
Authority
framework
right
now
in
the
space,
is
for
the
orchid
integration,
so
heavy
in
Institute
any
displace
acceleration
that
have
an
orchid
integration
now
use
the
auto
D
framework
to
to
link
the
auto
name
with
a
rich
record
that
currently
is
stored
in
in
solar
in
the
current
orchid.
The
authority
of
the
space
where
you
have
additional
metadata,
including
the
orchid
ID
so
TVA,
is
to
rely
on
this.
C
This
existent
feature
to
store
relation
with
other
items
in
the
space.
So
if
you
use
an
item
for
to
represent
people
a
person
or
to
represent
an
organization
or
a
journal
or
boodle,
you
can
simply
store
the
UID
of
the
of
the
item
or
an
unique
identifier
of
this
item
in
the
authority
of
the
metadata
that
linked
to
original
item
to
publication,
with
author
and
and
so
on.
C
If
you
look
to
the
document
title
at
the
most
explicative
parties
in
the
storage,
if
you
look
to
the
storage
into
the
base,
you
can
see
also
I
included
a
diagram
where
you
can
see
that
a
publication,
for
instance,
is
a
linker
to
have
several
auto
sum
of
this.
Author
are
well
known,
so
you
have
on
a
rich
profile,
forties
researcher
in
the
system.
C
This
mean
that
the
researcher,
one
and
researcher
two
are
displaced
items
where
you
can
store
additional
information
about
this
researcher,
as,
for
instance,
the
orchid
ID,
and
another
researcher
instead
is
less
not
to
system
is
an
external
researcher.
So
you
don't
have
anything
more
than
just
the
name.
Has
it
appear
into
publication
and
most
of
time
we
don't
make
any
sense
to
create
a
very
basic
record
which
just
string,
if
you
don't
know
anything
about
the
researcher
using
key
authority,
the
atole
framework.
C
C
The
other
nice
thing
to
use
the
authority
framework
for
to
manage
relationship
is,
if
you
look
to
the
reserve
publication
to
this
publication,
to
you
also
have
a
contribute
rotor,
but
this
time
the
author
is
not
really
a
person,
but
is
an
organization.
This
is
a
quite
common
use
case
in
many
field
because,
for
instance,
if
physicians
have
a
lot
of
research
group
that
usually
sign
the
publication,
but
this
is
not
just
limited
to
the
publication.
C
So
when
you
have
a
relation
that
is
the
auto-ship
or
not
lot
of
ways,
you
don't
have
fixed
target
entities
for
the
relation
from
one
side,
you
have
a
publication,
but
the
other
side
could
be
a
person
or
could
be
an
organization
using
K
out
of
the
framework
you
are
able
to
do
that.
You
just
need
to
create
your
Authority
implementation
that
is
able
to
look
up
in
embodied
directory,
and
this
is
quite
simple,
as
we
will
use
items
for
both
for
any
entities.
Time.
D
Sorry
to
interrupt
I
just
want
to
make
a
brief
intersection
comment
here
that
both
of
those
use
cases
are
also
supported.
In
the
other
model,
just
I
mean
the
implementation
is
a
bit
different,
but
both
of
these
are
also
possible
in
the
other
model.
I
can
show
examples
of
it
later.
I
don't
want
to
interrupt
the
whole
thing
for
too
long,
but
this
is
also
perfectly
possible
in
the
other
model.
It's
just
the
way
that
it's
implemented,
that
it's
different,
so
sorry
continue.
Yeah.
C
I
would
like
to
discuss
that
more
at
the
end,
because
I'm
not
completely
sure
about
that,
for
instance,
is
that
most
true
for
everything,
but
in
if
you
store
relation
into
data
base
in
the
way
that
is
presenting
it
to
your
the
prototype,
you
will
be
not
able
to
decide
that
author
could
be
a
researcher
or
could
be
an
organization.
You
could
have
two
different
relation
for
sure.
C
So
you
can
say
these
are
the
person
author,
and
these
are
the
organization
author,
but
is
not
exactly
the
same
because
if
you
need
to
mix
one
person
in
one
organization
and
you
want
to
make
to
keep
track
of
the
proper
order,
then
the
organizational
peer
FreeStore
second
or
thing
like
that
is
rigged
the
difference.
So
you
are
not
able
to
really
track
this
graph
in
the
other
prototype,
but
we
can
discuss
more.
So
if.
D
C
In
any
case,
there
are
also
order
advantage
of
this
approach.
One
is
40
external
researcher,
so
in
this
case
you
are
not
required,
not
strictly
required
to
create
an
item
for
external
researcher.
You
can
do
that
if
you
like,
but
if
you
only
need
that
you
have
is
to
store
to
external
researcher
named
in
the
publication
metadata,
you
can
just
use
string
value,
and
these,
of
course,
don't
apply
only
to
water
or
so
to
other
metadata
in
the
publication.
It's
quite
convenient
to
create
an
authority
of
journal,
but
is
not
a
trivial
organization
issue.
C
So
not
all
the
institution
will
be
able
to
maintain
a
list
of
an
authoritative
list
of
journal
or
to
keep
these
list
quality
proof.
So
in
some
case
it
will
be
just
easier
to
keep
the
current
solution
of
the
space
to
to
have
flat
string
and
with
this
approach
you
are
not
required
to
create
additional
item.
If
you
don't
need
this
become
much
more
important.
When
you
talk
about
the
new
submission
in
a
needle
world,
you
have
altered
component
that
you
need
the
altie
entities
and
you
just
make
connection
with
this
entity.
C
But
what
an
opponent
reality
is
when
you
submit
a
publication
of
many
times,
you
have
some
author
that
already
exists
in
the
system
and
some
author
that
not
yet
exist
in
the
system,
and
you
need
to
create
this
entity
on
the
fly.
If
you
use
the
authority
framework,
you
can
just
put
the
string
name
for
this
author
and
have
a
consumer
into
system
to
create.
C
If
you
like
the
entity
when,
when
the
item
is
approval,
is
archived
in
the
system
delay
the
creation
of
the
auto
record
or
simplified
this
tiel's
cleaning,
because
of
course,
if
you
you
can
do
the
same.
Also
in
the
other
prototype,
if
you
put
a
name
that
is
not
in
the
index
run-time,
you
immediately
create
the
entity.
But
if,
after
just
one
step
to
submit
there
say,
oh
I
put
the
wrong
name
and
I
need
to
fix
something
change:
the
name
of
the
researcher
or
remove
the
external
researcher
that
was
just
created.
C
It's
a
lot
of
housecleaning
stuff
that
you
need
to
be
maintaining
to
keep
or
today
dancing-
and
this
become
more
more
complex
if
you
think
about
parallel
submission
where
stuff
created
by
your
serger
could
be
used
by
other
research
in
other
submission
or
thing
like
that.
Another
point
is,
then
totally
framework
is
already
integrated
with
orchid.
So
it's
what
is
used
for
the
orchid
integration,
so,
for
instance,
this
mean
that
if
you
just
care
about
publication
and
researcher
profile,
you
can
use
the
orchid
integration
to
look
up
with
your
edges.
C
E
If
you're
working
with
items
representing
an
entity,
of
course,
the
orchid
integration
will
need
to
be
modified
as
well
to
make
sure
it
doesn't
just
create
an
authority
like
ability
to
create
the
item
entity
as
well,
so
that
should
be
redesigned
for
you
just
as
much
as
we
need
to
be
redesigned
for
using
database
relations.
The
question
where
the
relation
is
stored
is
not
the
important
part
here.
We
need
to
create
the
entity
ID.
C
Sorry
to
disagree
with
you
ban
on
that,
but
if
you
introduce
a
new
concept,
that
is
the
relation,
and
we
need
to
manage
this
relation
in
the
submission
you
can
for
sure
use
the
authority
to
as
a
workaround.
So
during
the
submission
use
the
authority
to
information
and
owns
the
item
is
published,
you
move
to
information
from
the
authority
to
the
relation,
but
essentially
it
is
me
that
you
are
using
totally
framework
and
you
are
just
moving
into
data.
Instead,
these
are
ready.
C
If
you
want
to
go
to
really
use
the
relation
structure,
you
need
to
create
a
new
component
into
submission
so
that
the
user
will
have
input
where
they
can
search
hook
up
for
existin
to
author
and
so
on,
and
in
any
case
one
of
the
question.
One
of
the
point
that
I
have
alighted
in
in
the
approach
is
we
say
that
not
all
institution
want
to
deal
with
additional
entities.
Some
institution
want
to
say
with
a
basic
space
and
don't
want
to
care
about
the
additional
entities
at
all.
C
But
in
this
case,
which
will
be
the
role
of
the
authority
framework
and
relation,
there
are
two
features
that
do
most
less
the
same
thing
and
it
will
be
unclear
when
you
need
to
use
one
of
the
order
and
if
you
have
more
code
to
maintain
it
will
be
just
yeah
more
codes.
110
is
just
a
major
burden
in
maintenance,
so
edited
that
is
exactly
the
same
and
translated
sorry.
E
C
No,
this
is
this
is
not
true.
There
are
a
lot
of
authority
outside
here
that
are
related
to
external
system,
and
you
are
not
required
to
create
a
local
cache
of
these.
Of
this
data,
for
instance,
also
institution
that
have
market
integration
and
don't
want
to
manage
researcher
profile
could
just
use
the
existent
orchid
Authority
and
it
will
work
without
any
change.
C
The
change
that
you
need
to
hang
on
to
orchid
authority
is
is
just
the
final
storage
instead
in
use,
especially
solar
core,
where
you
store
this
data,
you
can
decide
to
use
the
entities,
but
if
you
look
to
the
mesh
subject
or
to
get
heated
zeros,
you
are
not
required
to
to
maintain
these
additional
tests
ourselves.
This
base
entity
you,
who
use
an
authority
that
dynamically
will
use
the
webservice
from
this
provider
to
get
the
terms.
D
And
plus
I
think
it's
even
more
unclear
to
the
user,
because
you're
using
the
authority
framework
for
both,
so
it
doesn't
make
it
so
clear
when
you
have
to
choose
for
the
authority
framework
and
one
you
have
to
choose
for
for
an
entity
in
the
authority
framework.
When
is
it
about
a
vocabulary
and
when
is
it
about
an
entity
where
I
mean
the
way
we
saw
it
now?
Is
that
you
know
having
an
entity
as
an
item.
D
C
Is
this
will
be
solved
very
easily
in
the
configuration
of
the
authority
you
can
just
imagine
about
of
in
the
configuration
that
say,
I
want
to
transform
to
record
the
in
entities
or
not
so
you
will.
In
any
case,
you
will
use
the
orchid
authority
to
to
get
the
idea
of
the
author.
If
you
want
to
create
an
orchid
profile,
you
say
to
enable
or
local
profile.
C
If
you
want
to
have
local
profile
for
project
from
open-air,
you
can
use
the
open
air
project
authority
that,
for
instance,
we
have
in
in
this
base
Chris
that
you
look
up
into
web
services.
If
you
want
to
just
get
the
ID
use
these
authority
Aziz.
If
you
want
to
create
also
project
profile,
you
can
set
these
flag
to
say
locker
profile
to
and
it
will
be
used
for
user.
There
is
no
choice.
It's
just
a
way.
C
D
It's
it's
actually
quite
the
same
in
both
scenarios.
I
would
say
so.
I
don't
see
how
this
is
a
determining
factor
to
decide
whether
you
want
to
store
the
relationship
as
a
database
table
or
as
an
authority
control
I
mean
and
in
in
both
proposals.
You
will
have.
Let's
say
we
talk
only
about
publication
and
author
now,
for
example,
so
you
will
have
the
the
user
will
have
the
option
to
put
in
a
cleared
of
the
text
value
as
it
is
today.
D
C
So
if
we
need
the
less
effort,
if
we
need
less
Java
classes,
if
we
need
less
change,
it
will
be
better
because,
let's
change
you
do
in
to
database
you
to
do
something
that
we
agree.
That
is
not
yet
the
final
solution,
because
we
are
going
fast
to
support
this
implementation,
but
we
don't
have
the
fully
deal
of
what
are
the
needed
more.
We
can
postpone
new
concept
into
Lucien
on
your
concept.
C
If
you,
in
the
current
way
to
store
relation
in
addition
that
a
table
you
just
sort
the
foreign
key,
so
you
say
this
publication
is
related
to
this
researcher,
but
you
don't
say
anything
about
which
is
the
string
that
is
used
to
create
this
connection,
and
this
string
is
quite
important
in
several
domain,
for
instance,
an
author
have
several
variants,
a
several
name.
Of
course.
This
name
called
appear
in
the
local
profile.
C
So
in
your
local
profile,
your
orchid,
you
can
have
the
official
name,
your
translated
name,
the
family
name,
the
marriage
name
and
everything
like
that.
But
if
you
want
to
really
track
which
publication
was
sign
at
which
which
exact
name-
and
this
could
be
also
important
for
historical
well,
there
is
sadhana
moon.
If
you
talk
about
pop
in
historical
domain,
that
are
sign
it
before,
after
that
they
become
pop
or
other
famous
person
is
quite
relevant
to
know
which
publication,
which
object
was
cited
with
one
name
or
another.
C
There
are,
of
course,
other
structures
that
allow
you
to
to
manager.
Also,
this
kind
of
thing
cannot
in
database
structure,
but
I
think
that
is
quite
more
complex.
So
if
you
like
to
make
an
experiment,
your
with
your
proposal
to
to
describe
how
you
are
able
to
travel
publication,
Auto
read
by
a
researcher
and
an
organization
that
was
an
interesting
use
case
and
another
example
where
you
have
to
publication:
Auto,
read
by
the
same
people,
but
using
two
different
name,
and
you
want
to
store
this
name.
C
This
also
will
be
useful
to
see
how
complex
will
become
maintain
this
information
in
a
completely
normalized
database
structure.
That
is
what
you
propose
for
relation,
so
this
is
one
other
benefit
that
I
see
the
other
is
for
the
community
at
all.
When
we
talk
about
immigration,
if
you
have
an
existent
space,
emigrate
to
displace
seven
and
start
to
think
about,
I
want
to
start
to
use
entities.
C
Even
your
approach,
the
idea,
if
you
have
special
table
for
relation
you
need
to
convert
the
see,
contribute
or
alter
in
something
else.
So
we
need
sequel
script
to
immigrate
to
normalize,
to
clean
up
the
data
all
together
during
immigration,
when
you
enable
entities
if
use
otology
control,
as
you
just
start
with
your
existing
database.
All
the
item
have
just
simple
string
and
you
can
just
upgrade
one
item
by
one
editing,
tea
item
and
say:
ok,
this
paulina
andrea
is
this
one.
This
is
another
I
want
to
create
a
local
profile
or
not.
C
So
you
can
also
do
that
massively
for
all
if
this
is
the
case,
but
the
decision
is
up
to
you
and
I
think
that
this
will
make
the
migration
much
easier.
What
a
technical
aspect
that
of
the
organization
aspect,
because
they
can
start
one
place
or
maybe
just
fix
all
the
rezoned
items
or
thing
later
of.
E
Course
the
sense
does
not
apply
for
the
model
that
we
put
post
on
one
and
you
don't
have
to
migrate
two
entities,
but
if
you
do,
for
instance,
want
to
migrate
the
authority
control
orders
to
a
person
entity,
you
will
need
to
migrate
them
to
items.
That's
true
for
both
proposals.
You
can
do
that
in
batch
and
that's
gonna
be
similar
for
both
proposals,
or
you
can
do
that
one
by
one
and
the
difference.
There
will
be
that
in
your
proposal
you
have
two
different
solutions
and
authority
control.
E
For
the
author
and
on
our
proposal
you
have
a
public
person
and
a
private
person,
for
instance,
whether
you
only
make
the
public
people
accessible
and
the
tribe
when
you
keep
the
private
people
with
limited
readwrite,
so
that
you
can
translate
around
make
that
still
make
them
public.
You
can
do
the
the
process
of
migrating
them
to
items
all
at
once.
So
it's
just
a
matter
of
determining
writing
and
make
certain
person
public.
C
Yeah
I'm
not
sure
that
you
can
do
that
for
just
a
subset
of
the
items.
So
if
you
start
this
accumulated
author,
he
will
be
great
or
to
order
the
other
thing.
Please
check
careful
about
what
means
to
create
new
code
identities,
search
great
items
for
each
new
submission.
When
you
need
to
describe
author
from
the
start
because
identity
all
screening
work
during
the
submission
when
the
author
name
is
not
yet
finalized
or
some
author
AHA
added
the
removal,
it's
not
trivial.
So
this
is
my
worry
I
would
like.
C
I
will
appreciate
if
you
can
describe
better
who
this
scenario
is
managed
in
your
current
prototype,
and
you
can
reason
about
the
number
of
query
that
need
to
be
done
into
database
to
maintain
that
in
terms
of
insert
into
database,
update
or
delayed
and
alter
consequence
that
you
have
in
terms
of
table
lock
or
row
lock
into
table
ID.
That
is
quite
much
more
complex
to
manage
from
the
start
of
the
space
item
for
everything.
C
C
D
One
small
comment
about
the
submission
is
yeah.
There
is,
of
course,
at
the
moment,
nothing
implemented
in
the
prototype
for
it's
a
patient,
because
the
submission
pull
requests
are
not
there
yet,
but
we
do
have
specifications
for
it.
We
just
decided
not
to
include
them
in
the
document,
because
the
code
is
not
there
so,
but
we
do
have
something
in
mind
and
yeah.
You.
C
C
Absolutely
like
to
check
the
pull
request
and
we
don't
have
yet
I
have
received
a
review
on
the
pull
request.
That
is
your
son's
more
than
one
mount
I
have
restricted
now
and
on
the
newest
luxury,
put
request.
I,
you
received
some
positive
feedback
right
now,
so
I
think
that
you
can
just
check
out
the
branch
and
work
on
native.
If
you
like,
yeah.
D
C
Okay
and
again,
I
want
to
stress
the
argument
about
how
much
work
is
needed
to
put
in
place
these
disapprobation
work
that
was
required
is
what
at
mine
already
have
done
in
its
prototype.
So
we
can
completely
reuse
the
code,
develop
adding
on
the
angular
site
to
to
characterize
the
two
different
entity
types
so
that
you
can
have
a
different
page
for
a
searcher
for
publication
for
organization.
This
is
what,
at
my
hair,
already
have
done
in
its
prototype.
C
So
the
only
thing
that
probably
you
will
be
needed
to
create
is
an
authority
that
is
able
to
look
up
in
in
existent
items,
making
a
filter
based
on
to
entity
type.
This
is
some
existent
code
in
this
base,
crease
that
we
can
absolutely
reuse,
or
in
any
case
this
is
a
very
small
class
that
can
be
easily
created
in
I,
think
less
than
one
day
of
work.
So
it's
very
limited.
B
Thanks
Andrea
I
think
there's
a
lot
of
interesting
concepts
here
that
I
admit
I
have
to
think
about
more
once
I
mean
back
back
to
myself,
since
my
head
is
a
little
bit
concept
a
little
bit
cloudy,
but
but
one
question
I
did
have
from
from
the
get-go.
So
I
guess,
if
I'm
understanding
this
correctly.
So
in
this
model,
items
are
still,
of
course,
and
our
entities
are
still
items
authority,
control
may
or
may
not
use
entities
depending
on
whether
the
the
object
that
it's
referring
to
is
either
internal
or
external.
B
So
entities
are
optional
for
authority
control,
but
all
entities
are
Authority
control,
their
local
authority
control.
So
we
probably
have
two
I'm
assuming
there's
gonna
have
to
be
some
more
solar
indexes
to
be
able
to
pull
that
information
out
in
a
way
that
it's
useful
in
the
submission
process
and
understand
which
ones
are
local
versus
external
yeah.
C
It's
already
here:
okay,
the
search
core
of
solar,
already
index
all
the
items.
So
this
is
why
you
can
just
search
in
into
search
core
and
find
any
existent
item
in
the
current
code
into
master.
You
only
have
published
items
but,
as
you
know,
from
to
open
repository
demo,
the
pull
request
to
support
submission
and
so
on
also
introduced
the
indexing
of
any
in
progress.
Omission
right
in
solar,
tease
me
that
you
can
look
up
also
for
items
that
are
not
yet
published
and
as
by
default,
any
method
out
of
the
item
are
indexes.
C
If
we
essentially
propose
the
same
structure
for
the
entity
than
th
my
prototype,
so
we
expect
you
have
a
metadata
in
the
item
where
the
type
of
entity
is
stole.
It
is
essentially
exactly
goes
into
order
prototype
and
this
could
be
used
to
scope
the
search
to
a
specific
entity.
So
if
you
like
to
search
only
for
researcher,
you
will
say
entity
spot
type
or
colon
researcher,
if
you
want
search
in
researcher
and
organization,
you
will
have
enough
query.
B
B
We
will
have
more
time
to
be
able
to
look
at
this
back
at
your
own
institution
and
add
comments
into
the
Google
Doc
that
andreia
created,
but
I
would
like
to
just
get
a
sense
of
what
others
are
thinking
so
far.
Does
this
look
promising?
Do
you
want
to
bring
it
back
and
look
at
it
closer?
Do
you
have
some
concerns
about
just
storing
the
relationship
at
the?
In
you
know,
authority
control
just
curious
to
hear
what
others
are
thinking
so
far.
F
F
C
C
I
just
want
to
add
that
one
of
the
benefit
that
I
see
on
this
approach
is
a
potential
performance
gain
because
intermitted
data
you
have
also
to
text
value-
gives
me
that
for
a
basic
visualization
of
the
item,
you
don't
need
to
fetch
at
all
the
link
at
the
entities.
If
you
don't
need
additional
information,
when
you
get
the
item,
you
get
the
string
that
is
used
in
the
item
to
sign
the
design
to
publication
and
you
get
the
ID
of
the
link
and
auto.
C
So
you
can
create
the
link
to
to
the
tail
page
without
fetching
and
information
from
to
order.
If
you
want
to
fetch
additional
information
because
you
want
to
create
a
richer,
we
saw
it
session
where
you
can
see
showcase,
also
to
orchid
ID
or
the
affiliation
or
other
fact
above
to
otter.
You
just
need
to
make
a
query
on
the
primary
key
of
the
entities,
because
the
authority
is
a
string,
but
it
will
be
the
UID
of
the
items.
So
essentially
it's
just
a
get
the
item
using
its
primary
key.
C
Ya
thanks
for
this
question,
because
this
was
on
another
important
benefit
that
they
see
when
you
need
to
explore,
inverse
relation
I
feel
that
the
only
solution
is
to
go
on
solar.
So
in
this
approach
TDI
is
you
will
make
a
query
on
solar
to
say:
I
want
to
have
multiplication
that
have
author
and
score
authority
equals
empty
UID
and
you
will
get
the
list
of
publication
white.
C
It
is
much
better
than
make
a
query
on
to
the
top
base
because
you
don't
want
to
just
have
the
list
of
publication,
but
you
need
to
have
the
list
in
a
proper
order.
You
need
to
paginate
this
list.
You
need
to
sort
the
list
on
specific
criteria.
You
need.
You
want
to
propose
facet.
You
want
to
create
a
rich
experience
to
navigate
this
publication.
C
E
E
All
his
volumes,
because
you're
gonna,
not
display
search
for
volumes,
are
going
to
display
the
volumes
in
the
order
that
they
haven't
been
stored
and
for
the
volume
you're
gonna
retrieve
the
higher
level
journal
directly.
So
there's
a
use
cases
where
you
can
use
bi-directional
relation,
but
not
having
a
bi-directional
relation,
is
not
an
advantage.
It's
a
future
less.
This
searching
is
something
that
you
don't
wanna
support.
E
C
So
then,
I
agree
with
you
is
a
feature
that
both
models,
support
and
this
approach
does
support
direct
reading
onto
database
or
or
less
than
support
with
the
reasonable
or
four
months
the
query
on
to
database
directly
from
the
database
for
inverse
relation.
But
there
are
no
real
use
case
where
you
want
to
go
on
to
the
debase
to
clearly,
because
also
the
example
that
you
do
have
much
better
result
go
into
solar.
C
If
you
want
to
have
the
list
of
volume
for
a
journal,
you
can
make
a
query
on
solar
and
you
can
decide
to
sort
by
the
date
of
issue
or
for
volume
number
or
for
whatever
you
want.
If
you
make
this
query
on
to
the
debase,
and
you
want
to
sort
for
something,
the
performance
will
be
very
pure
because
the
metadata
are
in
a
different
table.
You
know,
so
you
need
to
join
and
it's
not
really
feasible.
So
again,
I
will,
like
you
see.
E
If
you're
gonna
sort
on
something
in
the
metadata
of
the
related
item,
that's
not
going
to
be
applicable
if
you
have
a
fixed
order,
for
instance,
if
you
have
just
like
metadata,
we
have
the
place
in
there
so
that
you
can
say
okay,
this
is
journal
volume,
1,
2,
3,
4,
5,
6,
7
and
just
use
them,
and
you
display
that
in
the
order
that
they
have
been
added
to
the
to
the
journal,
so
that's
even
another.
Each
of
that
sailor,
you
do
have
that
place
column,
have
both
directions.
C
C
C
E
B
One
I
think
it'd
be
useful
to
get
to
use
cases
here
so
because
I'm
unclear
myself,
I'm
a
little
foggy
like
I,
said,
but
I
think
it
would
be
useful
to
talk
about
the
scenarios
of
bi-directional
relationships
and
some
sort
of
use
cases
for
why
these
become
important
at
the
database
level.
To
be
able
to
do
that.
Just
because
I
think
that
will
easily
clarify
one
of
the
key
differences
between
these
two
proposals,
or
at
least
I,
would
hope.
B
I
don't
know,
but
I
think
it
would
be
useful
to
bring
this
to
use
cases
that
that
each
of
these
proposals
feel
that
they
sort
of
meet
better
or
that
might
be
a
gotcha
sort
of
a
use
case
that
the
other
proposal
may
not
be
able
to
support
as
well,
because
that
would
allow
us
to
kind
of
really
get
our
minds
around
this
more.
B
You
know
I'm
not
sure
we
have
enough
time
to
go
through
that
in
detail
today,
Ben.
So
that's
why
I'm
kind
of
wondering
if
this
is
a
useful
to
document
these
sort
of
use
cases
and
scenarios
in
these
two
documents
themselves,
so
we
can
kind
of
talk
through
them
at
the
next
meeting
to
bring
us
closer
to
sort
of
a
decision
point
on
these.
B
B
D
So
it's
not
that
difficult,
but
I
think
one
of
the
key
other
points,
but
if
correct
me,
if
I'm
wrong,
that
we
had
is
that
you
know
with
the,
if
you
do,
if
you
do
need
bi-directional
relations
with
the
authority,
control
implementation,
you're
also
doing
data
duplication
and
okay,
there
might
be
some
that
there
is.
There
are
also
a
lot
of
disadvantages
to
duplicating
the
data,
but
Ben
can
explain
this
much.
E
D
C
C
C
Also,
if
you
have
a
one-to-one
relation,
you
can
always
from
the
publication,
make
a
query
on
soar
and
say
give
me
whole
data
set
that
are
linked
to
this
publication,
but
it's
become
convenient
to
update
the
item
of
the
data
set
as
well.
When
you
create
a
publication
that
is
linking
to
the
data
set,
because
maybe
you
want
to
update
the
metadata
of
the
data
set
on
the
site
and
you
need
to
generate
metadata
of
the
item.
So
this
become
very
specific
implementation.
Detail
that
I,
don't
I.
C
Don't
think
that
we
should,
including
now
in
the
discussion
to
real
discussion,
is
not
about
the
approach
you
can
completely
withdrawn
to
consumer.
You
don't
need
it
is.
An
optional
item
is
an
an
additional
possibility
that
you
have.
If
you
have
a
very
specific
use
case-
and
you
see
that
this
is
very
relevant
and
in
this
case
I
agree
with
you
that
there
is
a
duplication
of
data.
But
you
can
completely
reach
out
from
the
proposal
and
never
change.
B
That'd
be
good,
Andrea
and
I'd.
Ask
that
others
start
to
add
comments
and
Andria's
document
here,
so
that
we
can
track
these
questions
a
little
bit
better.
I
have
jotted
down
a
couple
notes
here
throughout
the
meeting
that
I'll
also
post
on
the
wiki
page
likely
tomorrow,
but
but
I'm
not
sure
that
I
captured
all
of
the
comments
and
questions,
so
it
would
be
useful
to
have
others
enhance
these
and
add
your
comments
directly
into
the
documents.
B
But
since
we
only
have
a
couple
minutes,
left
I
did
want
to
try
and
see
if
we
can
figure
out
a
time
for
our
next
meeting.
There
are
no
conflicts,
I
just
checked
in
double
checks
again
at
the
same
time,
next
Tuesday
or
even
an
hour
earlier.
If
we
wanted
to
do
an
hour
earlier,
but
I
guess
I'm
curious
is:
does
this
time
generally
work
for
folks?
Would
you
prefer
it
get
moved
to
a
different
day
or
do
I
need
to
just
do
it?
Doodle
poll
you.
D
Know
what
I
is
we
were
talking
about
some
specific
use
case
and
Adria
mentioned
a
few
where
he
said.
Ok,
I
would
like
to
see
how
the
model
does
this
I
think
it
would
be
useful
if
we
wait
two
weeks
this
time
and
that
we
take
a
look
at
how
we
will
implement
or
how
this
model
can
implement
some
of
the
use
case.
So
we
can
have
a
better
side-by-side
comparison
so
that
everybody
can
see
like
ok.
B
I'm,
okay
with
that,
provided
that
people
are
active
in
the
documents
and
that
also
leave
in
you,
you
already
alluded
to
some
prayer,
patience,
slides
those
need
to
get
shared
during
this
two-week
period
to
allow
this
discussion
to
actually
occur
in
a
more
offline
fashion,
so
I
think
that's
the
only
way
that
works
is
if
the
we
share.
All
the
information
we
have
along
with
those
use
cases
that
we
feel
are
are
potentially
problematic
with
the
other
solution.
I
have.
D
Them
in
the
slides,
I'll
throw
them
into
the
document
and
expand
that
Andreev.
You
could
post
like
the
two
three
main
things
so
you've
already
said
the
the
relation
is
author
of
relation
to
like
an
or
keynotes
that's
or
an
entity.
That's
not
a
person.
You
mentioned
the
name,
variance
problem
where
you
have
several
string
values
for
an
author
name,
and
you
would
like
to
assign
one
particular
value
to
a
particular
relation
between
a
publication
and
the
person,
but
I
might
be
forgetting
some
of
the
other
ones.
C
Other
one,
the
major
one,
is
what
is
missing
in
this
new
approach
compared
to
your
approach
in
terms
of
real
use
case,
you
know
as
implementation,
because
my
point
is
less
Kody
is
better
for
sure,
because
that's
what
you
do
less
code,
if
you
have
to
maintain
and
it's
easier
to
evolve,
you
don't
need
to
to
set
the
constraint
in
advance.
You
can
decide
about
structure
when
you
really
need
this
structure
is.
B
Okay,
so
we
need
to
jump
in
here
and
wrap
this
up.
I
think
that
it
is
useful
to
bring
those
use
cases
and
questions
into
into
the
documents
themselves
to
make
sure
they
are
documented
there.
As
I
said,
I
did
capture
some
of
the
discussion
here
and
some
notes
which
I'll
post
but
I
agree
that
we
need
to
get
those
those
noted
down
textually
so,
but
if
we
meet
in
two
weeks
is
this
time
in
two
weeks
work
for
folks
this
the
room
is
also
available.