►
From YouTube: 2018-11-20 : DSpace 7 Entities Working Group Meeting
A
Okay,
we're
now
recording
so
welcome
all
again
to
our
every
other
week,
entities
working
group
meeting
and
let
me
go
ahead
and
share.
You-
should
have
the
agenda
already
from
slack,
but
I'll
add
it
into
the
zoom
chat.
Just
in
case
you
don't
have
slack
open
right
now
and
I'm
going
to
briefly
share
my
screen.
Just
kind
of
talk
through
a
couple
quick
points
up
front
here.
A
A
What
we
talked
about
was
a
subset
of
the
DS
space
leadership
group,
I,
should
say
group
oriented
more
towards
D
space,
7
release
timeline,
so
we
talked
about
the
timelines
and
goals
for
D
space
7
and
we've
we've
kind
of
sketched
out
some
rough
time
lines
which
are
listed
here
in
our
agenda,
and
these
are
not
fully
public
yet,
but
I
mean
they're
kind
of
out.
There
is
like
rough
estimates,
so
they
still
are
very
very
rough
estimates
and
our
first
goal
is
really
the
first
one.
A
We
want
to
try
and
hit
to
make
sure
everything
else
on
schedule.
So
the
first
goal
really
is
that
we're
not
going
to
have
any
releases
in
2018
coming
up
to
the
holidays.
Here
a
lot
of
folks
obviously
are
heading
off
on
holiday
for
or
vacation
or
whatever.
You
want
to
call
it
in
December
and
the
group
that
met
decided
that
doing
a
release
in
December
may
not
be
the
most
useful
for
our
community.
Just
because
a
lot
of
won't
get
a
chance
to
look
at
it
or
play
with
it.
A
But
we
do
want
to
ensure
that
configurable
entities
are
a
part
of
that
release,
because
the
goal
of
this
release
is
really
to
allow
people
to
start
to
play
around
with
D
space
7.
So
at
least
an
early
version
of
configurable
entities
should
be
available
within
that
preview
release
and
the
reason
we
have
that
in
late
January,
early
February
is
just
to
try
and
first
keep
us
on
our
toes
in
terms
of
making
sure
we're
moving
configurable
entities
along
quickly,
as
well
as
trying
to
to
potentially
get
out
of
release.
A
A
Working
group
is
really
getting
that
early
version
of
configurable
entities
merged
into
the
master
branch
by
by
that
timeline,
and
preferably
I'd
really
like
to
see
us
get
things
ready
to
go
by
the
end
of
2018
so
that
as
of
January,
we
we
all
come
back
from
holiday.
We
can
start
to
clean
things,
up,
get
things
ready
for
release
and
maybe
do
a
little
bit
of
bug
fixing.
A
So
that's
kind
of
our
goal
for
our
working
group.
The
next
timelines,
then
after
this
are
really
sort
of
rough
estimates
at
this
point
in
time,
so
the
next
goal
would
be
to
have
a
beta
release
out
by
hopefully
late
April.
That
would
be
the
first
release.
That's
feature
complete
in
terms
of
7.0
and
then
get
the
final
release
out
prior
to
open
repositories,
2019
and
open
repositories.
This
year
is
scheduled
for
the
it's
the
second
week
of
June.
So
in
order
to
make
that
deadline,
we
really
want
to
be
looking
towards
like
late
May.
A
Obviously,
if
we
can
move
these
timelines
by
moving
more
quickly,
that's
awesome.
If,
for
some
reason
we
are
late
on
our
first
preview
release,
then
it's
very
possible.
These
other
dates
may
may
have
to
change,
but
those
are
the
goals,
we're
looking
at
right
now
and
we
think
they're
very
doable
goals
from
all
the
discussions
within
the
that
leadership
group.
That
subgroup,
which
include
leaving
and
others
who
have
resources
available.
So
that's
kind
of
where
we
sit
with
our
rough
goals
for
dspace
seven.
A
A
Obviously
we're
working
on
a
configurable,
entity's
branch
right
now
within
both
the
angular
and
the
rest.
Api,
ideally
we'd,
be
to
a
pull
request
for
master
state,
so
we'd
want
to
have
things
really
really
good
to
go
and
ready
to
get
into
master
by
the
end
of
2018.
So
that's
kind
of
our
first
goal
here.
A
So
to
that
end,
moving
along
then
to
topic
number
two
here
is
really
where
we
sit
with
our
current
pull
requests.
As
we
know,
those
are
going
into
a
shared
branch
right
now
and
I'd
really
like
to
see
us
try
and
get
these
initial
pull
requests
merged
into
that
share
branch
pretty
soon,
if
possible,
sometime
within
the
coming
days
or
weeks.
However
long
it
takes
us
to
do
it,
but
obviously
the
sooner
the
better,
and
just
because
that'll
give
us
an
opportunity
to
build
more
pull.
A
A
Pull
request
as
well,
but
I
didn't
see
personally
any
reason
why
we
should
hold
this
up
any
further,
just
because
it
seems
like
it's
been
pretty
well
tested.
It's
gotten
some
reviews,
but
I
wanted
to
get
a
sense
from
others
who
were
reviewed
this,
whether
you
agree
with
that
or
if
you
have
any
other
comments
and
that
you'd
like
to
see
addressed
prior
to
merging
this.
A
B
A
B
B
C
D
A
A
D
A
Yeah
I
think
that
sounds
reasonable
as
well.
We
probably
should
track
that
somewhere
and
I'm,
trying
to
think
of
the
best
places
to
do
that
at
we
could
to.
We
could
start
creating
JIRA
tickets
for
some
of
these
tasks
that
we
know
we
want
to
clean
up,
especially
on
the
REST
API
side
and
I
can
flag
them
as
sort
of
with
a
label
related
to
to
the
entities
working
group,
but
that
does.
D
C
A
If
you
wanted
to
note
this
down
as
a
task
for
your
team
or
put
it
in
one
of
the
Google
Docs
or
someplace
that
we
can,
we
can
just
kind
of
track
that
then
that
might
be
the
good
enough
place
for
now
and
as
we
get
this
code
cleaned
up
to
represent
items
more
than
that's.
Maybe,
where
we'll
be
able
to
describe
these
things
better
in
JIRA
tickets,
as
we
continue
to
work
in
the
coming
weeks,.
A
A
A
In
terms
of
these,
these
upcoming
pull
requests
that
I
noted
and
the
feature
you
just
noted
as
well:
Paulo
I'm,
trying
to
think
of
the
best
place
to
track
those
down.
Maybe
I
can
actually
put
those
zero
well,
we
could
put
them
in
yeah
I'm,
trying
to
think
of
whether
they're
gonna
make
sense
in
JIRA
I'm
kind
of
going
back
and
forth
based
on
marks.
This
marks
note
that
these
might
not
make
is
good
make
make
as
much
sense
in
JIRA
well,
they'll.
C
A
A
So
we'll
get
those
three
tickets
created,
we'll
merge
this
particular
pull
request
and
then
we'll
start
to
move
forward
on
on
a
upcoming
pull
request.
I
guess
so
that
seems
like
a
good
direction,
then,
for
the
rest,
API
side
of
things
we'll
get
a
merger
three
new
tickets
and
move
forward
with
the
upcoming
pull
requests.
Sound
good!
D
Sounds
good,
then,
we'll
probably
soon
have
next
school
requests
already
for
rest,
based
on
some
improvements
that
we
already
made,
but
not
everything,
of
course,
from
from
Linda.
Yet
I
will
fire
them
once
I
review,
I
review
them.
A
Give
me
a
moment
here:
okay,
so
I
had
I
finally
got
around
to
reviewing
this
yesterday.
It
took
me
quite
a
while
to
get
through
the
code,
there's
just
a
lot
of
code
changes
here,
but
but
overall
I
tested
it
out
and
and
found
that
the
code
seems
to
be
working.
Okay,
I
didn't
notice
any
bugs,
as
I
was
kind
of
browsing
around
through
the
through
the
data
and
I
just
tested
it
against
the
demo.
A
Rest
API
that
at
Meijer
is
already
hosting
so
I
noted
just
three
things
here
again,
and
none
of
these
I
think
are
massive
blockers
again
I
think
similar
to
the
REST
API.
We
need
to
rename
the
entities
to
be
items,
so
that
would
be
another
follow-up
pull
request
after
this
one
I
did
ask
a
couple
questions
around
a
particular
component,
which
I
think
art
answered
today
and
I
admit.
A
I
haven't
actually
gone
back
to
see
arts
answer
to
make
sure
it
makes
sense
to
me,
but
I
noted
that
one
of
the
components
is
has
a
very
awkward
name
and
I
did
not
quite
understand
the
structure.
What
a
page
field
component
is
so
I
was
talking
kind
of
talking
through
that
within
the
code
comments,
and
then
one
out
of
the
one
final
note
I
had
in
here
is
again
I.
Think
in
a
follow
up.
Pr.
Is
that
a
lot
of
these
the
components
within
this?
A
So
it
was
kind
of
a
general
comment
and
that's
something
we
might
want
to
to
brainstorm
a
little
bit
more
about
I'm,
not
sure
how
that
applies
to
all
of
our
various
entities
or
how
best
to
package
these
up.
But
I
was
just
noticing
that
they're
not
as
standalone
as
we
may
think
they
are
they're
very
interdependent.
I.
A
Yeah,
so
module
is
an
actual
angular
concept
and
that's
how
angular
tends
to
treat
extensions
in
a
lot
of
ways,
so
they
package
things
up
as
modules
and
modules
are
really
just
kind
of
packaging
of
various
related
components,
and
this
would
provide
a
first
initial
good
example
of
how
how
various
types
of
entities
that
relate
together
can
really
be
deployed.
As
as
modules
you
can
install
within
your
hangar
there
UI
in
a
you,
know,
fashion
that
makes
them
a
little
bit
more
configurable.
A
But
those
were
my
main
three
points.
I
did
have
a
lot
of
inline
comments
that
I
know
art
is
getting
to
in
terms
of
small
little
things
that
I
ran
across
within
the
code
and
areas
where
there's
missing
missing
specs
some
missing
tests
most
the
specs
are
there,
but
there
are
some
areas
that
I
found
missing
tests
and
missing
comments
that
I
that
I
commented
on.
But
most
of
my
comments
on
the
on
the
angular
side,
I
feel
like
are
pretty
minor
overall,
without
with
the
exception
to
those
three
upper
level
points.
A
So
I
felt
like
it's
it's
it's
in
a
pretty
good
state,
but
I
wanted
to
see
if
anyone
else
has
had
a
chance
to
review
this
to
test.
This
I
know
I'm,
probably
the
most
knowledgeable
on
the
angular
code
side
of
things
of
everybody,
so
maybe
code
reviews
not
the
most
the
highest
priority
here,
but
I
appreciate
to
have
it
appreciate
others
testing
it
taking
a
look
at
it,
seeing
what
you
think
with
with
how
it
currently
sits
as
well
so
I'll
pause
here.
B
This
some
little
time
to
watch
how
to
try
to
make
it
work
and.
B
A
D
B
D
D
A
A
In
terms
of
that,
a
lot
of
the
views
around
creating
entities
are
quite
similar
in
nature,
where
it's
just
a
matter
of
kind
of
selecting
which
fields
to
to
apply
to
the
that
entity
to
display
for
that
entities
display,
and
so
it
seems
like
it
makes
it
a
little
bit
easier
for
people
to
to
just
kind
of
create
your
own
entity
components
in
a
way.
That's
that's
quite
quite
simple.
So.
A
Think
that
that's
already
kind
of
somewhat
there
to
some
extent,
but
it
could
use
a
more
generic
basic
entity
like
you're
talking
about
Paulo,
but
I,
guess
here,
I'll
actually
show
we
got
it
I'm
just
didn't
I
know
we
have.
We
need
other
discussion
to
get
to,
but
I
do
want
to
share
real
quick.
My
screen
just
to
show
you
what
I'm
talking
about
here
in
terms
of
how
entities
are
structured.
A
A
What
it
looks
like,
and
so
the
actual
component
itself
is
pretty
small
and
it
just
kind
of
shows
that
a
journal
issue
is
related
to
a
volume
and
it's
related
to
a
publication
and
in
terms
of
things
that
are
in
this
issue,
and
those
are
item
arrays,
so
it
this
this
code
concept
here
is
actually
relatively
simple.
It's
most
mostly
around
the
relationships
and
a
lot
of
these
look
similar
and
then
in
the
actual
component,
HTML
itself.
So
this
goes
with
that
component.
Here
we
got.
A
We
actually
then
get
to
select
what
fields
we
want
to
display.
So
we
have
a
journal
volume.
We
have
an
issue
date,
things
of
that
nature
and
then
we're
going
to
display
our
relationships
and
another
section
of
divs.
So
the
way
the
code
is
structured
is
quite
configurable
in
a
lot
of
ways
and
a
lot
of
these
entities
look
quite
similar.
A
Okay,
any
so
I
guess
the
next
step
on
this.
What
do
we
feel
like
would
be
the
next
step
here.
Do
others
want
to
give
this
a
quick
try
in
terms
of
testing
it
out?
We
want
to
try
and
have
a
similar
process
where
we're
going
to
merge
this
relatively
soon
to
the
the
shared
branch
and
have
some
follow-up
PRS
to
clean
up
those
those
things
that
I
had
questions
on
still
like
this
one
has
a
lot
less
feedback.
So
I
don't
know
if
you
all
want
to
have
a
chance
to
do
more
review
here.
A
A
E
Most
likely
the
the
it
will
most
likely
be
the
same
errors,
because
I
used
it
extensively
to
set
up
the
data
for
the
journal,
issuer
icky
and
then
copied
over
all
the
data
from
some
other
journal
that
was
hosted
online
and
I
ran
into
a
few
problems
with
the
CSV
importer,
and
those
have
all
been
addressed
now
been
I
think,
but
are
ready
for
for
a
follow-up
request
right.
Yes,.
B
D
A
So
so
it
sounds
like
I
mean
Paulo.
If
you,
if
you
haven't,
had
a
chance
to
fully
test
this,
would
it
be
useful
to
do
some
more
tests
on
your
end
or
anyone
else
want
to
run
some
tests,
whether
it's
against
I,
don't
think
it
needs
to
be
against
a
local
version
of
the
data.
But
at
least
we
could
run
some
tests
against
the
existing
REST
API
that
is
hosted
at
Meijer
and
make
sure
that
the
browsing
and
the
searching
that
functionality
seems
to
be
working.
Okay
and
if
there's
other
bugs
along
the
way.
E
A
That
yeah,
that's
fine,
then
so
yeah.
If
this,
if
this
can
wait
a
little
while,
then
let's
give
the
rest
of
the
team
time
to
to
run
some
tests
on
the
angular
side.
Make
sure
that
everything
looks
good
and
make
sure
my
comments
and
arts
comments
back
and
forth
are
all
clarified
here
along
the
way
you.
E
A
So
that
sounds
like
a
good
plan
then
so
on
the
rest,
api
say
we
already
have
our
plan
to
get
that
merged
right
away
on
the
angular
side.
I
might
appreciate,
if
others
do
some
testing,
you
can
even
just
do
your
testing
against
the
current
demo
site
as
needed
and
report
back
and
also
take
a
look
at
the
comment
discussion
between
myself
and
art
that
have
already
been
added
in
here
within
the
last
day.
So
we
can
clarify
any
questions
that
have
that
come
up
within
there.
E
A
Either
yeah
either
way
I
think
we
have.
We
should
just
do
a
thorough
review
here
on
the
angular
pull
request,
anyways
and
there
are,
and
I
still
have
to
read
back
through
arts
responses
back
to
make
sure
that
I
understand
everything
that
is
going
on
here,
because
I
had
quite
a
few
questions,
so
it
sounds
like
we'll
just
see
which
one
gets
merged
first,
and
there
will
be
plenty
of
time
for
others
to
test
this
this
week
to
verify
everything
looks
good
to
them
too.
Okay,
an.
E
A
A
That's
where
we
had
a
Google
Doc,
that's
linked
in
here
and
bold
and
the
agenda
which
I'll
copy
into
our
chat.
Here
in
case
you
don't
have
the
agenda
in
front
of
you,
so
there's
the
Google
Doc
and
our
zoom
chat
and
I'm
leaving
I,
don't
know
if
you
want
to
lead
us
through
this
I'm
going
to
admit
that
I
have
not
had
a
chance
to
review
this
thoroughly
yet
because
I
was
more
trying
to
get
the
angular
reviewed
on
yesterday
and
hadn't
had
a
chance
to
look
at
this
today.
A
E
E
First,
the
author
profile
use
case
in
itself,
so
an
author
profile
page
must
provide
metadata
about
the
author
entity
that
had
already
been
described
in
the
main
documentation
we
created
about
configurable
items,
just
no
identity,
calling
them
configurable
entities.
There
are
some
examples
there
already.
So
this
is
an
example
in
our
prototype.
E
E
There
is
another
example
there
that
goes
a
little
bit
further
in
terms
of
relations
with
other
objects,
where
you
also
have
relations
to
projects
as
in
the
cris
model
and
org
units.
So
this
person
is
part
of
the
org
unit
admire
and
it's
collaborating
on
test
project
one,
and
so
you
can
of
course,
click
through
and
see
other
authors
that
are
related
to
this
project,
publications
that
are
related
to
a
project
and
work
units.
E
The
second
one
file
page
must
be
able
to
display
virtual
metadata
from
Associated
Works
articles
or
books.
Named
variants
should
be
displayed
for
each
associated
work.
For
example,
you
should
know
which
works
were
published
under
each
name
variant.
This
immediately
goes
into
a
broader
discussion,
and
so
there
are
two
parts
to
the
discussion.
One
part
is:
how
do
we
add
extra
values
to
a
relation?
E
E
We
prefer
for
adding
extra
values
to
a
relation,
and
so
I
create
an
extra
section
at
the
bottom
additional
data
for
relations
here
where
the
first
case
is
adding
additional
field
in
the
relationship
database
table,
or
it's
just
an
extra
field
that
has
no
further
qualifier
or
meaning,
and
it
can
contain,
for
example,
the
name
that
is
used
on
a
particular
publication.
There
is
some
advantages
to
that
or
a
song,
some
complexity.
E
And
some
lists
of
what
are
the
implementation
changes
that
we
would
need
to
do
to
be
able
to
implement
that
and
what
are
remaining
challenges?
These
are
I'll
highlight
these.
Instead,
you
know
this
is
a
simple
solution,
relatively
quick
to
implement,
but
the
problem
is
that
there
is
no
structure
about
what's
in
this
text
field.
E
A
second
option,
which
requires
more
implementation
but
would
be
more
sustainable
on
the
long-term,
is
to
implement
a
relationship
as
a
dspace
object,
so
that
the
relationship
itself
can
have
metadata
associated
with
it
and
where
we
can
actually
just
use
the
the
metadata
registry
to
say.
Okay,
this
is
a
start
date.
E
This
is
an
end
date
so,
but
it
would
require
quite
a
bit
more
implementation
work
at
the
moment,
but
it
would
be
more
usable
on
the
long
term
and
with
more
for
more
different
use
cases
where
we
want
to
add
extra
information
to
a
relation.
And
finally,
it
would
also
help
with
permissions
on
a
relationship.
A
A
I,
don't
know
for
certain
I
I,
admit:
I,
don't
I,
don't
have
a
solution
in
mind,
but
I'm
just
wondering
if
there's
a
way
to
to
store
these
name
variants
on,
like
the
the
author
object
itself,
just
as
metadata
regular
metadata
and
then
link
that
metadata
field
using
the
authority
system
somehow
to
what
that
metadata
field.
What
other
object
that
metadata
field
relates
to
like
the
article
that
it
relates
to
or
something
like
that
so
I,
just
wonder.
If
there's
a
way
we
can
do
this
through
authorities.
Well,.
E
E
So
that's
that's
a
second
question
that
the
first
question
is
like:
how
do
you
store
additional
information
about
relations
in
the
system
and
then,
like
I,
said
another
example
could
be
a
start
and
an
end
date
of
a
relation
between
an
author
and
an
org
unit,
and
so
I
mean
using
authority
control,
it's
very
similar
to
the
first
solution.
It's
it's
just
you're.
Storing
a
text
value
and
you
have
no
idea
what
it
is.
E
You
don't
know
if
it's
a
name,
if
it's
it's
just
a
text
value
whether
you
store
it
in
authority
control
or
you
store
it
in
the
database
table
I
mean
personally
that
first
site
I
think
wouldn't
make
that
big
of
a
difference.
I
think
the
question
is
more
on,
you
know:
do
we
see
other
use
cases
here
as
well
and
do
we
want
to
be
able
to
explicitly
know
what
the
value
means
you
know
and
be
able
to
say
this
is
this
is
metadata
and
it's
a
DC
contributor?
A
E
E
What
it
can
be
used
for,
so
you
could
use
it
for
a
storing
alternative
label
or
a
name
variant.
It
could
point
to
a
specific
name
variant
to
be
used
on
the
publication,
for
example,
DC
contributor
author
person
name.
So
it's
similar
to
what
you
were
mentioning
and
then
we
give
the
example
of
storing
a
start
and
end
date
for
a
relation.
E
D
Can
also
have,
for
instance,
delete
permission
so
that
you
can
determine
whom
has
Commission
to
delete
that
relation.
That
would
just
be
another
added
value
of
using
those
space
objects
and,
of
course,
editing.
That
metadata
can
be
something
that's
similar
to
editing
collection,
metadata
item
metadata
would
just
be
a
similar
you.why
and
are
similar
and
make
sure
that
you
can
determine
what
information
you're.
D
No,
let
me
rephrase
it,
you
can
have
a
single
publication
on
a
single
person
and
have
two
relations
between
them,
one
as
an
author
and
one
as,
for
instance,
an
editor
that
would
make
it
much
harder
to
store
the
name
variants
on
a
publication
and
compared
to
the
relation
itself,
where
it's
clear.
It's
this
specific
relation.
We're
talking
about
that
was
maybe
a
little
bit
too
abstract.
D
A
I
mean
I:
am
we
don't
have
to
hang
up
on
this
right
now,
but
I
think
this
is
a
bigger
discussion,
because
I
worry
about
the
complexity
of
that.
To
be
frank,
just
that
it's,
it
seems
like
we're.
We're
storing
metadata
in
so
many
different
areas
that
how
are
you
ever
going
to
know
where
your
name
variants
are
stored,
like
as
a
repository
manager?
How
do
you
know
what
object
to
edit
to
change
a
specific
field?
A
And
how
do
you
know
how
to
do
this
via
like
feel
like
CSVs
and
stuff,
like
that
I'm
like?
How
do
you
manage
these
fields
and
I
I
actually
disagree
that
the
the
metadata
is
entirely
on
the
relationship,
because
I
think
the
metadata?
Some
of
these
metadata
fields
exist,
regardless
of
whether
the
relationship
is
there.
So
things
like
a
named
variant
that
exists
on
a
publication
whether
or
not
that
publication
is
related
to
an
actual
author
in
the
system
you're
going
to
have
the
name
at
the
publication
used
and
you're
going
to
have
the
name.
A
If
the
person
is
an
author
and
an
editor
on
that
publication,
you're
going
to
have
those
names
stored
on
the
publication,
regardless
of
whether
there's
any
relationship
stored
in
the
system
and
I
think
that
same
thing
occurs.
If,
if
there's
dates
as
to
when
you
were
a
member
of
an
organization,
if
you
have
an
author
profile
on
a
system,
but
your
organization
does
not
exist
in
the
system,
you
still
should
be
able
to
store
dates
that
you
were
a
member
of
a
particular
organization,
whether
or
not
that
organization
exists
in
the
system.
A
E
I
agree
to
a
certain
extent,
with
the
the
use
case
for
the
name
variant,
but
not
for
the
dates
for
the
relationship
I
mean
if
you
think
about
the
dates
for
the
relationship.
You
wouldn't
store
that
as
regular
metadata
in
the
system
right
now,
because
what
are
those
dates
to
which
organization
the
organizational
unit
are
they
linked?
So
those
I
think
are
really
metadata
of
the
relation
rather
than
metadata
of
either
the
author
or
the
the
organizational
unit.
I
mean
the
the.
E
If
the
organizational
unit
doesn't
exist
as
an
item
type
in
the
repository,
the
name
of
that
organizational
unit
will
be
metadata
of
the
person
object
or
the
person
item
type,
but
the
dates
would
not
be
I
mean
that
date
in
itself
would
not
mean
anything
unless
you
have,
for
example,
her
ARCA
commanded.
It
right.
A
E
E
C
A
C
A
A
So
my
point
is:
is
that
all
of
assuming
that
all
of
these
relationships
need
to
exist
within
the
system,
I
think
is
a
somewhat
flawed
assumption
that
that
different
institutions
are
going
to
want
to
store
different
types
of
org
units
and
different
types
of
organizations
within
their
system.
But
they
don't
want
to
have
to
store
all
of
them
in
order
to
make.
C
What
I'm
hearing
here
is
that
there
are
cases
where
a
an
author
would
want
to
have
information
in
his
record.
That
is
not
related
to
anything
as
far
as
dspace
is
concerned,
so
it's
just
an
other
field.
It
has
a
string
label
and
a
string
value.
There
is
no
relationship
as
far
as
the
software
is
concerned,
correct.
A
You
and
I'm
just
worried
that
going
down
this
route
of
trying
to
build
these
relationships
very
hard
within
D
space
is
not
a
route.
That's
gonna
bring
us
in
the
right
direction,
especially
if
we
later
want
to
try
and
figure
out
ways
to
do
hierarchical
metadata,
which
is
where
this
sort
of
information
would
be
better
represented,
rather
than
trying
to
build
the
hierarchy
into
the
object
model.
Given
the.
E
E
So
that's
example,
I
already
showed
here
where
this
author
was
a
member
of
this
or
you
need
to
dates
yet,
as
we
just
discussed
so
that's
possible,
but
then
for
the
use
case
which
works
were
published
at
each
organization.
This
is
where
actually
also
hierarchical,
metadata
comes
into
play,
because
we
feel
that
you
should.
We
shouldn't
resolve
that,
through
the
secondary
relation
of
the
author
between
the
org
unit
and
use,
for
example,
the
date
published
to
determine
which
org
unit
of
that
person
was
applicable
at
the
time
of
the
publication.
E
A
E
Because
it
can
happen
that
an
author's
work
has
been
published
after
that
person
already
left
that
org
unit
due
to
the
lengthy
publication
process
sometime.
So
that
should
be
like
a
link
between
the
publication
of
the
origin
I'd,
rather
than
a
link
between
the
publication
and
the
author
and
the
author
and
the
org
unit
and
using
a
date
to
determine
when
which
org
unit
that
that
person
at
that
time
was
related
to
too,
because
you
could
also
have
to
ord
units
that
you're
associated
with
you
still
wouldn't
know.
So.
E
This
also
makes
the
case
for
article
metadata,
and
so
our
final
thoughts
were.
Maybe
we
should
just
leave
all
this
4d
space
8
and
have
a
good
proposal
for
an
implementation
for
her
article
metadata
ad
space
aid,
rather
than
now
doing
something
that
yeah
that
we
would
not
reuse.
Indeed,
space
8
anymore.
If
these
base
8
house
or
commodity
I
think.
C
A
Correct
yeah,
yeah
and
I
can
agree
with
that
as
well.
I
think
the
only
thing
I'd
I
asked
us
to
think
about
it.
Maybe
this
is
for
our
next
meeting
since
we're
over
time
here
is
is
where
that
line
is
sort
of
drawn
like
which
things
are
definitely
hierarchical,
metadata,
in
which
case
we're
kind
of
taking
them
off
the
table
for
D
space
7
and
putting
them
on
the
table
for
D
space
8
and
which
of
these
are
maybe
not
as
much
hierarchical
but
just
could
be
somehow
defined
in
the
existing
system
like
I
guess.
C
A
F
C
A
Yeah
I'm
not
sure
if
it
gives
us
a
ton
of
freedom
in
D
space
7,
although
that
will
need
to
be
able
to
export
these
relationships
and
things
of
that
nature
intimate
so
that
we
can
do
things
like
it.
Do
the
AIP,
backup
and
restore
and
stuff
of
that
nature,
but
as
we
get
into
hierarchical
metadata,
maybe
there
is
a
there's
more.
We
can
do
there,
I
don't
know,
but
since
we're
over
time
we're
already
five
minutes
over
and
I
know,
people
have
to
run.
I
would
suggest.
A
Let's
bring
some
of
this
discussion
to
our
next
meeting.
In
terms
of
which
of
these
pieces,
we
feel
as
hierarchical,
metadata
and
kind
of
where
we
want
to
draw
the
line
here,
which
things
we
feel
we
kind
of
trained
want
to
get
into
D
space
7
in
some
way
and
which
things
we
probably
should
just
say.
This
is
hierarchical.
Metadata
will
do
this
in
T
space
8,
because
I
agree
with
that
sort
of
approach.
A
E
I,
just
could
point
out
that
so
the
highlight
it's
liked
it
works
is
there
we
have
described
how
you
could
do
it,
because
it's
quite
easy
to
do,
but
we
didn't
implement
it.
The
author
profile
resonated
listing
searcher,
searchable
and
sortable
has
been
implemented
so
that
actually
work
so
you're
now
searching
within
with
caching
problems
causing
issues
here.
So
if
you
search
on
something
like
memory,
you
get
only.
E
Those
are
seven
results
and
you
have
the
facets
that
are
only
related
to
the
selection
of
your
seeing
so,
and
this
is
just
reading
the
search
component,
the
main
search
component
with
an
additional
filter.
We
do
still
want
to
remove
this
here,
but
so
that's
fully
implemented,
and
so
the
main
use
cases
or
the
main
points
for
this
use
case
are
addressed
and
implemented,
is
just
the
name
variant
and
the
other,
if
I'm
just
going
to
call
it
metadata
for
relations
but
feel
free
to
think
of
it
in
another
way.
E
A
E
So
you
could
have
all
three
possible
values
for
an
author
and
you
still
want
to
be
able
to
display
it
properly
on
the
item
page
in
their
order
that
you
submitted
it
in
because
the
author
ordering
is
important-
and
here
is
also
a
pro
to
do
that
and
to
makes
those
three
types
of
values
in
one
metadata
field,
and
it
would
be
good
to
also
read
through
this
proposal
so
that
we
can
discuss
that
as
well
in
the
next
meeting.
That's
what
I
wanted
to
point
out?
Okay,.
A
Thank
you
very
much.
Yeah
yeah
and
I
will
be
out
of
the
office
for
the
rest
of
the
week
after
today,
so
I
will
wrap
up
the
things
on
the
rest,
epi
PR
today
and
then
and
we'll
I'll
be
talking
to
you
more
next
week
when
I
return,
but
I
hope
you
all
have
a
good
rest
of
your
week
and
those
of
you
who
are
in
the
States,
which
I
think
is
pretty
much
just
mark,
have
a
good
holiday
as
well,
and
we
will
talk
again
on
December
4th
in
two
weeks.
Okay,.