o’.‘..'.
J
.
.\
o
@
&
)S)
samvera”
L
api{elnlilegale])
The
Samvera
Geo
Predicates
working
group
was
established
in
2017:
«
Obijective:
To
develop
a
core
set
of
recommended
RDF
predicates
sufficient
for
basic
description
of
geospatial
resources
in
a
Samvera
repository
when
combined
with
default
metadata.
*
Need:
Geospatial
resources
require
specialized
metadata
elements
for
adequate
description,
but
there
is
a
lack
of
consensus
around
what
individual
predicates
should
be
used
for
these
elements
in
a
linked
data/RDF
environment
like
Samvera.
We
elected
to
adopt
the
general
steps
outlined
in
the
Me4MAP
method
for
developing
a
metadata
application
profile
(Malta
2017),
which
is
based
on
the
Singapore
Framework
for
Dublin
Core
Application
Profiles
(DCMI
2008).
We
identified
several
tasks
within
the
method
as
key
steps
for
our
working
group:
«
S2
Developing
the
Domain
Model
*
A3
Environmental
Scan
«
S3
Developing
the
description
set
«
S3.1
Vocabulary
Alignment
This
poster
describes
work
to
develop
a
domain
model
to
serve
as
a
basis
for
a
partial
metadata
application
profile
for
geospatial
resources.
Domain
Model
for
Geospatial
Metadata
Application
Profile
John
Huck!,
Tom
Brittnacher?,
James
R.
Griffin
1113,
Eliot
Jordan3,
Kim
Durante?®
"University
of
Alberta,
2University
of
California
Santa
Barbara,
3Princeton
University,
“Stanford
University
RESOURCE
TYPES
We
enumerated
a
set
of
in-scope
and
included
geospatial
resource
types,
loosely
construed
as
types
of
geospatial
resources
that
might
be
shared
in
a
library
repository.'
This
was
an
intuitive
process,
based
on
the
collective
experience
of
the
working
group
members
with
collections
of
geospatial
resources.
This
set
of
resource
types
was
refined
so
that
each
type
was
distinct
and
did
not
overlap
with
any
other.
Some
resource
types
were
excluded
through
this
process,
because
they
were
deemed
to
be
included
in
another
type,
or
out
of
scope.
Sets
and
single
instances
of
the
types
were
defined
separately.
The
final
set
of
included
resource
types
is
given
in
the
table
below.
Almost
all
resource
types
were
defined
in
matching
pairs
of
single
and
collection
instances
to
more
closely
reflect
the
range
of
real
world
repository
objects.
v
SNl
[cap
=0
(el
N
Quoting
Baker
&
Coyle
(2009),
Malta
defines
a
domain
model
as
“a
description
of
what
things
your
metadata
will
describe,
and
the
relationships
between
those
things.
The
domain
model
is
the
basic
blueprint
for
the
construction
of
the
application
profile,”
and
further
specifies
that
"it
identifies
the
entities
and
their
relationships,
and
the
entities
attributes
(e.g.,
datatypes
and
other
attributes
with
literal
values)"
(Malta
2017).
Geospatial
resources
can
encompass
a
breadth
of
resource
types
and
formats,
and
it
can
be
tricky
to
categorize
them.
We
took
a
multi-step
approach
to
developing
a
set
of
domain
entities
for
the
model,
starting
with
a
list
of
concrete
resource
types,
then
determining
applicable
target
attributes,
and
finally
developing
a
generalized
set
of
domain
entity
classes
from
them.
This
approach
allows
conceptualization
to
emerge
from
the
results
of
a
concrete
scope-setting
step,
rather
than
be
imposed
prematurely.
It
also
represented
a
movement
from
conceptualizing
repository
objects
to
conceptualizing
metadata
objects.
_
Resource
Type
Name
R
R
1
2
3
4
5
6
7
8
9
10
11
(12
13
(14
15
(16
[17
scanned
map
scanned
map
set
scanned
geological
cross-section
scanned
geological
cross-section
set
aerial
photograph
aerial
photograph
set
georeferenced
scanned
map
georeferenced
scanned
map
set
georeferenced
aerial
photograph
georeferenced
aerial
photograph
set
remote
sensing
data
object
remote
sensing
data
set
vector
GIS
data
object
vector
GIS
data
set
raster
GIS
data
object
raster
GIS
data
set
mixed
GIS
data
set
TARGET
ATTRIBUTES
DOMAIN
MODEL
ENTITIES
Each
resource
type
was
characterized
in
terms
of
applicable
geospatial
metadata
attributes,
from
a
list
of
target
attributes
that
we
defined
ahead
of
time,
based
on
the
group's
collective
domain
knowledge.
What
we
called
a
"target
atiribute”
represents
a
piece
of
geospatial
metadata
for
which
we
seek
a
linked
data
predicate
capable
of
expressing
that
information.
General
attributes,
such
as
title
or
creator,
are
not
part
of
the
set
of
target
attributes,
because
a
founding
assumption
of
the
working
group
objective
is
that
these
attributes
are
already
provided
for
in
a
standard
metadata
vocabulary,
such
as
Dublin
Core
Terms.
Through
this
process,
we
identified
one
target
attribute
that
was
not
essential
(Geographic
Location
-
Description);
added
one
(Remote
Sensing
Details);
and
chose
to
expand
the
scope
of
another
(Spatial
Data
Representation
Type)
so
that
it
could
serve
to
express
the
type
characteristic
for
all
the
resource
types
we
identified.
the
DM
entities.
Domain
model
entities
were
abstracted
from
the
resource
types,
using
the
applicability
of
different
target
attributes
as
distinguishing
criteria.
We
found
that
there
was
a
set
of
base
target
attributes
universally
applicable,
which
established
a
base
class
for
a
general
geospatial
resource
within
the
model.
Other
classes
represent
specializations.
The
distinction
between
single
objects
and
sets
was
not
retained
for
extent
(TA1)
location
-
place
name
(TA2.1)
spatial
data
rep.
type
(TA5.1)
file
format
(TA6)
i
extent
(TA1)
location
-
place
name
(TA2.1)
spatial
data
rep.
type
(TA5.1)
file
format
(TA6)
remote
sensing
details
(TA9)
m
Target
Attribute
Name
A
{mixed
GIS
data
-
RT17}
extent
(TA1)
location
-
place
name
(TA2.1)
spatial
ref.
system
(TA4)
spatial
data
rep.
type
(TA5.1)
file
format
(TAG)
1
{scanned
geological
cross
section
-
RT3/4}
extent
(TA1)
location
-
place
name
(TA2.1)
scale
(TA3)
spatial
data
rep.
type
(TA5.1)
file
format
(TAB)
]
{raster
GIS
data
-
RT15/16}
extent
(TA1)
location
-
place
name
(TA2.1)
spatial
ref.
system
(TA4)
spatial
data
rep.
type
(TA5.1)
file
format
(TAB)
raster
resolution
(TA8)
{scanned
map
-
RT1/2,
georeferenced
scanned
map
-
RT7/8}
)
extent
(TA1)
location
-
place
name
(TA2.1)
scale
(TA3)
spatial
ref.
system
(TA4)
spatial
data
rep.
type
(TA5.1)
file
format
(TAB)
{aerial
photograph
-
RT5/6}
{remote
sensing
data
-
RT11/12}
{vector
GIS
data
-
RT13/14}
TA1.1
Geograp
TA1.2
Geograp
TA1.3
Geograp
TA1.4
Geograp
TA2.1
Geograp
TA3.1
TA3.2
TA3.3
hic
Extent
-
Bounding
box
(rectangle)
hic
Extent
-
Polygon
(Footprint)
hic
Extent
-
Path
hic
Extent
-
Point
hic
Location
-
Place
name
Scale
-
Representative
Fraction
Denominator
Scale
-
Text
Scale
-
Qualifier
TA4
Spatial
Reference
System
TA5.1
Spatial
Data
Representation
Type
(vector,
raster)
TA5.2
Spatial
Data
Feature
Type
(point,
line,
polygon)
TA6
File
Format
for
Geospatial
Objects
TA7
Flight
Altitude
TAS8
Raster
Resolution
(dimension
of
raster
pixel)
TA9
Remote
Sensing
Details
extent
(TA1)
location
-
place
name
(TA2.1)
spatial
data
rep.
type
(TA5.1)
file
format
(TAB)
flight
altitude
(TA7)
remote
sensing
details
(TA9)
extent
(TA1)
location
-
place
name
(TA2.1)
spatial
ref.
system
(TA4)
extent
(TA1)
location
-
place
name
(TA2.1)
spatial
ref.
system
(TA4)
T
spatial
data
rep.
type
(TA5.1)
file
format
(TAG)
raster
resolution
(TA8)
remote
sensing
details
(TA9)
f
-
RT9/10}
{georeferenced
aerial
photograph
extent
(TA1)
location
-
place
name
(TA2.1)
spatial
ref.
system
(TA4)
spatial
data
rep.
type
(TA5.1)
file
format
(TAG)
flight
altitude
(TA7)
raster
resolution
(TA8)
remote
sensing
details
(TA9)
spatial
data
rep.
type
(TAS5.1)
spatial
data
feature
type
(TA5.2)
file
format
(TAB)
REFERENCES
«
Baker,
T.,
&
Coyle,
K.
(2009).
Guidelines
for
Dublin
Core
Application
Proles.
Retrieved
April
12,
2016,
from
http://dublincore.org/documents/prole-guidelines/
«
Malta,
M.C.
(2017).
Me4MAP:
A
method
for
the
development
of
metadata
application
profiles.
Retrieved
October
1,
2018,
from
http://dublincore.org/resources/training/#2017Malta
*
Nilsson,
M.,
Baker,
T.,
&
Johnston,
P.
(2008).
The
Singapore
Framework
for
Dublin
Core
Application
Profiles.
Retrieved
October
1,
2018,
from
http://dublincore.org/documents/singapore-framework/