►
From YouTube: 2018-03-23 Meeting of the DSpace Entities Working Group
A
Okay,
just
a
couple
days
ago
here
on
the
21st
to
to
go
through
the
D
space
entities,
overview
discussion,
document
that
I'm
sure
you've
all
reviewed.
If
you're
here
in
this
meeting
and
specifically
kind
of
look
a
little
bit
more
closely,
the
new
option
number
three
that
that
at
Meier
proposed
as
an
alternative
to
the
other
two
that
we're
already
there
and
leavin'
gave
a
nice
presentation
to
steering
in
terms
of
going
through
what
their
proposal
is
and
a
little
bit
more
detail
and
kind
of
walking
through
how
this
might
work.
A
And
it
was
suggested
that
we'd
also
try
and
do
that
same
sort
of
thing
here
with
this
group.
So
others
could
get
a
sense
of
of
what
this
proposal
entails,
because
there
was
a
lot
of
steering
saw
a
lot
of
promise
out
of
this
proposal.
There's
no
approval
of
any
one
proposal,
but
there's
a
good
amount
of
promise
that
they
asked
for
us
to
kind
of
take
a
look
at
this
in
a
more
detail
and
and
get
some
more
feedback
from
the
community
and
see
whether
this
seems
like
a
good
route.
A
C
D
C
This
discussion
discussion
wasn't
finished,
so
today
we
are
currently
we
are
going
to
do
to
focus
on
on
this.
We
are
going
to
continue
this
discussion,
so
the
our
agenda
is
our
proposal
at
Meyer's
proposal
at
mars.
Proposal
is
based
on
the
portland
common
data
model
and
if
he
had
time
to
discuss,
I
wish
we
had
time
to
discuss
certain
and
bottom
at
strategies
based
on
what
we
have
speak
spoke
till
now,.
C
C
C
Crease
did
with
there
not
not
not
isn't
only
based
on
that,
but
is
based
on
what
is
best
crease
did
to
to
this
two
and
their
data
model,
metadata
value,
to
support
numeric
text
date,
values
or
can
be
even
extended
to
to
have
other
types
of
types
of
metadata
value
types,
and
one
of
those
types
is
the
entity
type,
and
this
enables
the
relationship
between
you
know
or
in
in
the
metadata
level.
It
enables
the
direct
relation
with
entities
and
some
core
entities
like
outsource
organization,
that
they
are
that
specific.
C
Behaviors
and
one
generic
entity
that
have
common
ever
for
entities
that
instance
this
structure
to
have
entities
in
this
space,
we
think
we
need,
as
I
said,
the
type
of
that
this
base
object.
We
here
we
will
have
a
bit
stream
which
is
0-3.
Could
this
is
something
that
was
abandoned
and
we
think
it
should
exist
in
in
the
space
object.
C
C
C
C
C
C
C
But
we
will
have
events,
for
instance,
location,
something
like
that,
and
they
all
need
to
be
specified
and
we
think
that
could
we
could
use
a
specific
schema
inside
to
to
store
that
data,
then
the
at
the
metadata
value
level
we
think
that
week
it
could
be
enhanced,
so
we
proposed
here
normalization
and
the
introduction
of
specific
type
fields,
specific
metadata
types
like
text
date,
something
like
that
and
one
other
important
type.
It's
the
the
entity
type
or
relation
type.
It
can
relate
and
metadata
field
with
an
entity,
and
we
can
expose
something
like
this.
C
C
C
Metadata
can
relate
entities
and
we
introduced
some
default
entities
like
authors
organizations
and
give
room
to
two
dynamic
entities
that
share
the
same
behavior.
But
we
aren't
currently-
and
this
is
a
proposal
it
was
fought
and
based
on
the
display
screens
model
and
other
platforms
that
we
know,
and
we
aren't
completely
sure
if
we
could.
It
can
be
accomplished
with
much
easier
way
so
saying
this
I
think
I
can
handle
the
the
presentation
to
to
Livan
for
him
to
show
us
what
he
did
or
thought
color.
A
C
E
Suppose
is
talking
regarding,
because
is
of
authors
and
organisations
that
we
can
already
have
as
created
structure
instead
of
having
to
ticket
structures
here
and
then
have
flexible.
This
object
instead
of
that
starving,
dynamic
objects
and
we
create
dynamic
structure
of
what
we
need.
I
think
that's
the
point.
D
F
I
liked
it
here
to
have
some
more
important
entity
in
the
model
it
will
be
returned
to
audit
organization
and
have
some
generic
entity.
Is
this
similar
to
what
exists
in
this
place?
Chris
I
think
that
this
will
learn
to
think
simple
for
some
behavior,
because
you
are
explicitly
author
organization.
You
can
make
some
really
custom
for
this
entity,
so
there
are
feces.
F
The
the
other
thing
is
you
can
try
to
partitioning
your
beta
so
to
split
your
information
in
different
table.
Of
course
you
can
do
that
in
a
several
way.
You
can
also
think
that
the
database
will
help
you
reading
partition
and
table
and
thing
like
that.
But
if
you
leave
this
stuff
to
to
database,
it
strongly
dependent
DBMS
engine
that
you
got
to
use
so
pasta.
Sauce
is
some
solution
or
it
isn't
much
more
difficult
to
to
manage.
F
So
honestly,
I
like
to
presentation
the
proposal
from
Erica
I
think
that
it
is
really
in
line
with
what
really
this
base
Chris
provide
right
now
in
some
way.
I
think
also,
that
is
an
evolution
of
this
base,
Chris
in
a
more
natural
T
space
fashion,
because
it
is
basically
much
more
on
to
metadata
and
existent
concept
of
the
space.
This
is
something
that
we
was
not
able
to
do
immediately
in
this
base,
Chris,
for
instance,
because
this
stuff
was
not
yet
ready
when
this
base
Chris
born.
F
So,
for
instance,
metadata
for
all
was
introduced
later
is
not
blessed
when
his
basic
restart
and
also
I
can't
have
a
proposal
to
introduce
some
of
the
key
change
that
this
basically
introduced,
namely
the
possibility
to
manage
different
type
of
value
so
that
you
have
reference
to
other
entity.
You
have
data,
you
have
string
your
number.
This
is
not
something
that
you
have
in
the
basic
space
model
and
also
the
slide.
F
Will
you
show
the
ability
to
expose
over
image,
for
instance,
complex
structure,
it
is
very
nice
is
something
that
you
can
do,
or
with
this
place.
Chris
structure
to
only
think
here
is
the
difficult
part
is
intimate
age.
So
what
I
want
to
be
sure
is
that
all
of
us
agree
and
understood
that
what
we
are
going
to
present
required
a
lot
of
effort.
F
I,
don't
think
that
this
effort
is
a
misleading
time
of
day
it's
much
more.
So
this
is
a
very
nice
stuff.
Is
I
didn't
if
we
have
a
poor
to
achieve
this
result
in
this
term
with
all
this
capability,
it
could
be
also
an
improvement,
an
improvement
about
respect
what
we
have
in
this
basic
list
right
now,
but
this
is
not
something
that
you
can
do
immediately
is
not
a
six-month
project
is
not
a
one-year
project.
F
D
Know
that
deal
that
touched
another
thought
that
I
had
that.
You
know
you
know,
rather
than
having
ten
different,
you
know
tables
for
ten
different
kinds
of
metadata.
We
should
do
you
know
what
the
type
is.
We
could
do,
serialize
it
into
a
blob,
and
then
we
know
what
to
be
serialized
when
it
back
I,
don't
know
whether
that
would
be
more
or
less
performant
than
the
other
way.
A
Yeah
I
didn't
care
just
probably
not
to
dig
too
deeply
into
implementation.
I
mean
it's
important
to
get
an
understanding
of
these
proposals,
but
I
I'm
real
our
time
here.
Yeah.
We
have
plenty
of
time
for
the
other
stuff,
but
it's
a
good
good
point.
Marc
I
don't
mean
to
cut
you
off
I,
just
don't
know
that
we
need
the
answer.
Every
single
little
tiny
question
on
this
right
now,
the.
G
Or
I
should
have
pressed
unmute
before
I
started,
sharing
my
screen.
Okay,
so
yeah
I
agree
with
Andrea
about
especially
about
the
concern
for
time,
because
this
talks
about
how
you
do
things,
then
in
the
backend,
how
you
structure
the
database,
but
for
each
new
entity
we
create.
We
have
to
create
separate
ways
in
the
in
the
UI
to
view
them
to
make
sure
that
they're
in
the
search,
etc,
etcetera,
typed
metadata,
is
also
a
good
thing
to
have
I'm.
G
G
So
that
was
a
very
important
starting
point
for
us
for
creating
our
proposal.
So
you
will
see
some
things
that
are
not
in
this
proposal
that
are,
in
others,
such
as
their
article
metadata
or
tied
to
metadata.
But
that
is
for
the
sole
reason
to
that.
We
want
to
keep
the
effort
doable
on
the
short
term
and
be
able
to
have
something
in
the
space
7.
G
That
is
usable
that
can
move
us
forward
so
I'm
quickly,
as
only
eight
or
nine
slides,
quickly
going
to
talk
about
entity
types
and
relations,
how
it
configure
the
data
model,
how
to
do
the
storage
in
a
database.
What
is
the
impact
on
Java,
how
we
can
reuse
current
functionality
in
D
space
and
then
at
the
end,
I'll
go
into
the
Chris
models
more
specifically,
and
we
have
some
work
estimates
of
how
much
work
this
would
require.
G
Reason
to
have
more
configurable
entities
in
D
space,
but
no
it's
not
Chris
entities
that
so
this.
This
whole
exercise
should
not
be
about
just
Chris
objects,
but
about
adding
more
different
types
of
objects
to
D
space.
So
the
first
part
only
talks
about
that
so
entity
types
and
relations.
What
we
try
in
that
sense
to
do
is
to
avoid
hard
coding
a
particular
object
model
so
to
have
a
class
in
there.
G
That
says
author
profile,
it's
something
that
we
would
like
to
avoid
because
it
is
applicable
yes
in
the
Chris
context,
but,
for
example,
and
I'll
use
one
of
for
science
as
examples
the
T
space,
glam
add-on
doesn't
probably
not
have
an
author
profile,
but
it
has
different
kinds
of
objects.
You
might
think
about
data
repositories
where
you
want
a
data
set
that
you
want
to
relate
to
a
publication
and
have
a
separate
page
for
data
sets
not
just
have
it
be
as
a
bit
stream.
There
are
several
other
examples
you
can
think
of.
G
Besides
the
Chris
data
model
and
who
is
loosely
based
on
the
portland
common
data
model,
just
a
very
quick
graph,
it's
a
very
simple
one
where
you
have
a
collection,
an
object
on
a
file
and
objects
can
have
relations
to
each
other
collections
as
well.
Collections
can
have
that
can
be
your
articles,
so
they
can
be
put
in
hierarchical
fashion.
Wood
has
member
halation,
and
here
you
have-
has
member
and
has
related
object
for
objects.
G
So
this
is
how
you
make
relations
between
different
entities,
so
what
we
would
propose
is
to
have
the
data
model
itself
be
configurable.
One
of
the
other
important
reasons
to
do.
That
is
to
also
not
put
more
burden
or
complexity
in
repositories
that
do
not
necessarily
require
more
complex
object
models.
G
So
you
have
a
publication
on
a
person
and
then
you
have
the
labels
or
types
for
the
relationship,
it's
all
through
publications,
publication
of
author
and
then
defining
the
cardinality.
So
it's
a
very
simple
way
of
configuring.
The
data
model,
the
database
storage,
the
type
of
entity,
would
be
stored
in
the
item
table.
G
We
would
have
one
new
table
that
is
needed
to
store
the
relationships
between
the
objects.
So
we
have
one
row
in
that
table
per
relationship
type
from
the
XML
that
I
showed
earlier.
So
one
role
for
each
of
these,
and
so
for
the
Chris
model.
For
example,
it
only
results
in
a
small
table
of
six
rows
very
low
complexity.
G
So
that
means
that
we
also
have
a
very
low
impact
in
Java.
We
just
need
some
classes
to
retrieve
the
relationship
schema
to
be
able
to
identify
the
type
of
the
item
that
you're
looking
at
and
to
be
able
to
identify
which
relations
we
can
create
for
the
current
items
type.
So,
if
you're
looking
at
a
particular
item
type
which,
with
which
other
items
can
you
make
relationships
and
then
rich,
be
able
to
retrieve
all
of
the
current
relationships
for
a
particular
item
that
you
are
looking
at.
G
So
how
does
this
reuse
current
functionality?
I
have
a
few
examples
here
in
the
document
that's
linked
at
the
bottom.
That's
also
linked
in
Tim's
overview,
there's
a
more
elaborate
coverage
of
some
functionalities
in
dspace,
but
by
using
the
item
we
basically
have
the
opportunity
to
reuse
any
functionality
that
currently
exists
for
items,
for
example
to
be
able
to
configure
input
forms
and
to
build
input,
forms
for
a
specific
entity
type.
You
can
just
reuse.
The
current
input
forms
dot,
xml
functionality
you
can
already
search.
G
So
let's
say
we
would
have
this
solution:
the
default
discovery,
d,
space
search,
searches
across
all
entities,
and
if
you
have,
for
example,
the
entity
type
as
a
facet
of
filter
facet,
your
Sergi,
you
can
filter
on
the
different
entity
types,
but
you
don't
need
to
actually
alter
the
current
search
functionality
batch
import.
So
it's
also
very
easy
to
add
the
functionality
we
need
for
the
batch
import.
It's
just
a
matter
of
also
importing
the
item
type
and
then
just
expanding
it
for
only
the
relationships
between
the
item
types
that
are
possible.
G
There's
some
more
examples
like
I
said
entered
documents,
but
this
is
one
of
the
main
points
is
to
reuse
a
lot
of
the
current
functionality,
which
also
have
as
the
additional
benefit
that,
if
in
future
releases
or
in
next
steps
in
this
implementation,
we
would,
for
example,
say
we
want
to
add
her
article
metadata.
If
we
do
it
for
the
items,
then
it's
immediately
available
for
all
entity
types
if
we
would,
for
example,
decide
to
make
the
input
forms
configurable
in
the
UI
as
displays
Chris
does,
for
example,
it's
immediately
available
for
everything.
G
So
in
that
sense
it's
a
little
bit.
It
takes
a
bit
from
both
these
basic
risks
and
from
our
Cubs
proposal,
but
tries
to
minimize
the
effort
as
much
as
possible
to
make
this
achievable
within
the
time
frame
up,
for
example,
these,
please
them
now.
How
would
we
configure
a
Chris
model
with
this?
You
have
a
very
simple
XML
configuration.
You
just
define
the
six
relationships
that
you
need,
which
comes
down
to
an
XML
file
of
only
75
lines.
It's
included
in
that
document
that
was
linked
or
that
you
can
get
to
from
Tim's
overview.
G
He's
literally
used
for
the
just
wants
a
simple,
I
or
use
case.
You
don't
want
any
of
the
cris
entities.
You're,
not
interested
in
that.
It's
just.
You
know
a
repository
to
serve
images
from
some
image
archive
that
you
have
and
you
don't
really
care
about
projects
or
whatever,
and
you
don't
configure
the
automatic
Chris
model
or
another
model.
G
So
a
maven
build
parameter,
for
example,
that
automatically
pulls
in
or
uses
that
configuration
file
to
define
your
Chris
relationships
and
the
XML
and
would,
for
example,
automatically
creates
collections
for
people
projects
and
organizational
units,
and
you
attach
input
forms
to
those
collections
so
that
you
have
a
collection
where
you
can
store
your
projects
and
that
there
is
a
metadata
profile
associated
with
it.
That
you
have
your
input,
forms
ready
for
that.
G
An
automatic
creation
of
certain
search
configuration
like
the
facets,
specific
to
those
entities
that
you're
adding
people,
projects
or
units
an
automatic
creation
of
item
display
pages.
There's
some
information
at
a
document
again
about
how
we
do
how
we
would
propose
to
do
that
for
d
space
7,
and
by
doing
that,
you
kind
of
have
Cris
functionality,
supported,
out-of-the-box
and
other
people
who
don't
want
it.
Don't
have
it
out
of
the
box
and
we
have
the
opportunity
and
that's
even
more
important,
to
add
other
data
models
as
well
and
make
these
base
more
flexible.
G
In
that
regard,
then,
maybe
the
most
important
slide.
So
this
is
an
estimate
that
we
created
to
be
able
to
get
to
this
kind
of
implementation.
And
if
you
sum
up
the
values
here,
we're
talking
about
15
days
of
work
for
the
generic
model
and
15
days
to
actually
implement
to
the
Cris
use
case
more
or
less
than
16,
maybe
17.
But
so
this
is
all
achievable
within
a
time
frame
of
less
than
two
months.
If
there
is
only
one
FTE
available
to
do
this
work.
G
So
it's
a
very
short
time
frame,
a
short
implementation,
and
it
is
kept
specifically
this
way
so
that
we
can
expand
on
it
later
on
and
add
some
of
the
features
that
we've
seen
in
the
other
proposals,
like
our
Chrome
metadata,
I'm
like
to
type
like
type
metadata,
for
example,
and
add
them
over
time,
but
still
have
something
that
would
work
immediately
and
where
you
could
immediately
add
new
entity
and
have
a
representation
of
the
Chris
model.
And
you
can
decide
as
your
as
the
user
of
your
upholstery.
G
C
Like
your
your
approach
and
to
me
I
like
to
the
implementation
acts
but
perspective
of
it,
and
also
the
idea
of
having,
for
instance,
and
now
for
sharing
collection,
the
same
question
with
an
item,
it
can
be
possible
within
this
model,
I
think
but
but
but
I
like
it.
I
like
and
I
think
what
you
just
said
it.
It
is
open
to
add
other
requirements
like
them:
you're
a
hierarchical
made,
metadata
metadata
and
it's
not
closed
and
reuses
the
cord
space
to
to
accomplish
that.
G
Yeah-
and
maybe
that
was
one
thing
I
forgot
to
highlight-
which
I
think
is
also
on
an
important
aspect
of
this
proposal-
is
the
learning
curve
for
anyone
who
knows
these
space
today
is
very
low,
and
it's
very
simple
to
understand
and
to
start
working
with
this
this
model,
because
it
reuses
almost
all
of
the
functionality
that
exists
in
these
space,
so
anyone
can
very
quickly
start
working
with
it.
Yes,
I.
C
Just
every
one
or
two
issues
regarding
the,
for
instance,
this
space
crease
implemented
some
of
I,
don't
know
I,
don't
remember
what
they
call
him.
Let
me
see
if
I
here
see
first
class
entities,
those
entities
have
some
specific
behavior.
I.
Don't
know
at
this
point.
If
the
data
model
is
the
solution
to
to
have
that
specific
behavior,
but
this
could
be
a
requirement
or
something
like
that.
D
C
To
behave
yes,
you
are
correct,
but
if
you
need
a
couple
of
things
to
help
you
doing
that
behavior
accomplish
that
behavior
in
the
data
model.
I
don't
know
for
now.
If
did
this
is
the
right
solution,
but,
like
I
said
before
I
don't
know
if
the
data
model
is
the
solution
for
supporting
specific
behavior.
C
G
That's
true
what
mark
says:
I
mean
the
implementation
for
a
specific
behavior
for
a
specific
entity
might
be
slightly
easier
to
accomplish
if
you
have
that
entity
as
a
hard-coded
object
in
your
implementation,
but
it's
not
that
much
more
work
to
base
it
on
the
type
of
item
that
you
would
be
dealing
with.
So
it's
it's
it's
an
extra
step.
Yes,
but
it's
not
that
much
more
complex
and
it
gives
you
a
lot
more
flexibility.
Basically
I
mean
it's.
It
gets
a
little
bit
of
a
trade-off.
F
F
Sir,
please
keep
in
mind
that
on
this
base
Chris
you
have
some
fierce
citizen,
as
always
a,
but
we
also
have
a
dynamic
entity
that
can
be
whatever
you
want
when
we
need
to
implement
something
that
apply
to
the
dynamic
entity.
It
is
much
more
complex
than
what
we
need
to
implement
just
for
older
or
for
organization,
and
so
our
experience
on
currently
on
this
base,
Chris
I,
don't
want
to
force
too
much
is
just
reporting
what
we
have
observed.
F
G
G
It
mean
even
in
this
model,
it's
not
unthinkable
that
we
would
add
a
first-class
entity,
as
you
said,
for
example,
person.
It's
not
impossible,
it's
not
unthinkable.
If
we
use
one
or
two
different
examples,
then
we
can
in
detail
discuss
what
the
implication
would
be
for
one
or
the
other
model
and
then
see
what
you
know.
It
will
help
to
to
decide
where
the
balance
point
in
that
trade-off.
I
will.
C
G
A
I
worry
we're
getting
way
too
far
down
a
rabbit
hole.
If
we
go
down
this
discussion,
I
think
there's
several
ways
that
could
be
achieved
and
Mark
and
I
think
actually
mostly
agree
to
some
extent.
Just
disagree
about
implementation
details
which
I
don't
know.
That
is
worth
our
time
to
dig
into
right
now,
I'd
much
rather
trying.
B
A
H
H
And
then
we
have
communities
collections
and
bundles
and
I'm
a
little
bit
afraid
that
we
will
be
able
to
do
a
lot
of
things.
Was
it
with
the
entities
that
somehow
comes
from
from
the
item
class
we
currently
have
and
that
we
won't
be
able
to
do
the
same
things
with
the
community's
collections
and
bundles?
So,
for
example,
when
we
introduced
the
metadata
for
all,
we
got
which
ability
in
the
back
end,
but
we
are
still
missing
the
same
abilities
in
the
front
end.
H
So
we
cannot
really
use
the
metadata
for
or
for
the
communities
or
collections
currently
because
of
front-end
and
again
taking
the
item
and
ignoring
the
community
collections
are
a
little
bit
of
frets
will
add
the
similar
situation
in
which
we
then
would
be
able
to
do
a
lot
of
stuff
with
entities
except
community's
collections
and
bundles.
So
what
I'm
asking
myself
is?
F
So
there
is
more.
This
is
just
a
fifth
step.
The
proposal
a
is
a
sequence
of
different
step
to
build
the
full
system
as
progressive
improvements,
but
there
is
lot
of
reuse
of
existing
code,
but
I
think
it
the
same
reuse
and
most
the
same
views
can
be
done
also
using
tear
cut
proposal,
for
instance.
So
for
just
let
you
know
in
this
p7,
we
already
have
reused
some
concept
of
the
item
to
provide
that
metadata
for
to
be
stream
in
the
code
that
we
have
want
to
master.
F
F
F
Yes,
I
don't
want
to
go
into
the
tail,
but
please
keep
in
mind
that
the
tail
will
be
take
that
we'll
get
50
day
just
to
discuss
mass
today
we
will
spend
a
lot
of
time
just
to
discuss
about
to
the
tale
much
more
than
what
we
expect
for
implementation.
The
implementation
time
that
I
team
was
presented
in
the
last
proposal
is
what
happened
if
you
have
just
one
director
that
say
you
need
to
implement
this
thing
in
this
way.
F
F
The
thing
is:
if
you
want
to
link
user
and
auto,
you
can
do
that.
The
name
leave
in
every
case,
using
whatever
solution
do
you
want,
but
if
we
want
to
enforce
some
rule
at
the
base
level
having
a
separate
table
it
will
be.
Much
is
much
more
easy
and
useful,
and
this
same
assumption
is
related
to
the
difference
between
collection
and
item.
I
see
I
need
to
have
a
different
of
them.
It
is
just
a
collection.
F
Maybe
we
don't
need
a
community
collection,
because
commuting
collection
have
a
clear
scope
in
the
digital
libraries
and
in
digital
object
world.
In
some
way,
when
you
talk
about
collection
of
digital
object,
you
expect
to
a
specific
role
for
reservation,
for
responsibility
about
the
content,
so
collection.
If
the
digital
library
work
means
something
very
specific,
and
we
cannot
mix
this
collection
concept
with
the
Elven
partment,
because
if
you
we
think
that
we
need
to
have
a
collection
as
a
department
where
we
want
to
put
person.
F
We
have
an
issue
here,
because
it's
a
case,
the
department
is
a
collection.
In
other
case,
as
you
want
to
link
the
departmental
as
the
founder
of
an
item,
it
will
become
an
item
so
if
we
are
from
liquidus
into
the
modernity
that
there
is
something
brought
also
bundle.
Mb
stream
are
very
important
and
are
related
to
the
fact
that
we
are
talking
about
digital
object
and
full
text.
For
instance,
we
want
to
be
able
to
add
additional
technical
metadata.
F
We
want
to
have
the
preservation
feature
so
that
you
can
decide
that
the
original
content
is
stored
in
a
very
safe
place
and
Pamela
are
stored
in
a
bundle
that
is
associated
with
an
ephemeral
storage.
And
if
you
go
see
if
you
can
just
rebuild
stuff,
so
it
is
useful
to
have
some
concrete
entity
in
the
model
and
I
think
that
actually,
the
space
have
the
right
entity
just
for
digital
libraries,
but
means
the
entity
for
the
context
object.
F
So
I,
like
TD
of
cat,
but
also
a
smile,
is
very
similar
to
start
from
to
the
space
object
so
that
we
have
two
metadata.
We
can
build
on
top
of
that.
I.
Don't
think
that
a
person,
an
ATO
profile,
need
to
stay
in
a
collection,
because
we
don't
need
a
collection
to
represent
what
entity
types.
So
we
are
just
replicate
the
same
concept
in
two
different
place.
There
is
an
indication
of
a
weakness
of
the
data
model.
It
might
be.
H
Think
that's
a
really
good
point.
If
we're
looking
on
the
also
the
items
and
the
collections,
if
we
start
from
the
item
object,
they
always
have
to
have
an
only
collection.
Currently,
if
we
are
starting
from
this
base
object,
we
could
imagine
and
the
teeth
that
don't
have
to
be
in
any
collection
at
all
and
also
might
be
a
good
example
understand.
H
G
They
would
still
need
to
be
in
an
entity
that
describes
who
can
manage
them
and
who
has
who
can
do
what,
with
these
particular
objects
or
items
right
even
for
person
case,
and
so
for
that
reason,
I.
Think
if
you
look
at
the
details
in
the
document,
one
of
the
things
that
we
were
leaning
more
towards
was
that
if
you
set
up
a
collection
for
to
manage
persons
that
that
collection
would
be
hidden,
it
would
not
be
shown
in
communities
and
collection
Street.
G
But
you
do
need
to
group
them
in
some
kind
of
context
in
order
to
have
a
workflow
in
order
to
have
a
submission
in
order
to
have
some
authorization
for
who
can
can
edit
these.
So
it
does
make
sense
to
put
them
in
a
collection,
but
it
does
not
necessarily
make
sense
to
put
them
in
a
collection
as
being
a
department
or
an
organizational
unit.
But.
G
A
G
Versus
person,
but
we
do
have
resource
policies,
but
yes,
then
you
can't,
then
you
have
to
manage
them
on
a
person
level
on
an
individual
person
level,
and
you
can't
do
that
on
a
group.
Now
that
being
said,
collection
as
it
exists
currently
in
d
space
might
not
be
ideal
for
this
and
and
I
think
we
need
to
have
more
iterations
on
this
flexible
data
model
over
the
next
few
versions
of
D
space.
G
A
Yeah
I
think
I'd
like
to
get
back
to
that
core
sort
of
difference
between
the
arc
app
proposal
and
the
at
Meier
one
here,
because
I
think
there
is
a
lot
of
similarities
and
the
questions
folks
are
asking
are
very
good
ones.
Like
should,
should
these
entities
be
at
the
item
level,
should
they
be
at
the
dc-based
object
level?
I
think
those
are
all
great
questions,
but
the
big
core
difference
is
in
resourcing
and
the
amount
of
time
it
would
take
to
get
it
done.
A
A
Then,
yes,
the
model
could
move
with
it,
and
entities
could
become
G
space
objects
instead
of
specifically
items,
but
we're
doing
it
a
staged
approach
rather
than
trying
to
refactor
the
entire
data
model
all
at
once,
but
I
think
there
could
be
a
way
forward
here
that
we
start
with
the
at
Mayer
model
and
move
towards
the
archive
to
some
extent
and
find
the
best
of
both
worlds
here.
I
just
want
to
make
sure
that
we're
realizing
that
we
don't
have
unlimited
resources.
A
We
also
don't
really
have
unlimited
time
here,
because
we
have
people
who
want
this
basically
today
in
order
to
meet
needs
of
like
open-air
version,
4
that's
coming
out
in
terms
of
European
requirements
and
not
just
European
requirements
but
starting
there.
So
I
think
there's
a
lot
of
key
factors
here
that
we
need
to
be
considering
in
this
decision
and
how
we
can
move
this
forward.
That's
all
I
wanted
to
say
with
that.
F
Tim,
please
keep
in
mind
that
the
ELCA
proposal,
in
my
opinion,
is
not
so
well
presented
as
the
last
one
in
term
of
split
of
work.
Ok,
we
can
go
with
a
proposal,
for
instance,
but
we
are
not
required
to
implement
immediately
meta
data
type
or
here-here
metadata
or
old
stuff,
so
we
can
start
with
in
space
object
and
we
can
decide
that
metadata
time
come
later,
so
there
are
very
similar
I.
Don't
don't
see
these
big
difference
in
effort
for
the
fifth
step,
I.
F
Know
that
the
second
thing
is,
we
need
to
be
really
honest
on
that.
If
you
want
to
have
all
this
functionality
in
place
now,
I,
don't
think
that
both
name
or
the
solution
work
for
you.
If
you
want
to
have
ortho
function
right
that
the
user
request,
you
need
to
go
with
the
space
Chris,
because
this
functionality
is
implemented.
F
I,
don't
try
to
sell
you,
this
piece
Chris,
just
a
big
blur
right
when
we
go
for
this
piece
that
this
piece
that
will
be
very
far
from
what
to
use
on
it,
because
they
need
to
have
the
organ
synchronization.
They
need
to
have
automatic
pool
of
information.
They
need
to
have
the
right
exposure
of
voltage
for
each
information
or
white
image.
F
There
is
a
lot
of
is
not
a
work
of
till
today,
so,
whatever
option
we
go,
we
are
just
making
a
Pfister
tortoise
implementation,
but
is
something
that
we
in
the
best
case
will
result
liked
in
tradition
of
metadata,
for
all
we
are
introducing
for
all
is
a
big
improvement
of
Nauticus
changes
in
two
different
version
of
this
pace.
The
functionality
was
to
say
I
think.
G
We
can't
perfect
those
things
and
I
think
with
any
other,
but
with
the
two
other
proposals
to
get
to
a
first
initial
working
version,
it
would
take
more
time
and
effort,
maybe
not
in
the
case
of
dspace
Chris,
but
then
these
days
Chris
has
the
the
the
disadvantage
that
it's
more
written
as
an
add-on.
So
this
lays
a
little
bit
more.
The
groundwork
that
then
dspace
Chris
can
be
built.
On
top
of
this
is
how
I
see
the.
G
D
A
Yeah
and
I
I
agree
with
that.
I
think
we
still
will
with
metadata
for
all
I
think
the
thing
that's
taken
us
some
time
is
that
we've
had
to
solve
this
user
interface
thing
problem,
which
we
all
are
aware
of
in
terms
of
to
user
interfaces
and
all
that
but
yeah
I
guess
one
other
thing.
I
would
point
out
here
that
I,
actually
I
I,
admit
I
when
I
the
first
time.
I
saw
this
on
this
week,
basically
or
actually
late
last
week,
when
leaving
through
it.
A
My
way,
I
also
had
these
same
questions
about
whether
things
belong
at
the
item
level
in
the
DS
space
object
level
that
folks
are
expressing
here,
which
seems
to
be
one
of
the
key
things
here
and
the
more
I've
thought
about
that
throughout
the
week.
I'm,
actually
not
certain
that
we
want
all
entities
to
be
these
base
objects,
and
that's
just
me
primarily
because
of
the
all
of
the
research
and
stuff
that's
gone
into
the
Portland
common
data
model,
which
I'm
not
sure
how
many
people
are
aware
of
that.
A
But
they
do
specifically
splint
split
out
as
leoben's
noted
collections
from
objects,
and
that
collections
are
a
very
specific
type
of
thing
to
group
things:
it's
not
an
entity,
it's
something
that
actually
is
there
to
to
allow
us
to
build
hierarchies
of
entities
instead
of
being
an
entity
in
itself
and
the
more
I've
been
thinking
through
this
process.
I'm,
actually
not
convinced
that
building
all
this
down
to
the
D
space
object
layer
is
the
right
decision.
It
may
be
in
the
long
term,
but
in
the
short
term.
A
It
brings
me
back
to
whether
or
not
taking
a
first
step
into
the
entity.
Realm
is
worth
doing
at
a
basic
level
and
then
starting
to
see
what
do
we
learn
from
that,
and
how
can
we
improve
on
that
and
do
a
next
iterative
step,
and
if
that
next
iterative
step
is
moving
it
down
in
these
space?
I've
got
great.
If
the
next
iterative
step
is
these
need
to
stay
at
items,
but
we
need
to
make
items
more
of
a
more
enhanced
in
some
way
to
actually
allow
us
to
build
these
in
more
configure.
A
Then
that's
another
way.
We
could
go
I
realize
we're
out
of
time
here.
I
just
wanted
to
kind
of
get
in
those
notes.
That's
that
in
my
mind,
I'm
not
sure
that
that
that
either
solution
is
exactly
right,
but
I
think
we
need
to
take
that
first
step
and
start
to
learn
from
it
and
get
get
into
this
a
little
bit
more.
C
G
Think
it's
it's
important
to
him
that
we
do
make
some
kind
of
conclusion
that
we
can
discuss
further
in
in
the
steering
committee
because
they
asked
for
some
advice.
I
also
wanted
to
say
that
I
apologize
for
bringing
this
proposal
to
the
table
relatively
late
in
the
process,
but
it
was
mostly
because
we
saw
similarities
between
the
two
other
proposals
and
we
were
hoping
to
see
more
flexibility.
So
that's
why
we
did
decide
you
to
bring
this
up
so
late.
A
G
H
H
Like
those
proposals,
I
think
those
have
pros
and
cons
and
what
I
would
love
to
see
is
the
merge
of
those
proposals
so,
for
example,
I
like
the
idea
of
the
second
proposal
to
start
from
this
base
object
I,
like
that
we
have
the
third
proposal
to
reuse
code.
We
have
for
the
items
and
I
think
we
can
easily
put
a
lot
of
code.
We
have
for
the
items
can
be
to
the
object
level.
I
think
the
the
API.
It
would
be
possible
to
move
a
lot
of
code
from
the
item
to
achieve
that.
E
E
How
are
some
aspects
in
mind?
At
the
beginning,
the
rock
up
is
more
in
the
concept
of
what
space
and
it
is
or
that
space
object
should
be
or
should
selves
even
approach
is
more
on
a
practical
and
implementation
and
feasible
aspect
of
what
can
we
do
with
existing
space
generalities
and
and
codes
be
able
to
quickly
do
something
for
that?
E
But
for
me
the
one
very
important
aspect
is
that
we
need,
as
soon
as
possible
space
instance
allows
people
all
over
the
world
to
put
identifiers
in
a
repository,
so
I
think
we
we
should
to
focus
on
this
proposal
of
liván
regarding
a
very
feasible
roadmap
of
features
and
functionalities.
To
be
able
to
have
one
version
of
displace
7,
with
the
possibility
introduced
at
least
basic
functionalities,
be
able
to
have
some
kind
of
entities
represented
in
some
way
into
the
space
and
then
go
further
to
check
from
errors.
E
I
E
I
Have
a
question
on
exactly
what
you
would
like
to
merge
for
the
two
proposals,
its
Sun
of
the
bit
as
if
you
were
trying
to
merge
the
the
non
configural
part
of
having
the
rigids
entities
as
these
space
objects,
which
in
which
would
be
defeating
the
whole
purpose
of
this
proposal
of
it?
So
what
exactly?
Would
you
want
to
merge
in
from
the
second
proposal
just
to
make
this
clearer,
I.
C
I
H
I
think
you
should
we
use
as
much
code
as
possible
that
we
currently
have
on
the
item
level
on
the
space
object
level,
so
that
we
get
things
like
metadata
data
for
all,
also
for
the
communities
collections,
for
example,
that
the
community's
collections
don't
feel
like
being
set
the
second
class
and
the
T
compared
to
other
other
entities,
so
I
would
prefer
to
from
the
first
approach.
One
second
approach,
I
would
would
like
take
that
you
to
Sutton's
display
object
from
the
third
approach.
H
I
would
like
to
start
to
use
the
idea
to
reuse
as
much
code
we
currently
have
in
the
item
level
and,
of
course,
would
have
to
push
it
up
to
the
display,
object,
level
and
I.
Think,
though,
that
would
be
much
easier
than
to
rewrite
all
the
code.
I
think
it's
possible
to
pull
the
code
out
of
the
item
level
and
push
it
to
the
space
object
level.
So.
I
I
H
A
A
Okay,
so
that's
the
only
other
thing:
you're
interested
is
hierarchical,
metadata
and
then,
instead
of
D
space
item,
you
want
it
on
D
space
object.
Okay,
yeah
I
just
want
to
make
sure
that
that
that's
clear
what
you're
asking
so
it's
not
less
less
redoing,
both
proposals
and
more
thinking
about
whether
or
not
proposal
number
three
could
be
on
D
space
object
specifically
and
then
considering
hierarchical,
metadata,
I.
C
A
C
A
C
A
So
I'm
not
yet
to
clarify
I'm
not
against
this
idea.
I
think
that
if
somebody
wants
to
run
with
that
and
start
to
dig
into
that,
I'm
totally
for
an
analyzing
that
but
I
do
think
there
will
be
some
challenges
for
other
types
of
D
space
objects.
I
like
the
idea
for
communities
and
collections,
I
agree
with
you.
H
H
A
Yeah
I
understand
the
time
pressure
is
essentially
from
D
space
users.
I
will
let
you
know.
We
have
plenty
of
major
D
space
users
that
want
to
see
these
days
be
able
to
manage
these
sort
of
objects.
So
there
is
a
risk
and
that's
what
steering
is
pushing
on
us
for
essentially
there
is
a
risk
that
if
we
do
not
move
with
something
that
even
means
part
of
the
needs
that
we
could
potentially
start
to,
you
lose
users
who
want
these
things
out
of
t
space.
So
that's
kind
of
why
the
time
crunch
is
there?
F
Low
end,
we
need
to
say
just
one
thing:
I
agree
with
you:
the
space
user
want
to
have
a
rich
system
yep,
but
this
is
why
I
would
propose
the
space
Chris
to
solve.
Most
of
you,
I
will
be
happy
to
support
and
work
with
the
community
to
to
get
a
better
solution
on
to
long-term,
where
this
basic
risk
can
go
back
and
March
with
a
better
solution.
But
now
we
don't
need
to
get
risk
to
take
a
short
solution
to
to
get
something.
To
show
off.
F
Fastly
is
not
a
perfect
solution,
because
if
we
don't,
we
just
accept
something
that
is
not
a
perfect
solution,
a
telegram.
We
have
also
ready
specialists
that
have
a
lot
of
value.
So
if
we
decide
to
don't
go
for
this
based
Chris,
we
need
to
build
to
think
in
the
right
way.
This
is
my
point.
I
want
to
help
and
work
with
the
community
to
build
to
think
in
the
better
way
possible.
These
don't
mean
that
we
need
to
wait
ten
years
before
twelve
to
war
solution.
F
F
We
are
relate
with
the
release
on
the
user
expectation
and
if
we
go
with
a
new
release
that
we
need
to
go
back
because
we
changed
some
idea
our
mind
later,
it
will
be
a
risk
move
to
this
page
seven.
It
will
be
a
difficult
task
for
the
community
because
we
change
a
lot
of
team
right,
so
we
can
not
put
something
that
we
are
not
sure
that
is
in
the
direction
that
we
want
to
get.
We
cannot
make
experiment
with
the
space.
F
This
is
my
point
and
yes
think
I'm
really
afraid
to
say
that,
but
I
missed
one
important
thing
about
both
proposal
that
I
T
that
we
need
to
find
a
solution
to
better
manage
a
relation.
I
will
add
some
not
to
discuss
that
because
it's
a
difficult
topic,
but
essentially
both
solution.
Only
marriage
relation
between
object
in
marriage
in
turn
into
system.
The
reality
is
that
for
the
same
entities
some
case,
you
have
the
entity
internal
in
the
system.
F
In
other
case,
you
have
experimented
and
we
need
to
create
a
model
that
is
flexible
and
I'll
to
allow
you
to
link
an
external
altar
or
an
altar
that
you
have
internally
as
a
profile.
This
is
something
that
is
possible
in
this
pastries,
because
we
are
two
different:
that
a
model
that
coexist
the
space
that
a
model
that
is
very
open.
F
So
you
can
link
internal
team
or
gaspin
our
team
and
the
priest,
part
that
is
in
Germany
management,
because
if
you
ever
need
an
order,
you
are,
you
can
probably
manage
the
affiliation
and
all
the
stuff
related
to
the
little
holder.
If
you
manage
external
holder,
it
is
much
more
difficult
and
this
is
reality
and
we
need
to
have
an
idea,
a
plan
about
how
to
manage
distance,
this
complexity.
F
A
Thank
You,
Andrea
and
I
will
note
on
the
D
space
7
front
and
the
timeline
thing
one
of
the
other
things
that
has
come
up
in
steering
is
that
there
are
resources
available
for
this
work,
provided
that
we
do
it
soon
in
d
space
7.
So
there's
been
several
institutions
that
have
stepped
forward
and
said
that
you
know
if
we
can
do
this
as
part
of
D
space
7
and
make
a
small
step
in
the
right
direction
that
helps
us
store
this.
This
sort
of
data,
more
entities,
more
objects
in
D
space
7.
A
Then
they
will
provide
resources
to
do
that.
If
we
wait
until
D
space
8,
then
that's
where
there
is
some
risk
there
that
some
folks
may
not
even
upgrade
2d
space
7.
If
we
can
convince
them
to
go
to
something
like
D
space
Chris,
yes,
I'd,
be
all
for
that.
If
that's
going
to
meet
their
needs,
I'm,
not
convinced
that
that
will
meet
all
of
these
institutions
needs
that
we've
been
talking
to
so
I
just
want
to
try
and
lay
out
all
the
risks.
Here.
A
H
Missing
actually
for
the
discussion,
so
with
all
this
time,
pressure
for
example,
understand
why
and
we
have
proposed
it
Chris.
If
you
have
the
time,
I'm
I
think
ok,
we
could
could
take
a
look
on
how
to
design
it.
But
then
you
just
said
that
this
is
Chris
may
even
have
sources,
because
the
users
we
are
speaking
about
have
other
things
and
so
for
me,.
A
G
I'm
sure
I
know
that
it
needs
to
be
improved.
I'm
sure
that
there
are
some
improvements
possible
even
to
the
way
that
the
D
space
object
relates
to
collection
and
items
etc.
Moving
everything
up
to
the
D
space
object
level,
I'm,
not
sure
that
that's
the
right
solution,
but
creating
a
layer
in
between
or
whatever
those
are,
definitely
good
things
and
and
can
happen
over
the
longer
term,
but
being
able
to
make
relationships
between
items.
I,
don't
think,
is
a
functionality.
That
is
a
step
in
the
wrong
direction.
G
G
A
Yeah,
my
personal
feeling
is
that
it's
a
step
in
the
right
direction,
which
is
why
I'd
like
to
see
us
move
forward
with
something
that
at
least
goes
in
the
right
direction
and
we
can
improve
upon
it
incrementally
and
to
answer
Pascal's
question.
We
essentially
have
about
a
year,
maybe
less
than
a
year.
People
want
to
see
dspace
seven
out
either
by
the
end
of
2018
or
early
2019,
and
ideally
it
has
some
ability
to
manage
extra
entities.
It
doesn't
have
to
be
perfect.
It
doesn't
have
to
be.
A
You
know,
100
percent,
all
there
in
terms
of
everything
these
days,
Chris
does,
but
it
should
be
a
step
in
the
right
direction
to
be
able
to
manage
these
relationships
between
objects.
Manage
different
types
of
objects,
ideally
manage
objects
that
are
non,
not
not
even
Chris
specific
and
that's
kind
of
where,
where
things
have
our
sets
it
right
now,
you.
D
A
You
know
different
sorts
of
flavors
of
dspace,
allowing
you
to
kind
of
customize
these
space
in
different
ways
that
you
currently
cannot
and
that's
kind
of
where
this
first
stage
could
really
help
build
the
groundwork
for
that.
Where,
in
the
future
releases,
we
could
have
those
different
flavors,
but
we
just
need
to
make
that
sort
of
first
step.
G
F
Yes,
my
only
warning
is
about
the
strong
use
of
lighting,
because
I
think
that
the
point
that
we
can
use
a
lot
of
think
for
item
and
not
for
displaced
object
is
honestly
is
weak.
It
is
relief
for
displaced
six.
If
you
need
to
do
this
stuff
on
this
page
six,
you
are
right.
You
have
a
lot
of
feature
for
the
for
an
item
that
are
not
available
for
this
based
object.
A
So
let
me
let
me
poke
on
that
a
bit
here,
really
quick.
So
if,
if
your
only
disagreement
here
is
between
whether
it's
at
the
item
or
the
object
level,
are
you
essentially
saying
Andrea
that
you
agree
with
this
option
three
that
at
Myers
proposed?
But
you
would
just
propose
that
we
analyze
whether
we
could
move
this
down
to
the
D
space
object
layer.
F
A
F
So
if
we
make
this
change,
if
in
this
page
seven,
we
will
be
able
to
create
more
relation
between
the
internal
objects,
it
is
an
improvement
right.
In
any
case,
it's
good
to
have
I.
Don't
think
that
is
an
out
to
say
that
you
support
external
entity
and
it's
a
Chris
system
is
allows
you
to
do
or
to
think
that
the
user
want
to
do.
But
it
is
an
improvement
if
we
have
other
stuff
that
want
to
do
that
other
resource.
But
we
learn
to
have
that
inner
space
server.
It
can
be
done
so.
F
A
F
Would
you,
sir,
have
and
what
we
will
provide
in
this
place?
There
are
very
far
so
if
we
want
to
have
people
a
strong
work
in
integration.
This
is
this
help
to
do
something
better,
but
is
not
your
kid
integration,
implementation
and
the
orchid
integration
implementation?
We
require
itself
maybe
fifty
day.
G
F
If
we
do
that
into
right
way,
that,
for
me
mean
we
need
to
say
more
to
this
pace,
subject
level
we
need
to
instead
to
do
pink
at
the
item
level
and
move
down
later
we
immediately
do
the
new
thing
directly
for
Matata,
for
all,
as
we
are
doing
in
in
this
pace,
center
is
no
need
to
to
force
us
to
focus
on
the
item.
We
can
talk
about
Matata
for
all.
F
I
Understand
that
well
with
metadata
for
all,
we
can
do
the
exact
same
things
about
metadata
for
any
D
space
objects.
That's
the
goal
why
the
metadata
for
all
was
contributed
in
the
first
place,
but
metadata
for
all
is
not
everything,
that's
necessary
for
this
model,
and
there
are
many
other
things
that
are
present
in
items
that
are
going
to
be
very
complicated
or
not
realistic,
to
apply
to
all
these
place
of
checks
such
as,
for
instance,
a
special
workflow
special
steps.
I
A
So
yeah
I
agree
with
all
it's
good
to
hear
this
discussion
I
think
it's
good
to
understand
here
too,
that
there's
just
obviously
a
strong
disagreement
between
whether
this
stuff
should
be
at
the
item
level
or
the
object
level.
I
guess
my
question
is:
is
that
the
only
layer
of
disagreement
here
is
everyone
on
this
call?
Okay,
with
option
3,
providing
that
we
figure
out
that
disagreement
point
we.
H
A
A
B
F
Three
looks
promising
just
say
in
a
different
way:
I'm
gonna
is
I,
don't
want
to
abuse
of
this
new
feature
to
do
something
that
should
be
done
in
a
different
way.
So
this
new
feature
adds
some
value
solve
some
issue.
I,
don't
want
to
try
to
abuse
of
such
features,
to
say
that
we
can
solve
everything,
because
if
we
need
to
solve
something
very
specific,
we
can
discuss
about
a
better
strategy
to
solve
a
specific
feature.
A
F
I'm
su
T
is
just
a
morning
for
all
of
us:
yep
don't
try
to
implement
whatever
we
want
just
quickly
right.
It
is
our
good
functionality
that
we
want
to
add
is
good
to
add.
We
agree
as
you
want
to
go
in
this
direction,
but
if
we
need
to
build
something
on
top
of
it,
we
need
to
discuss
if
we
want
to
use
it
as
it
is,
or
we
want
to
extend
again,
and
so
we
don't
need
to
go
or
to
decision.
I
agree.
A
Yeah
I
agree
with
that
completely.
Let's
just
trying
to
make
a
first
step
here
and
then
we
don't
need
to
move
as
quickly
for
every
single
feature,
necessarily
or
every
single
next
step,
but
but
what
I
was
getting
to
here
is
I
want
to
make
sure
everybody
agrees
with
this
statement
that
I'm
going
to
tell
steering
is
I'm
going
to
say
that
this
working
group
feels
that
option
three
looks
very
promising.
A
B
A
B
A
Okay,
so
I
think
that's
to
me.
That
seems
like
a
good
enough
decision
for
today.
I,
don't
know
that
we
need
to
continue
this
meeting
any
further.
I
can
bring
that
back
and
say
that
option
three.
We
all
agree
that
is
promising,
but
we
do
need
to
dig
in
more
on
the
implementation
details
and
perhaps
even
at
Meyer
can
start
to
dig
in
slightly
on
on
that
bin
or
leaving.
A
G
G
A
A
G
A
Possibly
I
think
we'd
need
a
proposal
to
respond
to
that
might
be
a
if
at
Meyer's.
Somebody
can
look
at
and
the
initial
analysis
that
we
could
start
to
respond
to.
Then
maybe
we
could
do
some
of
the
commentary
in
slack
or
in
a
new
proposal
document,
but
we
still
probably
need
to
meet
to
make
sure
all
on
the
same
page.