►
From YouTube: 2018-09-25 : DSpace 7 Entities Working Group Meeting
A
Okay,
welcome
all
so.
This
is
the
third
meeting
of
our
D
space,
seven
entities
working
group
so
and
obviously
we're
still
in
the
phase
of
sort
of
analyzing
the
early
prototype
and
starting
to
decide
what,
where
to
go
next,
but
I
thought
I
would
start
things
off
today,
just
as
a
review
of
where
we
are
and
what
our
timelines
are.
So
let
me
see
if
I
can
share
my
screen
here.
So
I
can
kind
of
walk
through
this.
A
Okay,
and
now
you
should
be
able
to
see
my
screen.
Can
somebody
verify
that
you
can
see
the
meeting
notes
for
today
or
the
meeting
agenda
for
today?
Yes,
sure,
okay,
okay,
so
just
doesn't
reminder
I'm
going
to
jump
back
to
the
main
entities
working
group
page
here.
As
a
reminder,
our
deliverables
are
listed
here
in
the
middle
of
the
page.
A
Let
me
see
if
I
can
bump
the
size
up
here,
a
little
bit
in
case
they're
a
little
bit
small,
but
we're
still
on
step
number
one
which
is
sort
of
assessing
the
early
prototype
I'm
in
alignment
with
goals
and
we've
kind
of
come
up
with
a
secondary
proposal
for
a
different
way
to
implement
our
the
idea
of
relationships
with
on,
which
is
what
Andre
had
proposed
at
our
last
meeting.
So
I
just
want
to
note
we're
still
kind
of
in
that
phase.
A
A
A
So
here
is
our
here's,
the
summary
document.
Let
me
bump
this
up
just
a
tad
and
the
majority
of
this
document
was
written.
Excuse
me,
sorry,
I
still
have
a
little
bit
of
a
lingering
cough.
Everyone
smiles,
so
I'll
apologize
in
advance
for
that
a
little
bit.
So
the
majority
of
this
document
was
written
by
me.
There
have
been
areas
that
that
folks
have
specifically
inserted
where
they've
noted
noted
that
they're
named
as
having
inserted
some
content
and
I
will
readily
admit
that
this
was
based
on
my
own
reading
of
the
two
proposals.
A
A
A
I,
don't
know
that
we
need
to
solve
that
today,
but
the
fact
that
even
people
with
our
own
group
don't
know
what
the
difference
between
an
entity
and
an
item
is
a
problem
that
I'd
kind
of
note
I,
think
I've
been
thinking
of
them,
always
as
that
they're
almost
one
in
the
same,
and
that
entities
are
kind
of
basically
typed
items.
So
it's
an
item
that
has
a
stronger
type.
So
it's
an
item
that
represents
an
author.
So
now
it's
an
author
item
or
an
item
that
implements
a
journal.
So
now
it's
a
journal
item.
A
Our
journal
issue
item
so
into
these
are
kind
of
typed
items
or
the
opposite
way
of
thinking
of
it
is
that
items
become
more
like
generic
entities,
so
there's
sort
of
untyped
entities.
There
are
things
that
that
are
not
really
represented
as
a
specific
type
within
your
dspace
instance.
So
it's
not
necessarily
an
author
or
even
an
article
or
a
pay.
A
It
could
just
be
some
sort
of
generic
object
that
does
have
metadata
and
that
metadata
is
related
to
one
or
more
files,
perhaps,
but
it
doesn't
necessarily
have
a
strong
type
that
causes
it
to
have
a
specific
behavior
within
d
space.
So
I
don't
know
if
anybody
else
anything
else
to
add
here
in
terms
of
trying
to
clarify
this
or
anything
that
folks
want
to
add
in
in
terms
of
this,
this
topic
at
all
I.
B
B
A
I'm
actually
wondering
whether
that's
the
case
in
my
head,
because
that's
a
key
difference
that
I
think
is
somewhat
between
these
two
proposals.
To
some
extent,
is
that
in
it
depends
on
which
proposal
you're
looking
at
in
the
proposal,
that
is
the
bi-directional
relationships
are
stored
in
the
database.
It
does
seem
like
those
are
only
effective.
Those
relationships
only
exist
for
entities,
but
in
the
other
proposal,
where
it's
a
one
directional
relationship
and
then
the
relationship
is
stored
in
metadata.
I,
see
no
reason
why
those
relationships
could
also
be
four
items.
B
A
But
I
guess
my
point
is:
is
that
it's
good
for
us
to
clarify
what
we
sort
of
mean
by
these
two
concepts,
because
it
actually
does
have
an
effect
on
how
you
look
at
these
proposals?
That's
that's
kind
of
I!
Guess
what
I'm
getting
at
so
I
guess
I'm
curious.
Does
anybody
else
have
questions
on
this?
Does
this
seem
to
clarify
the
fact
that
entities
and
items
are
very
similar
items?
A
C
C
Hi,
how
I
knew
to
the
group
and
new
to
the
project
but
I
do
have
an
opinion
on
this,
and
that
would
be
that
I
I
expect
that
records,
if
we
think
of
items
as
records
and
would
have
to
have
joan
entity
type
as
well.
So
I
would
say
that
a
default
item
or
a
record
as
we
know
it
now
would
become
a
an
entity
record
and
then
it
can
have
relationships
with
entities
of
authors
or
entities
of
journals,
entities
of
other
records
and
so
on.
C
A
A
Yeah
I
I
would
I
would
lean
it's
a
good
question.
Pascal
I
would
lean
towards
every
every
item
would
have
a
single
entity
type
initially,
just
because
we're
building
a
lot
and
we're
talking
about
building
a
lot
into
the
concept
of
what
the
entity
type
means
so
like
you
might
have
a
different
sort
of
display
for
that
specific
entity.
Type
different
sets
of
metadata
are
required
for
that
entity.
E
If
you're
thinking
on
Jonah
effuse,
it
might
happen
that
you
want
to
have
a
journal
issue
that
is
like
our
old
item
type,
and
that
is
also
a
journal
issue.
So
I
cannot
I'm
not
sure
right
now,
if
I
would
lean
to
all
items
can
have
one
type
only
as
you
but
I'm
a
little
bit
afraid
that
it's
not
predictable
konkey.
E
D
F
F
G
F
The
choice
is
made
in
advance
when
you
adopt
the
new
D
space
and
the
new
D
space
provides
you
the
opportunity
to
configure
entities.
You
configure
your
entities
according
to
your
domain
and
then
each
item
in
the
in
your
repository
belongs
to
some
specific
entity.
You
may
maybe
create
one
entity
by
default
and
all
the
rest
should
represent
your
domain.
That's
how
we
can
make
this
best,
crease
really
neutral
with
respect
or
the
contest
where
it
is
adopted
and
extend
its
reach.
F
F
A
Okay,
so
it
sounds
like
we're
at
an
agreement
point
here
so
I'd
like
to
probably
move
this
along
so
I
have
down
here,
and
this
is
important
that
we
can
notice
a
definition
that
all
items
have
an
entity
type.
They
have
a
single
entity,
type
at
least
initially
for
produced,
may
seven
and
then
and
then
there's
that
concept
that
both
both
Pascal
and
Paolo
mentioned
briefly
that
just
around
where
we
store
that
entity
type
which
we
can
get
into
a
little
bit
later.
A
In
terms
of
being
on
the
item
table
or,
however,
we
want
to
represent
that.
But
that
seems
like
a
good
definition
to
me.
That's
that's
a
little
bit
clearer
than
we've
had
written
in
anywhere
else,
so
thank
you,
Greg,
as
well
for
kind
of
kind
of
a
clearly
clearly
stating
that
as
a
proposal,
so
I'm
gonna
move
along
here
just
in
the
essence
of
time,
because
I
think
there's
a
lot
of
other
concepts
we
want
to
get
into.
But
that
seems
like
a
good
starting
definition
for
where
we
can
go
here.
A
Okay,
so
you
still
have
my
screen
app.
Let's
see
I'm
going
to
just
step
through
here,
so
I'm
going
to
skip
over
these
other
similarities
here
between
the
two
proposals,
because
it's
it's
mostly
around
the
fact
that
we're
using
items
here
there
was
some
discussion
here
around
virtual
virtual
metadata
on
entities
I'm,
not
sure
if
we
want
to
dig
into
this
very
deeply
right
now.
A
If
we
want
to
move
along,
but
I
know,
leaving
I
had
noted
that
he
was
worried
that
the
that
the
second
proposal
around
storing
metadata
or
storing
entity
relationships
within
metadata
may
not
be
able
to
implement
virtual
metadata
as
easily,
but
I
am
actually
thinking
that
it
it's
it's
similar
I
added
a
note
here
around
the
similarities
and
some
of
these
discussions
literally
happen
just
before
this
meeting.
So
now
you
probably
haven't
had
a
chance
to
to
read
through
this,
but
this
might
be
one
that
I'd
suggest
tabeling.
A
A
B
B
G
E
G
Replying
on
the
doc
is
not
you
country,
because
the
booster
metadata
proposal
that
I
had
in
the
proposal
to
is
a
hole
to
which
to
meet
are
already
implemented
in
this
place.
Chris,
and
actually,
you
can
check
into
out
of
box
configuration
that
from
one
single
metadata
you
can
get
how
many
information,
as
you
want
from
to
Lincoln
Lincoln
entity.
So
if
you
have
a
metadata
that
link
to
one
person,
you
can
get
the
old
kid
that
the
Scopes
ID,
the
department
and
and
so
on.
G
G
A
So
I'd
like
to
move
along
here,
because
I
think
this
digs
pretty
deep
in
so
maybe
we'll
well
well,
if
we
should
get
into
some
of
these
other
differences,
but
I
believe
that
I
didn't
see
the
same
limitations
either
when
I
was
looking
at
some
of
the
code,
so
unless
I'm
overlooking
them
as
well,
I
think
we
should
move
along
and
get
more
clarity,
maybe
offline.
If
we
want
to
get
into
specific
examples
to
share
on
this,
so
I'm
going
to
move
down
into
some
of
the
the
differences
here.
A
So
as
a
reminder
proposal
number
one
is
really
about
storing
relations
chips
in
a
bi-directional
fashion
in
database
tables
and
I
know,
leaving
you
know,
there's
more
than
two
database
tables.
I
was
trying
to
simplify
it
here,
because
the
relationships
are
only
were
they
stored
in
two,
because
we
basically
you're
this.
The
proposal
here
is
to
have
a
relationship
definition
that
actually
stores
the
specific
relationships
or
the
relationship
table.
A
With
are
there
any
questions
about
that
concept
just
at
a
high
level,
so
I'm
kind
of
I've
only
covered
like
these
first
two
bullets
here
want
to
make
sure
that
others
understand
the
the
proposal
here
at
a
high
level
and
I
see.
We've
got
some
comments
down
here
that
have
come
in
on
aundrea.
Thank
you,
you're,
adding
some
some
notes
into
here.
A
Okay,
that
the
relationship
type
is
is
strictly
defined
and
configured
in
both
approaches,
depending
it's
just
a
different
place
where
you're
configuring
it
deleting
an
entity
will
clean
up
its
relationships
because
of
that
strong
typing
I
mean
as
Andre
as
you
noted.
There's.
That
may
not
always
be
what
you
want
or
expect
and
I
agree
with
that
that
that
we
would
have
to
be
careful
about
that,
because
we've
actually
hit
issues
with
these
same
sort
of
strong
linkages
in
the
database.
In
the
past
and
I
guess
debate.
A
The
best
example
I
can
think
of
is
when
we
used
to
have
like
browse
by
tables
in
the
database
layer
and
things
like
communities
to
items
that
relationship
from
the
community
level
down
to
the
item
level.
Sometimes
there's
strong
relationships
between
things
that
were
not
directly
related
caused
us
difficulty,
I'm
and
actually
managing
the
database
layer
and
actually
deleting
things
yeah
I
agree.
G
G
The
ID
of
the
entity
because
you
will
lost
alt
information,
so
the
difference
here
is:
if
you
have
the
authority,
control
intimate
of
the
value
you
can
just
remove
the
authority
key
and
you
keep
your
information.
You
come
the
minimal
information,
but
it's
the
author
name
and
the
position
that
this
string
will
take
in
the
orders
in
the
other
proposal.
You
don't
have
such
such
a
solution.
A
H
Is
it
whether
you
will
automatically
delete
relations
when
you're,
deleting
an
entity
or
whether
you
refuse
to
delete
an
entity,
because
you
have
relations
present
to
that
entity
is
actually
in
a
design
choice,
so
it
doesn't
necessarily
have
to
be
designed
to
delete
automatically
delete
relationships
and
I
wouldn't
advise
doing
that
either.
I
would
rather
say.
Okay,
we
have
this
list
of
relationships
present.
What
do
you
want
to
do
with
them
before
you're
going
to
delete
this
entity?
So
we
don't
have
any
dead
links?
H
B
And
that,
if
you
decide
to
delete
the
object
itself
like,
for
example,
the
author
part
of
that
method
could
be
take
whatever
virtual
metadata
configuration,
you
have
and
place
that
in
the
DC
contributor
field,
as
a
text
file
you
rather
than
and
then
just
you
know,
leaving
it
there,
I
don't
I
mean
I,
don't
want
to
bring
this
to
a
too
high
level
kind
of
discussion,
but
I
mean
an
entity.
Relationship
model
by
definition,
is
what
a
database
was
built
for,
and
we're
talking
about.
B
1970S
here
and
I
find
a
little
strange
that
we're
having
a
discussion
of
okay,
we're
going
to
build
an
entity
relation
model
in
B
space
and
we're
discussing.
Should
we
do
it
in
a
technology
that
is
built
for
entity
relation
models,
or
should
we
do
it
in
a
solar
search
index
and
I'm
currently
still
struggling
quite
a
bit
to
see
why
we
would
deviate
from
what's
been
the
default
to
solve
this
kind
of
problem?
B
Since
you
know
there
are
really
70s
and
why
we're
going
into
all
of
these
smaller
details
and
discussing
things
why
it's
in
good
or
bad
to
have
stronger
relations,
bi-directional
relations,
etc.
I
mean
I,
I'm,
still
really
struggling
to
see
the
point
of
deviating
from
what
is
typically
used
to
solve
this
problem,
to
go
to
something
that
is
not
typically
used
to
solve.
This
bro
I
think.
A
Yeah
and
that's
a
good
point
leave
in
it,
maybe
that's
worth
us
digging
into
because
I
think
what
it
what
it
gets.
That
is
what
is
what
are
we
talking
about
when
we're
talking
about
relationships,
because
I
think
that,
because
we
we
just
already
defined
what
is
a
what
is
an
entity
and
that
all
items
have
an
antitype,
a
single
entity
type,
and
maybe
that's
worth
us
digging
in
here
a
little
bit
on.
What
do
we
mean
about
relationships
because
I
think
that's
one
of
the
key
differences
that
I
see
here.
A
I
agree
with
you
that,
if
relationships
are
these
sort
of
excuse
me,
let
me
mute
a
phone
call
here.
If
relationships
are,
are
these
strong
sort
of
linkages
between
between
database
tables,
then
I
think
you're
completely
correct
that
that's
that's
what
a
database
is
built
for,
but
I
think
what
the
second
proposal
is
actually
showing
is
that
relationships
could
actually
just
be
considered
more
of
an
index
of
data
in
your
database.
A
It
could
be
considered
more
of
a
browse
bias
if
you're
thinking
like
an
author
profile
page,
it
could
more
be
like
it
could
be
this.
It's
the
similar
concept
of
having
a
browse
by
a
specific
author
and
having
things
pop
up
and
that
browse
by
index,
and
then,
if
you're
indexing
things
properly,
then
things
just
pop
into
that
authors
page
without
you
having
to
have
strong
linkages
between
this
author
is
related
strongly
to
all
these
other
things.
B
But
you
can
have
both
so
if
you're
only
going
for
that
weaker
linkage,
you're
actually
saying:
okay,
let's
not
support
or
let's
make
support
for
certain
use
cases
a
bit
more
difficult,
because
we
assume
that
you
know
this
subset
of
used
cases
is
going
to
be
more
common
and
I'm,
not
sure.
If
that
is
necessary,
you
know
you
can
have
a
lot
of
these
things
are
also
indexed
in
solar
as
well
like
the
the
link
I
put
there
at
the
bottom
of
point.
B
G
G
B
G
The
linkage
so
each
it's
a
bit
more
open.
It's
to
me
it's
very
similar
to
when
we
decide
to
have
metadata
in
a
key
video
table
structure
in
stand.
Then
we
have
several
columns
on
the
item
on
the
item
table
so
both
are
on
to
the
base,
of
course,
but
if
we
have
met
the
key
value,
we
can
add
a
the
data.
We
have
more
flexibility.
If
we
decide
for
the
real
database
way
that
should
be
have
additional
column,
it
will
be
a
different
story.
F
G
We
decide
to
use
database
to
store
or
deformation,
because
this
is
the
way
that
the
space
go
and
the
difference
between
the
space
and
fedora,
for
instance,
but
our
domain
don't
allow
us
to
have
so
strong
relation,
because
not
all
author
will
be
entities
not
all
Juna
with
the
entities,
and
we
will
have
author
that
sometime,
our
people
and
sometime
our
working
groups
on
time
are
something
else.
So
I
think
we
need
a
more
flexible
approach
that
is
like
I.
B
Mean
the
database
model
does
not
limit
it
to
student
I
mean
what
you're
saying
is
that
me?
You
can't
have
text
values
and
author
and
sheets
at
the
same
time
with
the
the
database
model.
That's
that's
not
correct.
You
can
have
it.
We
have
implemented
some
examples
to
show
that
the
same
goes
for
having
org
unit
as
an
author.
It
just
depends
on
what
relation
you
define
between
an
org
unit
and
an
author,
and
those
are
not
limitations.
B
A
E
Think
there's
one
one
difference
actually:
okay
models:
I
can
make
all
relations
other
one
also
can
have
unidirectional
links
and,
if
I
put
links
from
both
directions
to
each
other
than
their
protection
again,
so
one
model
can
do
you
need
you
know
external
see,
as
I
can
do
only
bi-directional.
It's
right
or
not.
C
E
A
I
think
you're,
so
yeah
I
think
it's
misstated
here.
This
is
so
proposal.
Two
by
default
would
always
be
unidirectional,
but
you
can
link
them
both
ways.
It
requires
duplication
of
metadata,
so
you
could
do
bi-directional
and
proposal
two
but
you'd
be
duplicating
the
metadata
on
both
on
both
entities.
A
H
Advantage
of
actually
using
by
direction
there's
never
a
disadvantage
of
having
that
in
place.
You
just
follow
the
links
in
the
direction
that
you
are
used,
but
there's
no
need
to
follow
the
links,
all
the
links
or
display
all
the
links
in
in
a
direction.
That's
not
useful
in
your
use
case.
So
that's
one
of
the
things
that
very
implemented
an
example
as
well.
Where
you
have
an
author
having
a
few
hundred
publications,
you
don't
have
to
display
all
those
publications
on
an
altar
page.
H
B
And
when
you
have
like
a
strong,
hierarchical
structure
like,
for
example,
if
you
want
to
represent
the
hierarchy
of
organizational
units-
and
you
have-
and
you
want
to
show
the
part
of
the
tree
or
things
like
that
querying-
and
it's
is
much
easier
and
better
in
in
the
database
solution
rather
than
in
something
that's
based
on
honest
or
I.
Could.
C
Comment
there
at
the
ATH
we
have
a
huge
organizational
database
system
and
to
best
show
that
tree
and
to
best
browser
tree,
we
must
be
able
to
go
by
direction.
We
must
be
able
to
say
that
this
Institute
is
a
child
of
this
other
department.
At
the
same
time,
we
need
to
be
able
to
say
that
the
Institute
is
parent
health.
All
of
the
entities
that
are
underneath
that-
and
these
are
these-
are
entity
relation
into
entity.
Relationships
that
happen
within
the
entity.
E
C
C
If
we
have
just
a
relationship-
and
we
say
that
there
is
a
relationship
between
these
two
entities
and
then
we
have
that
linked
to
the
relationship
type
and
the
relationship
type
is
in
a
separate
table
in
the
proposal
there,
so
that
prepared
that
table
relationship
types
or
it
could
be,
as
is
parent
of
then,
because
you've
got
that
just
in
one
place,
we
don't
have
any
redundancy
of
that
metadata
and
we're
able
to
also
look
it
up
in
the
other
direction.
If
we
want
to,
we
can
say
bring
me
back.
E
C
E
See
duplicated
metadata
because
I
think
it's
another
thing
to
say
this
is
a
child
and
this
is
a
pound
off
then
there's
a
relationship
between
one
is
a
child.
One
is
a
pound
and
with
some
life
left
whips
and
whites
entities
in
the
relationship,
so
I
don't
see
that
supplicating
we
leave
metadata.
Yes,
we
have
two
relationships.
One
thing
this
is
subtract.
The
other
one
is
upon.
This
is
the
direction
yeah.
A
But-
and
it's
also
worth
noting
that
that
you
could
still
do
these
lookups
and
either
option
using
Mike,
solar
and
technically,
you
could
do
and
via
somewhat
complex
database
query
it's
it's
not
it's
not
there's
no
relationship
table,
but
even
in
proposal
number
two.
If
you
know
that
there's
a
parent
to
child,
if
you
say
no
one
object,
is
the
parent
of
another.
You
can
find
the
child
relationship
via
index
and
solar
Orie
by
just
querying
across
the
metadata
value
that
stores
that
parent
relationship,
so
you
can
find
what
are
my?
A
H
G
I
just
want
to
know
that
marker
put
a
very
similar
comment
into
document
and
I
have
also
replied
that,
of
course,
we
can
do
it
query
as
the
way
that
you
described
him
and
if
the
performance
are
an
issue,
we
can
always
improve
to
your
to
the
framework
that
you
introduced
a
separate
call
for
in
terminal
authority
that
would
be
index
seldom
with
a
foreign
key,
as
in
the
other
solution.
Certainly
is
not
really
difference
on
that
between
the
two
solutions.
G
If
we
talk
about
visualization,
keep
in
mind
that
you
will
and
way
school
for
solar
instead
of
database,
there
is
no
real
use
case
where
you
want
to
represent
any
relation
that
is
not
into
direct
into
direct
verse.
If
you
want
to
visualize
an
inverse
relation,
you
are
always
want
to
have
pagination
and
sorting,
and
you
can
for
sure
have
imagination
on
to
the
debase.
But
if
you
want
to
have
sorting
on
metadata,
these
will
not
work
or
will
be
very
slow
on
to
the
debase.
A
F
A
B
Go
ahead
and
think
that
that
is
correct,
like
if
you
would
click
on
the
possible
advantage
just
to
consider
the
link
under
number
four,
you
can
see.
I
mean
it's,
it's
still
indexed
in
the
regular
source
search
index,
and
so
you
can
totally
get
to
so.
Those
two
links
show
how
it's
indexed.
First,
one
is
to
do
a
search
where
you
say
give
me
the
relation
is
author
of
publication
for
a
particular
publication.
A
B
A
A
Would
actually
disagree
there
again,
because
I
think
that
the
thing
that
I
so
I
want
to
hear
everybody's
opinion
here
and
see
what
you
think,
but
the
thing
that
I'm
starting
to
see
here
and
as
I
look
into
this,
because
we're
running
out
of
time,
I'm
just
gonna
jump
into
this.
What
what
I'm
starting
to
realize
myself
is
that
first
off,
our
definition
of
entities
as
being
all
items
have
an
entity
type
essentially
means
to
me
that
we
don't
necessarily
need
even
call
these
entities
we're
just
creating
typed
items.
That's
all
we're
doing
we're.
A
We
have
items
that
all
have
a
type.
That's
the
first
point.
I
want
to
make.
The
second
point,
though,
is
that
if
everything
is
an
item
and
we're
just
typing
these
things
and
treating
them
as
entities
now,
then
in
a
way
we
actually
are
creating
more
of
a
strong
internal
Authority
for
what
these
things
are
and
that's
where
authority
control
to
me
starts
to
actually
make
sense,
because
we're
trying
starting
to
treat
our
you-you
IDs
as
the
authoritative
version.
A
A
So
that's
what
I'm
just
gonna
say
about
that.
I
will
note
that
I
think
that
I've
actually
started
to
come
around
to
proposal
two.
It
was
not
on
my
radar
at
the
beginning,
but
through
week
of
thought
and
looking
at
this
in
more
and
more
detail
I'm
starting
to
lean
heavily
there
unless
I
can
understand
the
reasons
why
we
need
this
strong
relationship
in
the
database.
H
What
you're
here
for
first
thing?
Well,
the
authority
control
is
really
just
plain
text,
so
that
implies
you.
But
what
you
end
up
doing
is
you
break
links
and
if
you're
not
gonna,
have
actual
labels
duplicate
it.
You're
gonna
lose
data.
If
you
just
delete,
for
instance,
a
person
object
and
you
have
a
link
to
an
author
and
well
it's
a
link
to
an
ID
that
doesn't
exist
anymore
with,
as
they
were,
the
text
value
because
you
didn't
want
any
duplication
of
the
labels.
A
H
Be
possible
as
well,
but
the
point
in
general
is:
if
you
just
delete
a
linked
entity
when
you're
using
authority
control,
then
you
have
to
depend
on
searches
and
solar
to
verify
whether
there's
any
other
item
linking
to
this
particular
item
to
verify
what
we're
gonna
do
about
it
and
it's
gonna
be
a
much
higher
risk
of
breaking
functionality
in
your
repository
I
love
this
face,
you
could
do
leave
assaults
on
the
database.
You
don't
need
solo
for
these
queries.
You
could
do
the
same
thing
on
the
database.
H
That's
correct,
but
this
just
gonna
be
a
much
higher
risk
to
break
data
and
to
really
end
up
with
an
item
with
an
author.
That's
gone
and
you
don't
have
a
clue
what
the
author
ever
was.
Unless
you're
gonna
go
back
to
your
package
and
the
second
thing
about
removing
database
tables,
we
did
that
in
particular
for
everything
that
was
search
and
browse
related,
because
if
you're
talking
about
searching
and
browsing,
we
have
a
better
solution
compared
to
doing
all
of
that
manually
in
a
database.
Saur
is
a
search
index.
H
So
definitely,
yes
on
removing
everything
for
search
and
browse
from
the
database
to
solar.
So
that
was
a
good
move,
but
that
doesn't
imply
that
every
relation
and
should
no
longer
be
present
in
a
database,
because
where
do
we
end
up?
Do
we
want
each
person's
no
longer
to
be
connected
to
an
item?
Do
we
want
collections
no
longer
to
be
connected
to
an
item?
Do
we
want
to
lead
all
of
those
relations
and
move
them
to
regular
metadata?
H
There
has
to
be
there's
this
difference
between
building
database
tables,
for
searches
and
having
risks
when
you
delete
something
there
where
the
relation
itself
is
not
really
important,
it's
just
used
to
optimize
searching
versus
having
a
relation.
That's
really
important,
where
you
don't
want
the
relation
to
be
gone
just
because
one
of
the
endpoints
is
no
longer
supposed
to
be
a
person
object,
but
rather
a
string
value,
for
instance,
and
one
about
third
thing
I
was
I
was
actually
saying.
H
I
was
only
gonna
say
two
things,
but
for
the
relations
between
a
use
case,
where
we
have
those
bi-directional
relations
and
are
very
important,
is
it
was
Greg's
use
case
for
the
whole
parent
and
child
relations.
I
noticed
that
that
was
missing
when
we're
talking
about.
We
can
just
query
for
all
the
child
relations
in
solar
and
we're
just
searching
them
and
sorting
them,
and
solar
and
paging
them,
but
I
see
building
an
organizational
structure
and
you're
you
like
you,
don't
want
paging,
you
don't
want
sorting.
H
F
F
G
Was
exactly
communalist,
so
it's
not
you
that
you
can
say
you
don't
want
to
have
pagination
on
that.
The
end
in
this
place,
seven.
Instead
we
say
any
relation
need
to
be
paginate.
It
I
don't
want
to
deal
anymore
with
performance
issue,
so
you
need
to
paginate
everything.
This
is
the.
This
is
the
reality.
H
H
In
the
database
are
actually
also
paginated,
but
you
can
choose
not
to
use
that
stuff
this,
because
the
because
we're
working
with
the
display
seven
rest,
it's
already
paginate
it
by
default,
of
course,
but
the
point
was
particularly:
we
don't
want
search
thing
to
display
all
of
those
children.
You
want
to
be
able
to
display
them
in
order
I.
H
Determining
an
order
so
sort
is
saying:
I
want
to
sort
them
by
name,
but
the
order
is
saying
I
want
to
display
in
the
order
that
they
have
been
entered
or
or
in
a
manual
determined
or
the
deaths.
That's
what
I
was
pointing
out
because
for
organizational
units
you
don't
it
depends
a
bit
on
the
institution,
but
not
every
institution
want
to
display
them
sorted
by
name
or
by
date,
or
something
like
that.
But.
G
G
How
to
maintain
list
of
preferred
publication
prefers
everything
about
the
researcher.
This
is
something
that
exists
in
the
space.
Crease
is
done
just
using
geology
framework,
so
is
not
something
that
is
prevent
or
inter
approached
you
I
would
like
to
move
to
or
to
move
head
to
discussion.
I
just
see
another
major
benefit
I,
just
not
now
so
I
want
to
share
with
you
and
say
what
you
think
using
30
frameworks.
By
the
way
you
will
be
able
to
link
also
community
collection
stream
and
other
displays
of
German
person.
G
H
If
there
is
any
use
case
for
that
is,
of
course,
nothing
that
prevents
the
first
solution
to
do
that,
because
we're
just
talking
about
displaced
object,
IDs
and
all
of
those
have
this
base
object,
ID.
So
there's
nothing
that
prevents
us
to
do
that,
but
we
didn't
have
any
use
cases
for
that
so
far,
so
no
attention.
A
A
Who
else
has
mentioned
this,
but
if
it,
if
both
proposals
meet
all
these
use,
cases
in
some
way
shape
or
form?
It
still
seems
to
me
like
proposal.
2
has
a
lead
in
terms
of
that.
It's
less
work
to
implement
it's
basically
we're
using
code
that
are
exists
and
we're
not
using
stuff
that
already
exists,
and
there
will
be
fixes
that
have
to
happen,
but
it
seems
less
significant
to
me
than
the
amount
of
of
changes
that
would
have
to
happen
in
proposal
1.
C
Using
a
relationship,
curation
or
database
structure
for
managing
these
entity
relationships
is
industry
standard,
since
the
70s
and
I
can
just
see
problems.
When
said,
oh
I
was
actually
shocked
when
I
learned
for
the
first
time
two
weeks
ago,
that
dspace
didn't
have
an
entity
structure
behind
it.
Unfortunately,
haven't
come
across
that
information
until
now
and
I
wondered
how
is
it
possible
that
we've
gotten
through
six
versions
without
having
an
entity
relational
structure,
managed
in
a
database
like
what's
being
proposed
in
the
proposal?
A
Yeah
I
understand
that
Greg
I
guess
I
wanted
to
understand
what
makes
it
simpler
and
what
use
cases
make
it
simpler
and
that's
that's
why
I'm
pointing
at
you,
skews
and
I
think
is
because
I
feel
like
we're
sorry,
I'm
screens
here
in
my
calendar,
I'm
told.
Let
me
stop
screen
sharing
here.
I
need
to
know
it's
checking
to
make
sure
I
didn't
have
another
meeting
bumping
up
against
this.
A
Yes,
those
our
industry
standard
to
store
relationships
between
database
tables
in
that
way,
but
I
think
it
again
goes
to
what
we
define
as
a
relationship
I'm,
not
convinced.
Yet
at
least
not
a
hundred
percent
convinced
that
that
we
need
it
strongly
typed
to
that
to
that
level.
But
I
am
totally
willing
to
be
convinced,
I'm,
just
starting
to
find
myself,
leaning
more
and
more
towards
that
option
and
I'd
like
to
get
a
sense
of
why?
Why
why
that
would
be
a
bad
decision
if
we
went
that
way,
but.
B
I,
don't
understand
why
what
is
different
about
a
relationship
between
two
entities
in
D
space
than
in
other
applications?
That
is
something
that
I
have
a
problem
understanding
and
if
you
redefine
what
is
a
relationship
that
means
that
you're
limiting
yourself
to
particular
assumptions.
So
I
would
like
to
know
what
are
those
assumptions
and
why
do
they
apply
to
D
space
I.
A
Think
I
I
I
mean
I
I,
can't
I
can't
it's
hard
for
me
to
kind
of
put
this
all
into
words
right
here,
but
I
think
that
my
my
in
my
mind
the
data
model
of
these
days.
What
I'm
noticing
here
in
these
two
models,
is
that
the
data
model
of
D
space
actually
could
have
been
supporting
this
all
along
and
actually
already
can
support
this
at
the
level
of.
A
If
we,
if
we
go
with
with
proposal,
it
seems
like
that
model
actually
already
supports
the
idea
of
being
able
to
relate
together
items
and
being
able
to
to
start
to
build
linkages
between
objects
and
I.
Guess
what
I'm
wondering
in
my
mind
is:
why
are
the
relationships
within
dspace
that
much
different
from
authority
control.
A
A
If
we
can
clarify
why
it's
different
from
authority
control,
then
then
that
will
probably
convince
me
to
be
totally
Frank,
but
but
just
looking
at
how
dspace
relays
itself
to
external
objects
through
orchid
and
things
like
that
that
exists
and
other
sort
of
systems,
that's
all
done
through
authority
control,
I'm,
just
trying
to
understand
why
why
an
internal
relationship
could
not
be
the
same
as
the
authority
role?
What
is
the
key
use
cases
and
needs
and
assumptions
that
I'm
missing
here
you
know:
does
that
make
sense,
yeah,
I.
B
Mean
I
think
it's
just
a
jump
that's
made
in
in
in
the
the
reasoning
it's
like.
Okay,
we
can
have
performance
issues
in
certain
cases
when
if
we
would
store
it
as
bi-directional
in
a
database,
so
let's
move
it
to
solar,
where
the
approach
we've
taken
before,
like
you
said
with
the
Browse
tables,
is
to
have
that
also
indexed
and
solar
and
that's
what
proposal?
One
also
does
it
keeps.
This
is
the
strong
linkage
in
the
database.
B
But
if
you
need
to
query
you
need
to
query
it,
you
can
go
to
solar
and
you
have
it
in
the
standard
solar
index
and
not
a
second
solar
index,
which
already
exists
as
a
form
of
authority
control,
but
I
think
I
feel
that
that
we're
stretching
the
concept
of
authority
control
to
do
something
that
can
be
done
through
a
relational
database
in
combination
with
the
regular
solar
index.
So
I
think
that
we're
you
know
taking
that
performance
case
and
make
a
jump
to
something
that
there's
a
jump
too
far.
I.
G
Want
to
add
another
perspective
also
what
will
happen
if
we
are
wrong
today
with
the
decision?
If
we
go
for
approach
to
approach
one
we
go
to
introduce
new,
introduce
new
structure,
we
will
make
some
change
into
the
base
and
if
we
need
to
go
back,
these
need
to
be
rolled
back
and
restored
until
it
will
be
discussion.
If
we
go
for
approach
2
and
we
are
not
satisfied,
no
no
one
stopped
asked
to
make
approach
1
in
the
next
step,
so
approach
to
don't
have
any
hover
ad
is
on
most
year.
G
C
This
just
delay
is
inevitable
that
we
would
eventually
have
this
face
going
to
the
correct
approach
of
related
entity
relationships
stored
in
the
database.
The
other
thing
that
I
don't
know
much
about
the
authority
control,
so
I,
don't
know
whether
it
works
in
exactly
the
same
way
as
a
relational
database
structure.
A
Yeah,
it's
still
stored
in
the
relational
database,
but
it's
not
yeah.
It's
not
necessarily
in
a
normalized
database
relationship
structure,
but
a
lot
of
our
metadata
isn't
in
that
way
either.
So
so
yeah
I,
guess
yeah.
It's
it's
good
points
and
well
well
taken
Greg,
I'm
noticing,
where
we're
over
time
here,
and
we
probably
need
to
wrap
this
up.
I
think
what
I'm
going
to
have
to
do
here
is
we're.
Gonna
have
to
call
it
another
meeting
here
does
next
week.
A
A
I
can't
do
Mondays
or
Monday
this
next
Monday,
okay,
I'll
do
a
doodle
poll
and
send
it
out
to
everybody
rather
than
keeping
everybody
online
here
and
send
it
out
on
the
slack
channel,
make
sure
you're
on
the
entities
WG
slack
channel,
because
that's
where
we're
doing
all
other
discussion,
I'll
I'll,
get
out
a
doodle
poll
and
we'll
call
another
meeting
in
the
next
couple
weeks.
Here.
A
I
think
that
this
our
key
point
of
disagreement
is
still
around
weather
authority
control
is
better
used
here
or
whether
putting
this
in
the
in
a
relational
table
is
the
better
way
to
manage
relationships.
So
I
think
I'd
like
us
to
try
and
dig
deeper
there
on
some
of
the
the
use
cases
and
purposes
and
needs
and
benefits
of
either
approach
because
I
admit
I'm
still
not
getting
enough
out
of
out
of
the
the
points
made
to
understand
why
we
need
to
go
with
one
approach
over
the
other
myself.
A
So
maybe
it's
my
only
me
but
I'm,
assuming
it's
it's
probably
just
as
unclear
to
others
as
well.
So
that's
that
would
be
our
goal
for
the
next
week
or
so.
I
will
start
to
write
up
the
notes
from
this
meeting
right
after
this
and
update
them
in
the
Google
Doc
and
see
if
I
can
figure
out
a
way
to
structure
that
so
that
we
can
add
more
details
and
use
cases
and
and
and
and
description
around,
why?
Why
use
authority
versus?
Why
use
the
relational
tables?
But
thank
you
all
for
your
time.
A
F
Of
suggestions,
the
first
one
is
that
those
who
actively
participate
in
the
discussion
know
perfectly
well
both
approaches,
including
the
authority
framework.
If
not,
we
are
just
discussing
about
a
lot
of
useless
things,
and
the
second
one
is
that
we
fix
a
day
and
at
time
for
the
meetings
as
it
is
for
all
the
rest
of
the
space
engagements.
So
we
don't
have
to
doodle
it
every
time.
Maybe
it's
not
every
week,
but
when
it
is,
it
is
on
a
precise
date
and
time.
So
we
know
it's
in
advance.
Yeah.
A
I
agree:
I
was
going
to
do
that
in
that
doodle
poll
is
to
set
that
as
our
final
date
and
time,
because
I
it
has
been
difficult
to
find
times
to
fit
this
in,
but
I'll
that'll
be
part
of
the
doodle
poll.
Is
that
we're
gonna?
Have
it
on
that
regular
time,
just
decided
by
the
doodle
poll
and
we'll
continue
to
have
that
on
that
schedule?
Thank
You,
Suzanne
yeah!
Thank
you
very
much.
Yep,
okay,
I'll!
Let
everybody
go
now.