►
From YouTube: 2018-12-04 : DSpace 7 Entities Working Group Meeting
A
Okay,
we're
now
recording
so
welcome.
All
as
I
mentioned,
we're
kind
of
a
small
group
there's
only
four
of
us
here
today.
So
hopefully
we
can
keep
the
discussion
moving
along
and
make
some
decisions,
just
among
the
four
of
us
at
least
or
we'll
have
a
couple
other
folks
pop
in.
Perhaps
so.
The
agenda
I
had
a
link
to
within
slack
I'm
gonna
assume
you
all.
Have
it
pretty
much,
but
I'll
put
it
in
zoom
as
well.
A
The
three
of
them
I
think
there's
just
three
of
them
right
now
that
are
still
open
and
under
review
and
then
move
into
a
continuation
of
our
discussion
from
last
week
around
author
profiles
and
specifically
which
features
we
feel
should
really
be
in
these
base:
seven
verses,
which
could
be
delayed
for
for
a
dspace
eight
and
wait
more
on,
unlike
hierarchical,
metadata
and
other
features
that
will
be
coming
in
a
future
release.
And
then
we
can
wrap
things
up
at
the
end.
A
We
only
have
two
meetings
in
December,
of
course,
because
the
holidays
so
there's
this
one
today
and
then
the
next
one
will
be
on
I,
should
I
have
the
date
wrong.
Tuesday,
December,
18th
that'll,
be
our
final
meeting,
I'm,
not
sure
how
well
it'll
be
attended
since
I
know
that's
getting
closer
and
closer
to
the
holidays,
but
there's
quite
a
bit
of
work
to
try
and
get
done
in
December
and
that's
sort
of
what
this
first
topic
is
about.
Just
in
terms
of
our
scheduling.
A
As
a
reminder,
we
really
would
like
to
get
to
a
preview
release
by
late
January
early
February
to
try
and
keep
us
on
schedule
for
that.
It'd
be
really
great
if
we
can
get
entities
to
a
to
a
pretty
stable
state
and
ready
to
go
into
the
master
branch
by
the
end
of
December
early
January,
so
our
timelines
are
getting
a
little
bit
tighter
with
the
holidays
coming
up
and
with
only
a
couple
meetings
left
here
in
December.
A
So
that's
just
something
we
need
to
kind
of
keep
in
mind.
It'd
be
good
to
try
and
get
more
more
reviews
in
between
meetings
and
more
moving
along
pull
requests
in
between
meetings,
especially
in
December
because
of
our
lack
of
meetings.
So
the
more
we
kind
of
bring
discussion
to
to
get
hub
into
slack
or
whatever
other
ways
we
can
do
it
outside
of
meetings.
A
The
better,
the
more
we
rely
on
meetings
to
kind
of
touch
base,
I
think
we're
going
to
kind
of
move
a
little
bit
slower
than
expected
and
I'm
kind
of
worried
that
that'll
potentially
affect
our
target
of
that
late.
January
preview
release,
so
many
comments
or
questions
on
that
or
anybody
want
to
add
anything
to
that.
That's
kind
of
it
for
that
first
topic.
A
Okay,
not
hearing
anything
so
going
into
trying
trying
to
move
some
of
these
pull
requests
along.
As
I
noted,
we
have
three
pull
requests
that
are
still
open
that
are
under
review.
We
have
the
angular
user
interface,
pull
request,
which
I
had
done
an
initial
review
on
and
gave
some
feedback
just
from
a
a
code
standpoint,
and
most
of
that
has
been
actually
thank
God.
A
Most
all
of
it
has
been
cleaned
up
as
at
this
point,
but
we
haven't
had
any
sort
of
secondary
reviews
yet
in
terms
of
trying
to
test
it
out
or
see
how
things
look
and
in
the
code
or
anything
of
that
nature.
So
I've
still
been
kind
of
waiting
on
on
others
to
get
involved
here
and
see
if
we
can
get
a
secondary
review
review
or
some
tests
or
questions
in
there
has
anybody
else
had
a
chance
to
take
a
look
at
that.
A
B
A
So
I
I
would
like
to
get
more
feedback
on
the
angular
pull
request
or
request
number
315
on
the
angular
side.
I
can
link
that
into
slack.
So
as
of
the
last
meeting,
we
had
discussed
how
that
needed
to
be
kept
open
so
that
you
and
Alexander
I
know
how
examiner
isn't
here
today
could
have
a
chance
to
look
at
it
and
give
give
some
more
feedback
into
that
and
I'm
just
kind
of
curious.
Whether
you've
had
that
opportunity
or
will
you
have
the
opportunity
to
give
feedback
in
the
next
week
or
so?
A
B
A
A
Right
yeah
I
recall
that
I
just
remember
from
last
meeting
we
had
discussed
that
that
you
and
Alexander
would
have
a
chance
to
kind
of
give
it
another
test
and
run
through
it.
It
sounded
like
we
wanted
to
wait
for
somebody
else
to
have
a
chance
to
look
at
it,
since
I
was
the
only
one
to
give
it
a
thorough
review,
so
I
just
trying
to
get
a
status,
update,
I
guess
as
to
whether
or
not
there's
more
you're
planning
to
do.
C
D
A
Yeah
yeah,
if
you
have
any
chance
to
give
feedback
into
this
as
well
that'd,
be
welcome.
I
just
like
to
have
somebody
else,
get
some
sort
of
feedback
in
here.
Someone
else
review
it
basically
beyond
just
me,
because
I'm
not
sure
if
I
caught
everything
and
I
didn't
get
a
chance,
admittedly
to
do
a
full
test
myself.
A
A
Thank
you
for
sharing
that,
though
that's
excellent
okay,
so
that's
the
angular
PR.
So
then,
as
noted,
there's
two
other
pull
requests
that
are
open.
So
I'd
like
to
talk
about
those
briefly
as
well
and
see
what
we
can
do
here.
We
have
the
entities
CSV
import,
pull
request,
which
was
the
the
first
of
those
open.
This
is
two
two
six
nine
which
I
just
linked
into
the
slack
channel
and
I
know.
There
have
been
some
reviews
of
this,
which
is
great
to
see
and
Paulo.
A
A
C
D
C
A
Sounds
good
so
yeah
we're
waiting
on
just
updates
there
from
that
developer
then,
and
then
the
last
of
the
three
poll
requests
is
two
two
seven
zero
and
that's
the
virtual
metadata
updates,
which
I
know
Paulo.
You
had
a
chance
to
review
and
Alexander
had
a
chance
to
review
and
again
I
reviewed
it
yesterday
and
I
see
mark
added
some
notes
this
morning
as
well.
A
A
C
A
A
Yeah,
it
sounds
like
we
might
need
feedback
from
Ben,
so
we'll
just
have
to
wait
till
he's
able
to
have
a
chance
to
to
take
a
look
at
this
cuz
I
think
both
of
al'lat,
Alexander
and
Paulo's
questions
are
good
and
then
yeah
I,
just
kind
of
wanted
more
more
documentation
in
that
structure.
Here
of
the
configuration
yep.
C
C
A
C
A
A
A
C
An
update
on
that
you
have
there's
this
one
here,
that's
already
been
implemented,
but
then
hasn't
made
the
pull
request.
Yet
he
told
me
this
can
wait
until
he's
back
from
paternity
leave,
unless
anybody
would
need
it
sooner
and
same
basically
for
this
cheer
a
ticket
here,
I
says
I've
already
scheduled
a
task
for
a
developer
as
soon
as
this
is
ready,
I
can
create
a
pull
request.
A
C
A
Okay,
so
then
moving
along
from
there,
then
I
guess
our
nest.
Our
next
step
here
is
to
move
in.
So
there's
still
just
four
of
us.
It's
kind
of
hoping
more
folks
would
join
us
here
for
discussion
today,
but
this
might
be
a
trend
for
December,
we'll
see
we'll
see
how
many
people
would
get
online
in
December.
So
I
wanted
to
jump
back
to
our
author
profiles,
use
case
discussion
from
last
week,
because
I
know
that
was
very
rushed
or
not.
A
A
C
So
I
think
the
the
main
discussion
points
are
at
the
bottom
of
the
document.
That's
we've
called
it
metadata
or
additional
data
for
a
relation
and
then
another
point
that
we're
working
on,
but
I
don't
think
that
there
is
going
to
be
a
lot
of
discussion
around.
That
is
how
you
mix
plain
text
with
entities
and
authority
controlled
fields
so
that
you
can
retain
ordering,
and
you
have
a
good
display
if
there
are
authors
that
are
playing
metadata
versus
entities
versus
Authority
controller,
just
basically
the
same
as
playing
metadata.
C
So
that's
something
that's
already
being
implemented
at
the
moment
and
has
a
first
version
ready
that
I've
seen
internally.
But
it's
not
ready
enough.
So
I
think
that
one
might
be
the
easier
one
to
discuss.
I,
don't
think
it's
a
big
discussion
point
in
terms
of
whether
we
should
do
this
or
not,
but
just
the
way
it
is
implemented.
C
C
A
A
C
A
C
A
C
Of
course,
I
think
the
the
only
like
real
discussion
point
there
and
I
put
it
in
if
there
would
be
if
it
would
be
suitable
to
do
to
have
the
discussion
now,
but
I
think
it's
probably
not
the
right
time
yet.
So
it's
also
about
submission
like
how
do
you,
so
this
is
about
the
code.
How
do
you
do
the
place?
Calm?
C
How
do
you
store
it
as
well
as
how
it's
displayed
on
the
item
page?
So
it's
that
second
to
last
section
item
display,
UI
impact
and
I
think
you
know
for
those
two,
it's
pretty
straightforward
for
the
last
one.
I
have
submission
it's
still
difficult
to
discuss
at
the
moment,
since
the
submission
code
has
not
been
merged.
That
should
be
one
of
the
discussion
points
for
early
January
I.
Think,
once
the
submission
code
is
in
there
because,
on
the
usability
level,
I
mean
we've
been
doing
some
brainstorming
internally
on
how
to
best
approach
this.
C
But
it's
not
so
easy
to
make
it
very
usable
for
users
in
the
submission
to
determine
you
know
how
to
do
the
input
like
because
as
a
submitter,
you
might
not
know
that
an
entity
for
a
particular
person
exists
or-
and
you
have
to
make
the
choice
between
regular
metadata
Authority
control.
If
it's,
if
there's
no
entity,
but
there
is
an
authority
control
where
the
authors
you
know,
internal
identify
or
whatever
is
stored
in
the
authority,
control
or
an
entity.
C
So
but
I
don't
think
it's
very
useful
to
have
that
discussion
right
now.
As
long
as
the
submission
pull
request
is
still
open,
but
I
just
wanted
to
point
it
out
that
it
is
something
that
we
need
to
look
at
in
early
January
and
it's
only
one
point
of
the
submission.
There
are
other
areas
in
the
submission
that
also
need
to
be
discussed,
but
I
think
we
can
do
that
now.
A
Right
yet
be
useful
to
have
the
submission
code
to
look
at
but
yeah.
My
inclination
here
is
to
try
and
simplify
as
much
as
possible
and
think
about
either
extending
or
using
the
authority
control
mechanism
to
pull
up
entities
as
well
so
that
it
becomes
seamless
for
the
user,
so
they're,
basically
they're
selecting
from
some
object
that
exists
either
internally
or
externally,
with
an
identifier,
whether
that's
an
entity
or
an
external
object
or
they're
just
entering
plain
text.
So
it's
more
like
the
current
processes.
Okay,
yeah.
C
We
add
something
that
is
a
very
short
proposal.
Eris's
can
be
done
by
adding
a
lookup
button
to
the
submission
form.
It
has
a
UI
control
same
as
the
current
authority
control,
but
with
two
tabs,
one
for
authority
control
and
another
one
for
entities
or
typed
items
and,
if
you
add
a
plaintext
or
authority
control
value
stored
as
metadata.
If
it's
as
a
person,
it's
done
as
a
relation
with
The
Associated
virtual
metadata,
it's
ER,
but
yeah.
We
haven't
touched
on
the
whole
topic
of
how
to
deal
with
this
in
the
submission.
D
C
B
C
B
C
B
A
Done
by
for
science,
but
yeah,
it's
not
yet
merged.
So
this
is
what
what
has
a
dependency
right
now.
We
really
need
to
get
this
merged
on
the
angular
side
and
we
have
a
promise
that
this
will
be
merged
with
in
December
or
I'll,
be
ready
to
go
in
December,
because
currently
it
does
affect
some
of
these
decisions
on
the
entity
side
that
it's
kind
of
slowing
things
down
a
little
bit
on
entities.
You.
C
A
Technically
I
mean
you
could
start
to
analyze
the
code
that
already
exists
there
I
know,
that's
not
the
easiest
thing
to
do
in
a
pull
request,
but
I
mean
the
code.
Is
there
mostly
what
this
pull
request
is
waiting
on
as
it
needs
to
be
upgraded
to
angular
6,
and
then
it
needs
tests
tests
implemented,
but
the
actual
code
itself
already
exists.
So
technically
I
mean
you
could
start
looking
at
the
code
and
seeing
how
it
could
be
implemented,
but
I
definitely
understand
that.
Ideally
you'd
do
that
once
the
code
is
merged.
C
A
Yeah
I
was
just
noting
that
it
has
gone
through
some
review
cycles,
but
part
of
the
what
the
review
cycle
brought
out
was
that
there
was
a
lack
of
tests
and
there
were
some
fixes
that
were
noted,
but
I'm.
Just
noting
that
that
the
code
is
getting
to
a
point
that
it
seems
like
it
should
be
a
little
bit
more
reasonable
but
you're
right.
We
can
discuss
it
more
in
the
D
space
7080
tomorrow,
yeah.
C
I
have
some
comments
from
Ben
for
the
T
space
7
meeting
tomorrow
on
the
current
code,
because
Ben
is
waiting
to
review
it
until
the
the
pull
request
was
completely
there
and
not
just
to
open
the
repositories.
Demo
and
pull
requests
and
I
asked
him
to
go
ahead
and
review
the
demo
pull
request
already
anyway
cuz.
Otherwise
we
might
run
short
on
time
and
he
did
have
some
feedback
there.
I'll
relay
that
tomorrow.
That's
good
I,
think
the
the
main
discussion
point
here
is
the
question
of:
how
do
we
add
additional
data
to
relations?
C
That's
the
the
other
discussion
point
and
how
far
we
want
to
go
with
doing
that,
and
whether
or
not
that's
something
for
D
space,
7
or
D,
space,
8
and
kind
of
depends
on
the
the
strategy
we
want
to
follow.
The
the
first
one
is
an
additional
field
in
the
relationship
database
table,
which
is
very
simple.
It's
a
similar
approach
to
what's
these
basic
risks
does
with
authority.
Control
is
just
add
extra
fields
to
the
relation
without
defining
what's
stored
in
that
field.
C
C
A
second
alternative
would
be
to
what
we've
called
metadata
for
a
relation,
but
yet
depends
on
how
you
want
to
look
at
it,
but
where
you
would
also
want
to
qualify
what
it
is
that
you're,
adding
as
data
to
the
relation.
So
it's
not
just
a
text
field,
but
that
it
also
has
a
clear
description
of
what
it
is,
so
that,
for
example,
if
it's
a
DC
date,
dot
start
date
that
you
can
interpret
that
and
that
you
know.
Okay.
This
is
a
start
date
of
the
relation.
C
C
C
The
third
one
plain
text
metadata,
and
then
you
have
your
three
affiliations.
One
also
plain
text,
because
it's
outside
of
your
institution
and
then
two
relations
to
the
org
units
and
then
in
the
item.
You
need
hierarchical,
metadata
to
say,
okay,
this
author
is:
has
this
affiliation
right
rather
than
saying?
Okay,
you
have
that
secondary
relation,
and
you
resolve
it
through
that
secondary
relation
which,
which
required
to
have
dates,
start
and
end
dates,
but
I
think
those
two
are
not
so
related.
C
C
How
do
you
do
that?
How
do
you
store
that
additional
data
and,
like
I,
said
there's?
The
first
solution
is
a
simple
solution
and
the
second
one
is
a
more
involved
solution,
but
allows
more
complicated
and
more
on
different
use
cases.
Basically,
and
we
could
say
you
know
we
don't
go
for
either
of
the
two
and
dspace
seven.
We
could
say
we
go
for
solution,
one
in
D
space,
seven
and
throw
it
out
and
do
solution
2
in
D
space
8
or
we
could
go
for
a
solution
to
immediately.
C
A
Stepping
back
just
for
a
moment,
perhaps
a
silly
question,
but
is
it
possible?
Would
it
be
possible
to
to
simply
handle
like
author
variants
in
D
space
7
as
virtual
metadata
or
name
variances
virtual
metadata,
we're
essentially
the
author
profile
can
pull
that
information
from
the
publication's
link
to
that
author
profile
and
just
display
them
and
kind
of
filter
out
duplicate
values?
C
A
A
A
A
A
A
C
It
can
like
the
the
to
implementation
options,
can
support
both
those
scenarios
if
I
understood
it
correctly.
So
these
are
two
separate
problems.
Basically
one
is
like
okay,
where
do
you
put
the
control
on
the
publication
wrong,
the
author
profile
and
that's
one
discussion
and
a
second
discussion
is
okay.
If
you
need
to
add
information
to
a
relation,
then
how
do
you
do
that
in
the
code?
How
do
you
store
it
and
how
far
do
you
go
with
that?
C
So
if
you
have
it
stored
in
the
author
profile
and
you're
in
the
submission-
and
somebody
has
Mis
type
Tim
Donahue,
but
typed
Donoghue,
would
he
instead
of
oh
right?
It's
a
very
common
misspelling
of
your
name.
There
are
lots
of
people
who
have
that
problem.
Maybe
you
have
that
actual
home.
That
I
just
said,
then
you
can,
if
you
put
that
name
variant
in
your
profile
and
I'm
a
cataloger
and
I'm
typing
Donoghue,
and
then
it
gives
me
the
suggestion.
It
says
hey.
C
C
After
checking
your
author
profile
and
seeing
that
you
have
the
same
affiliation
as
the
person
on
the
publication,
and
it's
like
okay,
it's
10,
Donahue,
and
it
they
just
say:
okay
I
pick
that
one
and
then
you
go
from
there
where,
if
it's
on
the
publication
you
just
type
it
and
who's.
Gonna
know
at
that
point
to
attach
that
to
your
author
profile,
I
mean
I
assume.
A
Yeah
I
understand
your
point
and
I.
Just
don't
know
that
I
agree
that
that
requires
that
information
to
be
stored.
On
the
author
profile,
I
mean
I.
Think
an
author
does
have
like
preferred
names
and
those
are
kind
of
like
named
variants,
but
that
doesn't
necessarily
mean
that
an
author
even
remembers
all
of
the
various
names
they've
used
in
publications.
No.
C
Of
course,
but
if
then
there
would
be
a
question
of,
is
this
one
of
your
name
variants
than
one
cataloger
has
to
ask
that
question
once
the
author
says?
Yes,
you
added
to
the
name
variants
and
in
the
future,
other
people
would
know,
and
so
that
kind
of
flow
of
adding
the
data
I
don't
see
how
that
could
work.
A
Let
me
poke
at
that
a
little
bit
just
because
I'm
not
sure
I
fully
agree.
Yet
my
my
inclination,
rather
than
trying
to
like
I,
think
we're
making
almost
an
assumption
that
this
information
needs
to
all
be
stored
in
the
database
layer,
whereas
I
would
encourage
us
to
think
about
ways
that
we
should
be
indexing,
this
information,
so
that
it's
more
easy
to
find
so
I.
A
C
A
I'm
kind
of
saying
is
that
the
the
virtual
metadata
should
almost
be
indexed
and
easily
findable
in
an
index
so
that,
if
you
treated
this
a
different
way
of
thinking
about
this
I
mean
this
is
totally
totally
wrong.
But
let
me
just
get
it
out
there.
So
if
we
treated
this
as
virtual
metadata,
so
the
author
profile
does
not
have
well.
Maybe
it
has
your
preferred
names
on
the
author
profile,
but
it
doesn't
a
sort
of
not
necessarily
have
all
named
variants.
A
That
is
tea
donahue
and
then
that
can
come
up
with
a
list
of
who
who
has
that
information
or
who
has
one
of
the
two,
and
then
they
can
select
the
correct
author
profile
to
link
this
new
publication
to
that's
the
way
I
would
think
of
it
is
that
virtual
metadata
needs
to
be
well
indexed
both,
so
it
can
be
displayed
in
a
scalable
way
as
well
as
so
that
it
can
be
searched
as
if
it's
kind
of
on
both
objects.
So
it's
kind
of
both
on
the
author
profile
object
and
on
the
publication
object.
A
C
A
I
understand
that
that
there's
different
ways
of
doing
this
I'm,
just
noting
I'm,
just
questioning
whether
we
actually
need
to
be
storing
this
information
like
attach
to
a
relationship
which
is
what
the
solutions
here
revolve
around,
is
actually
adding
data
on
relations.
I
am
starting
to
question
more
and
more,
whether
that's
actually
necessary
or
if
that
can
be
implemented
in
a
different
way,
where
it's
more
of
that,
our
solar
indexes
need
to
be
able
to
track
what
information
kind
of
almost
belongs
to
the
relation
without
actually
storing
it
there.
A
If
that
makes
any
sense,
so
so
I'm
basically
saying
that
relations
are
just
loose
links
and
could
be
remain,
loose
links
the
name
variant.
We
can
choose
a
place
for
it
in
terms
of
whether
it
belongs
in
the
publication
of
the
author
profile,
but
within
solar.
It
appears
in
both
places
because
there
is
a
relation
there,
so
it
appears
as
if
it's
on
both
in
solar,
but
at
the
database
level.
It's
actually
really
only
on
one.
B
A
Yeah
so
I
guess
I'm
trying
to
propose
yeah
I
agree
with
that
Paolo
I
think
I'm,
trying
to
propose
a
different
solution
here,
which
might
be
simpler,
4d
space
7.
If
we
find
that
this
isn't
scalable-
and
we
actually
do
need
this
metadata
on
relations,
then
we
could
add
that
n
to
D
space
8
but
I'm
just
kind
of
questioning
whether
we
even
really
need
that
over
there
on
relations
or
whether
we
proven
it
and
I'm,
not
sure.
If
we
have
all
this
woodwork
can
I
draw
how
this
would
work.
I.
A
A
Essentially
so
we're
talking
about
additional
data
for
relations
and
rather
than
actually
storing
those
in
the
database,
I'm
implying
that
they
should
be
stored
in
solar,
because
they're
kind
of
just
indexed
information
but
yeah
I
could
draw
how
it
work,
but
the
concept
would
essentially
be
that
name
variance
would
just
exist
on
the
publication,
because
you,
in
term
into
the
publication,
you
are
trying
to
find
a
person
that
matches
that
name
variant
to
create
that
relation,
obviously,
and
so
the
first
time
this
happened.
So
the
first
object
you
put
in
for
40
Donahue.
A
Maybe
you
find
Tim
Donahue
in
the
system
you're
like
okay,
that
seems
like
a
reasonable
match.
Let's
create
that
relation
at
the
point
that
that
relation
is
created.
That
basically
is
an
index
within
solar.
That
says
you
know:
okay,
I
have
created
a
relation
between
this
author
and
publication.
So
now
I
know
in
solar
that
the
author
has
a
name
variant
of
t
donahue,
because
that's
what
exists
on
a
publication-
and
I
also
know
that
this
publication,
you
know
or
that
the
publication
is
linked
up
to
the
author.
A
D
A
A
Exists
in
the
database,
but
only
on
one
side,
so
it
exists.
What
I'm
saying
is
it
would
exist
in
an
example
of
a
name
variant.
The
name
variant
would
exist
in
the
database
on
the
publication
only
it
appears
virtually
on
the
author
profile
and
it
gets
indexed
and
solar
as
part
of
that
relationship
so
that
it
so
that
that
relationship
can
be
searched,
but
you're
right.
C
B
We
are
just
experience
other
profiles
in
this
phase
five,
and
we
extend
the
model
to
support
something
like
this.
This
information
is
about
an
alpha.
It
has
an
arcade.
This
is
the
the
open
air
for
version
of
the
the
schema,
and
let
me
try
to
do
this
pretty
way.
Okay,
so
we
have
an
offer
here
and
we
have
some
some
metadata
about
the
publication
this.
This
data
is
stored
in
the
the
we
have
a
specific
table
for
routers
this.
This
data
is
stored
in
that
table
and.
A
B
A
B
B
B
No
I
want
to
share
I
I
just
wanted
to
share
this
soft
to
to
show
that
and
I
think
we
can
use
solar
to
to
do
the
the
and
and
vital
metadata
to
do
that
part
to
mingle
the
the
two
entities.
That's
why
why
what
we
are
talking
here,
mingle
data,
we
need,
we
need
this.
We
need
to
have
parts
of
some
entity
and
have
parts
of
another
entity.
A
Yep,
yet
is
that
I
don't
know
if
that
the
context
here
mark
at
all
I
know
we're
about
near
the
top
of
the
hour,
but
I
think
this
is.
This
is
exactly
what
I
was
saying:
is
kind
of
you're
pulling
metadata
from
two
different
objects
and
when
you're
doing
that
sort
of
pulling
from
two
objects,
you
could
protect
potentially
non-solar
to
index
it
better,
so
that
that
metadata
could
appear
more
easily
on
each
object,
just
for
a
scalability
factor.
So
you
don't
have
to
actually
pull
each
object
from
the
database.
A
A
At
the
database
level,
I
don't
know
no,
not
necessarily
I'm.
Just
noting
that
I
don't
think
we.
My
whole
point
to
bringing
this
up
is
I'm,
not
convinced
that
we
need
to
have
metadata
on
the
relationship
itself,
I'm
more
pointing
at
the
fact
that
I
think
it'd
be.
We
should
consider
just
having
metadata
on
the
entities
and
the
relationship
be
metadata
lists
other
than
it's
just
a
link
between
two
entities
and
any
information
that
we
can't
easily
scalable
get
from
the
entity
metadata.
A
So
yeah
I
can
give
you
I'll
give
you
that,
so
maybe
we
don't
need
to
have
solar
in
here
at
all
I'm
just
my
whole.
My
whole
point
of
bringing
this
up
was
around
this
discussion.
Point
of
adding
data
on
relations
and
I
feel
that
this
is
another
potentially
premature,
optimization
I'm
asking.
Why
do
we
need
the
metadata
on
the
relations?
It
can
either
stay
on
the
entities
themselves
or
if
we
find
that
that's
not
scalable,
then
we
can
bring
it
into
solar
and
index
it.
You.
A
Right
yeah
and
that's
where
I'm
saying:
could
we
use
virtual
metadata
like
this,
because
that's
our
way
of
inference,
if
you
use
virtual
metadata
and
the
performance
is
okay,
then
that's
the
way.
We
should
do
it.
If
we
can't,
if
we
hit
performance
issues,
then
maybe
that
virtual
metadata
needs
to
be
indexed
in
some
way
and
solar
so
that
we
can
get
around
those
performance
issues.
A
Yep
yeah,
so
I
don't
know
if
we've
come
to
a
decision
point
here,
I
guess
I'm.
Just
noting
that
I
think
it
feels
like
to
me.
The
whole
section
of
additional
data
for
relations
seems
like
something
we
could
potentially
get
around
Indies
mae7.
If
we
can
lean
more
on
virtual
metadata
and
figure
out,
if
that's
a
possible
solution
for
now,
rather
than
the
two
options
presented
here
well,
I
mean.
C
C
C
I'm
forgetting
my
second
point-
yes,
sorry
I'm
still
not
100%
recovered
I
was
also
trying
to
reach
Ben
Rhoda
at
one
page
text
about
what
he
thinks
about
this
and
us
trying
to
read
it.
While
you
were
talking
and
making
sense
of
it
at
the
same
time,
but
apparently
that
that's
not
an
option
today,
but
I
think
we're
tying
to
two
together
a
little
bit
too
much,
and
there
is
also
the
question
which
we
don't
have
to
answer
today
of.
Do
we
really
need
this
name
variant,
implementation
in
D
space
7?
C
D
A
Yeah
and
I
think
we're
actually
all
saying
the
same
thing.
That
is
actually
why
I'm
trying
to
turn
this
into
a
discussion
around
virtual
metadata,
because
I
don't
see
the
point
in
and
trying
to
implement
complexity
of
metadata
on
relations
until
we
have
our
minds
around
what
people
need
there
and
I
don't
think
we
have
that,
and
so
when
I
say
this
should
be
implemented
as
virtual
metadata
I'm
trying
to
come
to
a
simple
solution
that
allows
us
to
still
say
yeah.
D
A
Yeah
I
agree
yeah,
but
I
get
the
sense
that
we're
all
actually
saying
the
same
thing.
We're
saying
it
in
different
ways.
So
I
think
that
this
metadata
on
relation
should
be
a
later
discussion.
It's
not
some
4d
space
7
because
I'd,
because
we
don't
have
our
minds
around
what
information
would
logically
go
here
and
I'm,
not
convinced.
A
If
we
can
just
do
those
as
virtual
metadata
in
the
same
way
that
we're
using
virtual
metadata
for
journal
relationships
and
things
of
that
nature
and
just
see
how
that
works.
So
it
that
does
not
seem
like
any
significant
change
to
me.
It
seems
like
it's
basically
like
we're
not
doing
much
anything
here
other
than
adding
in
a
new
virtual
metadata
field.
A
For
author
name
variants,
so
it's
almost
the
simplest
route
here,
but
but
we
need
to
wrap
this
up
because
we're
already
over
time-
but
that's
kind
of
it
seems
like
to
me
we're
all
really
actually
coming
around
to
the
same
sort
of
basic
solution.
And
then
we
just
need
to
see
how
that
sort
of
plays
out,
as
we
start
to
play
with
it
in
the
data
and
that's
where
solar
could
be
an
attribute.
If
we
find
performance
issues
of
some
sort
or
we
could
just
drop
named
variant
support
altogether.
C
Maybe
get
some
community
input,
because
I
think
we
still
I
mean
if
we
are
able
to
properly
finish
all
of
the
other
implementations
around
entities.
I
think
we
still
have
sufficient
time
between
early
february
and
the
next
dates
that
have
been
discussed
for
the
release
of
these
base
time
and
to
still
do
something.
I.
A
Think
that's
reasonable.
I
yeah
I'm
fine
with
that
I
guess.
The
only
thing
I
was
gonna
note
is
that
what
I'm
suggesting
I
think
is
very
minor.
It
would
just
be
adding
a
new
virtual
metadata
field
just
to
see
how
it
plays
out,
but
if
we'd
rather
do
that
after
after
the
preview
release,
then
that's
that's
fine
with
me.
I
just
see
this
as
a
configuration
change,
essentially
yeah,
but
what.
C
C
We
also,
you
know,
came
up
with
this
solution
very
quickly
on
the
spot
when
we
first
started
thinking
about
named
variants,
but
the
longer
we
thought
about
it,
the
less
we
got
convinced
of
the
different
options.
I
don't
know.
Even
today,
we
are
not
a
hundred
percent
convinced
that
it
should
be
one
of
the
two
options
that
we
put
forward
and
I.
C
A
C
C
C
C
D
C
Yeah,
it
has
a
lot
to
do
with
I
can't
comment
on
the
details
of
all
of
those
implementations,
because
some
of
them
are
not
public
repositories.
I
understand,
yeah,
but
so
that
it
mostly
comes
down
to
where
you
want
to
put
the
control
over
using
name
variants
with
CAD
loggers
or
how
you
want
to
deal
with
the
metadata
on
the
publication.
C
Some
people
want
the
metadata
of
the
publication
to
be
exactly
the
way
that
it's
on
the
you
know,
the
the
publication
itself,
the
PDF
and
others
would
like
to
see
their
name
correct
it
in
the
metadata.
In
the
repository
they
say.
Ok,
we
want
to
have
like
my
misspelled
name
on
the
publication
itself:
I
don't
care,
but
on
the
public
on
the
the
landing
page,
the
item
page,
they
want
it
correctly
and
yeah
it's
all
about
where,
where
is
the
control
over?
What
gets
used
as
the
name
variants
and
whatnot?
C
And
how
does
it
get
displayed
and
different
institutions
have
different
opinions
about
it?
So
I
think
if
we
would
come
forward
with
an
implementation
on
named
variants,
I'm
quite
certain
that
there
will
be
people
making
comments
that
they
want
the
other
way
around,
regardless
of
which
solution
we
pick.
So
this.
D
A
But
yeah,
let's
go
ahead
and
close
up.
The
meeting.
I
think
that
we've
come
to
a
conclusion,
though,
that
will
leave.
Variants
can
probably
wait
till
after
the
preview
release
and
we
can
kind
of
go
with
author
profiles,
as
is
for
the
most
part.
So
then,
in
two
weeks
we
will
be
really
concentrating
more
on
pull
requests
and
during
that
the
code
is
get
is
been
reviewed
and
moving
things
forward
as
quickly
as
possible,
so
that
we
can
try
and
get
this
code
ready
to
go
hopefully
by
the
end
of
December
early
January.