Copyright
©
2015
W3C
®
(
MIT
,
ERCIM
,
Keio
,
Beihang
),
All
Rights
Reserved.
).
W3C
liability
,
trademark
and
document
use
rules
apply.
This
document
defines
the
procedures
and
rules
to
be
applied
when
mapping
converting
tabular
data
into
JSON.
Tabular
data
may
be
complemented
with
metadata
annotations
that
describe
its
structure,
the
meaning
of
its
content
and
how
it
may
form
part
of
a
collection
of
interrelated
tabular
data.
This
document
specifies
the
effect
of
this
metadata
on
the
resulting
JSON.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
The CSV on the Web Working Group was chartered to produce Recommendations for "Access methods for CSV Metadata", "Metadata vocabulary for CSV data" and "Mapping mechanism to transforming CSV into various Formats (e.g., RDF, JSON, or XML)". This document aims to satisfy the JSON variant of the mapping Recommendation.
Due
to
the
limited
resources
available
within
the
CSV
on
the
Web
Working
Group,
this
document
describes
only
a
simple
mapping
—that
is,
where
a
single
object
is
created
for
each
row
of
tabular
data
that
contains
a
single
property
per
cell.
The
Working
Group
solicits
input
on
the
value
of
mapping
a
single
row
of
tabular
data
into
multiple
inter-related
objects.
This
document
was
published
by
the
CSV
on
the
Web
Working
Group
as
a
First
Public
Working
Draft.
This
document
is
intended
to
become
a
W3C
Recommendation.
If
you
wish
to
make
comments
regarding
this
document,
please
send
them
to
public-csv-wg@w3.org
(
subscribe
,
archives
).
All
comments
are
welcome.
Publication
as
a
First
Public
Working
Draft
does
not
imply
endorsement
by
the
W3C
Membership.
This
is
a
draft
document
and
may
be
updated,
replaced
or
obsoleted
by
other
documents
at
any
time.
It
is
inappropriate
to
cite
this
document
as
other
than
work
in
progress.
This document was produced by a group operating under the 5 February 2004 W3C Patent Policy . W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy .
This document is governed by the 1 August 2014 W3C Process Document .
This
document
describes
the
processing
of
tabular
data
to
create
a
set
of
nested
objects
referred
to
as
the
output
graph
.
The
output
graph
SHALL
that
MUST
be
serialized
as
JSON
[
json
RFC7159
].
The
conversion
of
CSV
content
to
JSON
encoding
is
intended
for
web
developers
who
need
not
care
about
the
complexities
of
RDF
[
rdf11-concepts
].
Where
the
formality
of
RDF
is
required,
[
csv2rdf
]
provides
the
procedures
for
mapping
from
CSV
content
to
RDF
which
may
be
serialized
to
[
json-ld
].
The
Tabular
Data
Model
[
tabular-data-model
]
defines
a
core
an
annotated
tabular
data
model
consisting
of
tables
,
columns
,
rows
,
and
cells
.
Tabular
data
may
be
,
enriched
with
metadata
annotations
that
describes
its
describe
the
structure
of
the
tabular
data
and
the
meaning
of
its
content.
These
metadata
annotations
are
described
in
[
tabular-metadata
]
and
may
be
embedded
within
the
CSV
encoding
itself
as
a
header
line
or
provided
within
a
separate
metadata
document.
The
resulting
annotated
table
conforms
to
the
annotated
tabular
data
model
.
The
metadata
annotations
may
describe
how
a
table
A
group
of
tables
relates
to
is
a
group
collection
of
tables
.
Such
collections
conform
to
the
grouped
tabular
data
model
.
published
as
a
single
atomic
unit.
The
mapping
conversion
procedure
described
in
this
specification
operates
on
the
abstract
annotated
tabular
data
model;
core
,
annotated
or
grouped
.
No
discussion
is
given
to
model
.
This
specification
does
not
specify
the
processes
needed
to
convert
CSV-encoded
data
into
tabular
data
form.
Please
refer
to
[
tabular-data-model
]
for
details
of
parsing
tabular
data
.
Further
details
on
parsing
cells
within
tabular
data
is
provided
in
[
tabular-metadata
Conversion
applications
MUST
provide
at
least
two
modes
of
operation:
standard
].
and
minimal
.
Adopting
terminology
Standard
mode
conversion
frames
the
information
gleaned
from
the
Data
Catalog
Vocabulary
[
vocab-dcat
cells
],
of
the
tabular
data
is
considered
to
be
a
dataset
,
whilst
with
details
of
the
CSV
file
rows
,
tables
,
and
a
group
of
tables
within
which
that
tabular
data
is
encoded
information
is
considered
to
be
a
distribution
of
that
tabular
data.
provided.
Minimal
mode
conversion
includes
only
the
information
gleaned
from
the
cells
Are
of
the
abstract
tabular
data
and
the
CSV
that
encodes
it
within
the
same
thing?
(Is
DCAT
distribution
appropriate?)
output.
The
mapping
procedure
is
intended
to
be
simple;
encouraging
the
provision
of
compliant
mapping
applications.
The
limitation
of
this
simple
mapping
is
that
a
single
object
is
created
for
each
row
Standard
of
tabular
data
that
contains
a
single
property
per
cell
and
minimal
conversion
are
described
normatively
below
.
An
annotated
table
may
include
a
reference
to
a
template
specification
(see
Conversion
applications
MAY
offer
additional
implementation
specific
conversion
modes.
Transformation
definitions
,
as
defined
in
[
tabular-metadata
])
that
describes
]
MAY
be
used
to
specify
how
tabular
data
can
be
transformed
into
another
format
using
a
template-based
approach.
Templating
script
or
template.
Such
transformation
definitions
MAY
facilitates
far
more
sophisticated
transformations
than
are
possible
using
the
simple
mapping
.
There
is
no
standard
template
syntax,
therefore
template
specifications
may
be
written
using
existing
template
languages,
such
as
Mustache
.
The
processing
of
template
specifications
during
the
mapping
is
yet
to
be
determined
by
the
Working
Group
and
is,
at
least
for
the
interim,
beyond
the
scope
of
this
document.
Finally,
note
that
the
mapping
procedure
is
considered
to
be
entirely
textual
.
There
is
no
requirement
on
compliant
mapping
applications
to
check
the
semantic
consistency
of
the
data
during
the
mapping,
nor
validate
use
the
cell
values
against
JSON
syntax
rules.
Where
cell
values
within
CSV
encoded
content
are
improperly
formatted,
the
output
from
the
mapping
is
likely
to
include
syntax
errors.
Downstream
applications
should
be
aware
of
described
in
this
and
take
appropriate
action.
Issue
62
Should
the
RDF/JSON
transformation
check
the
values?
specification
as
input.
As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.
The
key
words
MAY
,
and
MUST
,
SHALL
,
and
SHOULD
are
to
be
interpreted
as
described
in
[
RFC2119
].
Tabular
data
MUST
conform
to
the
description
from
[
tabular-data-model
].
In
particular
note
that
each
row
MUST
contain
the
same
number
of
cells
(although
some
of
these
cells
may
be
empty).
Given
this
constraint,
not
Not
all
CSV-encoded
data
can
be
considered
to
be
parsed
into
a
tabular
data.
As
such,
the
procedures
and
rules
defined
in
this
document
cannot
be
applied
to
all
CSV
files.
This
document
relies
on
terms
(e.g.
group,
table,
column,
row,
cell)
defined
data
model.
An
algorithm
for
parsing
CSV-based
files
is
described
in
[
tabular-data-model
].
The
procedures
following
typographic
conventions
are
used
in
this
specification:
markup
markup
definition
reference
markup
external
definition
reference
Core
Tabular
Data
lacks
any
annotation;
neither
from
the
Notes
are
in
light
green
boxes
with
a
green
left
border
and
with
a
"Note"
header
line
within
in
green.
Notes
are
normative
or
informative
depending
on
the
CSV
file
nor
from
whether
they
are
in
a
separate
metadata
document.
normative
or
informative
section,
respectively.
Examples are in light khaki boxes, with khaki left border, and with a numbered "Example" header in khaki. Examples are always informative. The content of the example is in monospace font and may be syntax colored.
The procedures for converting tabular data into JSON are described below for both standard and minimal modes.
distribution
null
or
a
sequence
of
values.
notes
property.
This
may
be
an
empty
list.
null
.A conformant JSON conversion application MUST produce output conforming to this algorithm according to the chosen mode of conversion: standard or minimal .
What
should
Where
an
annotated
table
is
defined
in
isolation
(e.g.
in
the
name
absence
of
the
property
be
a
group
of
tables
),
a
default
group
of
tables
is
provided
with
a
single
tables
annotation
that
relates
rows
refers
to
the
table?
row
is
one
option;
hasRow
is
another.
given
table
.
Each
row
The
steps
in
the
tabular
data
is
processed
sequentially.
algorithm
defined
here
apply
to
minimal
mode.
Each
object
in
Insert
an
empty
array
A
into
the
output
graph
JSON
output.
The
objects
corresponding
to
a
row
containing
the
name-value
pairs
associated
with
the
cell
values
will
be
subsequently
inserted
into
this
array
.
Each
table
is
processed
sequentially
in
the
tabular
data
SHALL
contain
one
name/value
pair
for
order
they
are
referenced
in
the
group
of
tables
.
For
each
column
table
where
the
cell
value
suppress
output
annotation
is
not
null
(e.g.
where
the
cell
does
not
contain
an
empty
string;
:
""
).
false
The
value
of
name
SHALL
be
_col=
[N]
where
[N]
Each
row
within
the
table
is
processed
sequentially
in
order.
For
each
row
in
the
column
number
current
table
:
Generate
a
sequence
of
objects
,
whilst
the
value
S
1
to
S
n
,
each
of
value
SHALL
be
provided
which
corresponds
to
a
subject
described
by
the
associated
cell
value
current
row
,
as
described
in
4.3
Generating
Objects
.
What
do
The
subject(s)
described
by
each
row
are
determined
according
to
with
conversion
if
no
column
name
is
given?
Where
the
about
URL
annotation
for
each
cell
value
is
null
,
the
name/value
pair
SHALL
be
omitted
from
in
the
output
graph
current
row
.
Where
about
URL
is
undefined,
a
default
subject
for
the
row
is
used.
Given
As
described
in
4.4
Generating
Nested
Objects
,
process
the
absence
sequence
of
metadata
annotations
objects
,
S
1
to
indicate
the
type
of
data
present
in
S
n
,
to
produce
a
given
column,
all
cell
values
SHALL
new
sequence
of
root
be
treated
as
strings.
objects
,
S
R
1
to
S
R
m
,
that
MAY
include
nested
objects
.
The
following
example
provides
a
numeric
score
for
four
fictional
people.
A
row
number
is
included
for
convenience.
There
are
four
columns
and
four
rows.
Given
that
no
metadata
annotations
are
provided,
it
is
very
difficult
steps
in
the
algorithm
defined
here
apply
to
ascertain
standard
mode.
Insert
an
empty
object
G
into
the
subject
of
JSON
output
which
is
associated
with
the
tabular
data
without
additional
insight.
group
of
tables
.
If
the
group
of
tables
has
an
identifier
I
G
4
John
Doe
80
;
insert
the
following
name-value
pair
into
object
G
:
http://example.org/people-and-points.csv
@id
Insert
any
notes
and
non-core
annotations
specified
for
the
group
of
tables
into
object
G
according
to
the
rules
provided
in
4.
5.
Mapping
Annotated
Tabular
Data
JSON-LD
to
JSON
.
The
procedures
and
rules
for
mapping
annotated
tabular
data
compliant
with
Insert
the
annotated
tabular
data
model
following
name-value
pair
into
object
are
described
below.
G
:
table
The
metadata
for
where
A
T
is
an
array
into
which
the
objects
describing
the
annotated
tabular
data
MAY
tables
will
be
provided
by
either
or
both
subsequently
inserted.
Each table is processed sequentially in the order they are referenced in the group of tables .
For
each
table
where
the
following
sources:
suppress
output
annotation
is
false
:
Insert
an
empty
object
T
into
the
header
line
array
within
A
T
to
represent
the
CSV
file;
and/or
table
.
If
the
table
description
,
schema
and
column
descriptions
has
an
identifier
(as
defined
in
[
I
T
tabular-metadata
;
insert
the
following
name-value
pair
into
object
T
:
@id
Mapping
applications
SHALL
establish
a
column
description
object
Specify
the
source
tabular
data
file
URL
for
each
column
the
current
table
based
on
the
url
within
annotation;
insert
the
annotated
tabular
data.
The
column
description
following
name-value
pair
into
object
contains
the
aggregated
set
of
metadata
properties
T
:
url
Insert
any
notes
and
non-core
annotations
specified
for
a
given
column
that
affect
how
the
cell
values
table
within
into
object
T
according
to
the
associated
column
are
expressed
rules
provided
in
the
output
graph
5.
JSON-LD
to
JSON
.
Metadata
properties
are
sourced
from
the
header
line
All
other
core
annotations
in
for
the
CSV
file
and
column
description
table
in
are
ignored
during
the
metadata
document
conversion;
including
information
about
table
schemas
and
enriched
with
inherited
properties
columns
from
specified
therein,
foreign
keys
,
direction
,
transformations
etc.
Insert
the
table
description
following
name-value
pair
into
object
and
schema
.
T
:
row
The
output
graph
where
A
R
is
an
array
MAY
include
some
Direct
Annotations
into
which
the
objects
sourced
from
describing
the
metadata
document.
Where
these
are
natural
language
properties
,
no
locale
information
can
rows
will
be
provided
given
subsequently
inserted.
Each
row
within
the
lack
of
multi-lingual
support
table
is
processed
sequentially
in
JSON.
Where
order.
For
each
row
in
the
current
table
:
Insert
an
empty
object
R
into
the
array
of
values
A
R
to
represent
the
row
.
Specify
the
row
number
n
for
a
property
are
provided
the
row
;
insert
the
following
name-value
pair
into
object
R
:
rownum
Specify
the
row
source
number
n
source
for
the
row
within
the
source
tabular
data
file
URL
using
a
language
map
(as
defined
fragment-identifier
as
specified
in
[
json-ld
RFC7111
])
the
array
of
locale-specific
values
SHALL
be
included
in
the
output
graph
];
if
row
source
number
-
albeit
without
is
not
null
,
insert
the
inferred
semantics
about
language
codes.
following
name-value
pair
into
object
R
:
url
#row=
n
source
Clearly,
in
order
Insert
any
non-core
annotations
specified
for
the
row
into
object
R
according
to
process
annotated
tabular
data,
a
mapping
application
MUST
have
access
the
rules
provided
in
5.
JSON-LD
to
JSON
.
Insert
the
full
metadata
description
following
name-value
pair
into
object
R
:
describes
where
A
is
an
array
.
The
objects
containing
the
name-value
pairs
associated
with
the
tabular
data.
cell
values
will
be
subsequently
inserted
into
this
array
.
URL
expansion
behaviour
Generate
a
sequence
of
relative
URLs
SHALL
be
consistent
with
Section
6.3
IRI
Expansion
objects
,
S
1
to
S
n
,
each
of
which
corresponds
to
a
subject
described
by
the
current
row
,
as
described
in
[
json-ld-api
4.3
Generating
Objects
].
.
The
base
URL
provides
subject(s)
described
by
each
row
are
determined
according
to
the
about
URL
against
which
relative
URLs
from
annotated
tabular
data
are
resolved.
The
base
annotation
for
each
cell
in
the
current
row
.
Where
about
URL
SHALL
be
that
of
is
undefined,
a
default
subject
for
the
source
CSV
file.
row
is
used.
As described in 4.4 Generating Nested Objects , process the sequence of objects , S 1 to S n , to produce a new sequence of root objects , S R 1 to S R m , that MAY include nested objects .
The steps in the algorithm defined here apply to both standard and minimal modes.
This
algorithm
generates
a
sequence
of
objects
,
S
1
to
S
n
4.1.1
Table-level
processing
,
each
of
which
corresponds
to
a
subject
described
by
the
current
row
.
The
algorithm
inserts
name-value
pairs
into
S
i
depending
on
the
cell
values
as
outlined
in
the
following
steps.
Determine
the
unique
subjects
for
the
current
row
.
The
root
object
of
subject(s)
described
by
each
row
are
determined
according
to
the
output
graph
about
URL
SHALL
describe
annotation
for
each
cell
in
the
annotated
table
current
row
.
A
default
subject
for
the
row
is
used
for
any
cells
where
about
URL
is
undefined.
Where
provided
in
For
each
subject
that
the
table
description
,
current
row
describes
where
at
least
one
of
the
metadata
property
cells
that
refers
to
that
subject
has
a
value
or
value
URL
that
is
not
,
and
is
associated
with
a
column
where
suppress
output
annotation
is
@id
SHALL
be
used
null
false
:
Create
an
empty
object
S
i
to
identify
represent
the
root
object.
subject
i
.
The
root
object
SHALL
be
identified
using
(
i
is
the
name/value
pair
"url":
"
[@id]
"
index
number
with
values
from
1
to
n
,
where
n
is
the
number
of
subjects
for
the
row
)
Subject
i
is
identified
according
to
the
about
URL
annotation
of
its
associated
cells
:
I
S
.
For
a
[@id]
default
subject
where
about
URL
is
not
specified
by
its
cells
,
I
S
is
the
value
of
metadata
property
.
@id
null
The
root
If
the
identifier
for
subject
i
,
I
S
,
is
not
null
,
then
insert
the
following
name-value
pair
into
object
SHALL
contain
a
reference
S
i
:
@id
Each
cell
referring
to
subject
i
is
then
processed
sequentially
according
to
the
CSV-encoded
distribution
order
of
the
tabular
data.
columns
.
The
distribution
SHALL
be
described
using
an
object
For
each
cell
referring
to
subject
i
,
where
the
suppress
output
annotation
for
the
column
associated
with
name
distribution
that
contains
the
name/value
pair
"downloadURL":
"
[CSV-LOCATION]
"
where
cell
is
false
,
insert
a
name-value
pair
into
object
S
i
[CSV-LOCATION]
is
as
described
below:
If
the
absolute
value
of
property
URL
for
the
cell
is
not
null
,
then
name
N
takes
the
value
of
property
URL
compacted
according
to
the
source
CSV
file.
rules
as
defined
in
URL
Compaction
Note
in
[
tabular-metadata
The
semantics
].
Else,
name
N
takes
the
value
of
properties
distribution
and
downloadURL
correspond
the
name
annotation
for
the
column
associated
with
the
properties
cell
.
If
the
value
URL
for
the
current
cell
is
not
,
then
insert
the
following
name-value
pair
into
object
S
i
dcat:distribution
null
and
:
where
V
url
is
the
value
of
value
URL
annotation
for
the
current
cell
expressed
as
a
string
in
the
JSON
output.
If
N
is
@type
,
compact
V
url
according
to
the
rules
as
defined
in
URL
Compaction
in
[
vocab-dcat
tabular-metadata
].
Else, if the cell value is a list that is not empty, then the cell value provides a sequence of values for inclusion within the JSON output; insert an array A v containing each value V of the sequence into object S i :
Each of the values V derived from the sequence MUST be expressed in the JSON output according to the datatype of V as defined below in section 4.5 Interpreting datatypes .
Where
a
header
line
Else,
if
the
cell
value
is
present
in
the
CSV
file
then,
for
each
column
,
not
null
,
then
the
cell
value
provides
a
single
value
V
for
inclusion
within
the
JSON
output;
insert
the
following
name-value
pair
into
object
S
i
:
Value
V
derived
from
the
column
header
SHALL
cell
values
MUST
be
assigned
expressed
in
the
JSON
output
according
to
metadata
property
name
within
the
column
description
object
datatype
for
that
column
of
the
value
as
defined
in
section
4.5
Interpreting
datatypes
.
Where
the
column
header
is
null
,
If
name
N
occurs
more
than
once
within
object
S
i
,
the
value
assigned
to
name-value
pairs
from
each
occurrence
of
name
SHALL
N
MUST
be
_col=
[N]
compacted
to
form
a
single
name-value
pair
with
name
N
and
whose
value
is
an
array
containing
all
values
from
each
of
those
name-value
pairs.
The
steps
in
the
column
number
.
algorithm
defined
herein
apply
to
both
standard
and
minimal
modes.
Where
present
in
the
table
description
current
row
describes
multiple
subjects
,
the
following
metadata
properties
SHALL
it
MAY
be
included
in
possible
to
organise
the
output
graph
objects
associated
with
those
subjects
such
that
some
objects
are
nested
within
others;
e.g.
where
the
root
object:
notes
-
value
URL
annotation
for
one
cell
matches
the
array
about
URL
annotation
for
another
cell
in
the
same
row
.
This
algorithm
considers
a
sequence
of
objects
representing
structured
annotations
on
generated
according
to
4.3
Generating
Objects
,
S
1
to
S
n
,
each
of
which
corresponds
to
a
subject
described
by
the
tabular
data
SHALL
current
row
.
It
generates
a
new
sequence
of
root
objects
,
S
R
1
to
S
R
m
,
that
MAY
be
included
verbatim.
include
nested
objects
.
The
Web
Annotation
Working
Group
Where
the
current
row
is
developing
describes
only
a
vocabulary
for
expressing
annotations
which
we
anticipate
referencing
from
single
subject
,
this
specification.
Issues
likely
to
algorithm
may
be
covered
therein
include:
how
to
anchor
the
annotation
to
bypassed
as
no
nesting
is
possible.
In
such
a
target
in
the
tabular
data
and/or
CSV
file,
what
form
case,
the
annotations
themselves
may
take
(e.g.
a
simple
literal
annotation
body,
or
whether
additional
formatting
properties
are
required
root
object
S
R
1
is
identical
to
indicate
that
the
annotation
is
expressed
in,
say,
Markdown
or
HTML).
original
object
S
1
.
This
nesting
algorithm
is
still
unclear
-
especially
based
on
the
interrelationships
between
subjects
described
within
a
given
row
that
are
specified
using
the
confusion
on
identifying
value
URL
annotation.
Cell
values
expressing
the
identity
of
a
subject
in
the
current
row
numbers
(
ISSUE
#68
refers).
(i.e.,
as
a
simple
literal)
will
be
ignored
by
this
algorithm.
Any
Common
Properties
The
algorithm
uses
the
following
terms:
The nesting algorithm is defined as follows:
Each
column
description
SHALL
be
matched
to
a
column
For
all
cells
in
the
tabular
data
based
on
current
row
,
determine
the
order
value
URLs
,
V
url
,
that
the
description
occur
only
once
.
The
list
of
these
uniquely
occurring
value
URLs
is
listed
referred
to
as
the
URL-list
.
Create
an
empty
forest
F
.
Vertices
in
the
columns
array
trees
of
this
forest
represent
the
schema
subjects
described
by
the
current
row
.
For
each
column
description
object
S
i
in
the
metadata
document,
the
following
metadata
properties
SHALL
be
added
sequence
S
1
to
S
n
:
Determine
the
relevant
column
description
identity
of
object
established
by
the
mapping
application:
S
i
:
I
S
.
If
present
in
object
S
i
,
the
name-value
pair
with
name
.
Where
metadata
property
name
@id
is
also
provided
via
the
header
line
provides
the
value
from
the
column
description
of
I
S
.
Else,
object
in
the
metadata
document
SHALL
take
precedence.
S
i
is
not
explicitly
identified
and
I
S
is
.
predicateUrl
null
Check
whether
there
is
a
vertex
N
in
forest
F
that
represents
object
S
i
urlTemplate
.
.
If
none
of
the
existing
vertices
in
forest
F
represent
object
S
i
,
then
insert
a
new
tree
into
forest
F
whose
root
is
a
vertex
N
that
represents
object
S
i
and
has
identity
I
S
.
For
all
cells
associated
with
the
current
object
S
i
Inherited
properties
(e.g.
whose
about
URL
null
,
separator
,
format
,
datatype
,
annotation
matches
I
S
):
If
the
value
URL
annotation
of
the
current
cell
is
defined
and
default
are
added
to
its
value,
V
url
,
appears
in
the
column
description
object
,
overwriting
values
added
URL-list
,
then
check
each
of
the
other
objects
in
the
previous
step
where
properties
are
duplicated.
sequence
S
1
to
S
n
to
determine
if
V
url
identifies
one
of
those
objects
.
For
each
column
description
object
where
metadata
property
S
j
,
if
the
name-value
pair
with
name
predicateUrl
@id
has
not
been
assigned
within
is
present
and
its
value
matches
V
url
,
then:
If
the
column
description
,
root
of
the
value
tree
containing
vertex
N
is
a
vertex
that
represents
object
S
j
,
then
object
S
i
is
already
a
descendant
of
predicateUrl
SHALL
object
S
j
;
no
further
action
should
be
set
as
taken
for
this
instance
of
V
url
.
This clause in the algorithm prevents circular loops being created.
Furthermore,
because
the
URL-list
contains
value
URLs
that
occur
only
once
for
the
current
row
,
object
S
i
cannot
be
a
descendant
of
metadata
property
name
.
an
intermediate
vertices
in
the
tree
.
The
Else,
if
there
is
a
root
vertex
M
in
forest
F
that
represents
object
SHALL
contain
an
array
named
row
containing
one
object
for
each
S
j
,
then
set
vertex
M
as
a
child
of
vertex
N
and
remove
vertex
M
from
the
rows
list
of
roots
within
in
forest
F
(i.e.,
the
tabular
data.
tree
rooted
by
M
becomes
a
sub-tree
of
N
).
Refer
to
Section
4.1.2
Row-level
processing
Else,
create
a
new
vertex
for
further
details.
M
that
represents
object
S
j
as
a
child
of
vertex
N
.
The
output
graph
Each
vertex
MAY
contain
information
about
in
forest
F
represents
an
object
in
the
metadata
documents
original
sequence
of
objects
S
1
to
S
n
and
is
associated
with
a
subject
described
by
the
current
row
.
Rearrange
objects
S
1
to
S
n
such
that
were
used
when
when
creating
they
mirror
the
output
graph
structure
of
the
trees
using
in
forest
F
as
follows:
If
vertex
M
,
representing
object
S
i
,
is
a
child
of
vertex
N
,
representing
object
S
j
,
then
the
following
name/value
name-value
pair
in
object
S
j
associated
with
the
edge
relating
M
and
N
MUST
for
each
metadata
document:
be
modifed
such
that
the
(literal)
value,
V
url
"describedBy":
"
,
from
that
name-value
pair
is
replaced
by
object
S
i
thus
creating
a
[Metadata
Location]
nested
"
object
.
Return
the
absolute
URL
sequence
of
the
metadata
document.
root
objects
,
S
R
1
to
S
R
m
.
An implementation may be able to optimize the algorithm by skipping branches (e.g. if URL-list is empty) or by other means.
Each
row
Cell
values
are
expressed
in
the
tabular
data
is
processed
sequentially.
The
behaviour
exhibited
when
processing
a
given
cell
within
JSON
output
according
to
the
current
row
is
dependent
on
cell
value's
datatype
.
The
relationship
between
the
metadata
properties
value
of
the
column
description
object
cell
value's
datatype
for
and
the
column
that
that
cell
primitive
types
supported
by
JSON
(as
specified
in
[
RFC7159
resides
in.
The
effect
of
each
metadata
property
])
is
provided
in
the
table
below.
Instances
of
JSON
reserved
characters
within
string
values
MUST
be
escaped
as
defined
in
Section
4.1.3
Metadata
property
effects
on
row-level
mapping
behaviour
[
RFC7159
].
Each
object
in
JSON
has
no
native
support
for
expressing
language
information;
therefore
the
output
graph
language
corresponding
to
of
a
row
value
has
no
effect
on
the
JSON
output.
A
datatype's
format
is
irrelevant
to
the
conversion
procedure
defined
in
this
specification;
the
tabular
data
SHALL
contain
one
name/value
pair
for
each
column
cell
value
where
has
already
been
parsed
from
the
contents
the
cell
value
is
not
null
.
according
to
the
format
annotation.
Where
the
metadata
property
urlTemplate
is
provided
in
the
schema
,
each
object
in
contents
of
the
output
graph
cell
corresponding
to
a
row
cannot
be
parsed,
or
other
validation
errors
occur,
cell
errors
in
the
tabular
data
SHALL
will
be
explicitly
identified
using
provided.
It
is
an
implementation
decision
to
determine
how
conversion
applications
should
proceed
in
the
name/value
pair
event
that
cell
errors
are
encountered.
|
JSON primitive type |
---|---|
anyAtomicType
|
string |
anyURI
|
string |
base64Binary
| string |
boolean
| boolean |
date
| string |
dateTime
| string |
dateTimeStamp
| string |
decimal
| number |
integer
| number |
long
| number |
int
| number |
short
| number |
byte
| number |
nonNegativeInteger
| number |
positiveInteger
| number |
unsignedLong
| number |
unsignedInt
| number |
unsignedShort
| number |
unsignedByte
| number |
nonPositiveInteger
| number |
negativeInteger
| number |
double
| number |
duration
| string |
dayTimeDuration
| string |
yearMonthDuration
| string |
float
| number |
gDay
| string |
gMonth
| string |
gMonthDay
| string |
gYear
| string |
gYearMonth
| string |
hexBinary
| string |
QName
| string |
string
| string |
normalizedString
| string |
token
| string |
language
| string |
Name
| string |
NMTOKEN
| string |
xml
| string |
html
| string |
json
| string |
time
| string |
This
section
defines
a
mechanism
for
transforming
the
value
resulting
[
json-ld
]
dialect
used
for
non-core
annotations
and
notes
originating
from
the
expansion
processing
of
the
metadata
(as
defined
in
[
uri-template
tabular-metadata
]
specified
in
the
urlTemplate
property.
])
into
JSON.
Conversion
applications
may
have
other
means
to
create
annotated
tables
,
e.g.,
through
some
application
specific
API-s.
In
such
cases
the
name
property
specified
exact
format
for
each
column
.
During
template
expansion,
non-core
annotations
or
notes
may
be
different.
Specifications
for
such
annotation
processes
should
specify
how
these
annotations
should
be
converted
into
RDF.
Name-value
pairs
from
notes
and
non-core
annotations
annotations
are
generally
copied
verbatim
from
the
variables
evaluate
metadata
description
subject
to
the
cell
exceptions
below:
Name-value
pairs
whose
value
is
an
object
within
using
the
row
[
json-ld
being
processed
that
is
associated
with
the
named
column
.
]
keyword
@value
,
for
example:
_row
{
"@value":
"
"
}
are transformed to:
Once
the
URL
has
been
generated
via
Name-value
pairs
occurring
within
the
template
expansion,
relative
URLs
value
object
that
use
[
json-ld
]
keywords
@language
and
@type
are
resolved
against
ignored.
Name-value
pairs
whose
value
is
an
object
using
the
base
URL
[
json-ld
]
keyword
@id
to
create
coerce
a
string-value
to
be
interpreted
as
an
absolute
URL.
IRI,
for
example:
{
"@id":
"
V
url
"
}
are transformed to:
Where
In
addition
to
compacting
values
of
property
URLs
,
URLs
which
ware
the
cell
value
is
null
,
of
@type
used
within
the
name/value
pair
SHALL
be
omitted
from
notes
and
non-core
annotations
are
compacted
according
to
the
output
graph
rules
as
defined
in
URL
Compaction
unless
a
in
[
tabular-metadata
].
default
value
This
section
is
non-normative.
Each
of
the
examples
expresses
more
complex
conversions
-
it
is
specified
for
recommended
that
column
readers
of
this
specification
work
through
the
examples
in
sequential
order.
This
example
comprises
a
single
annotated
table
(see
metadata
properties
null
containing
information
attributes
about
countries;
country
code,
position
(latitude,
longitude)
and
name.
Whilst
the
input
tabular
data
file,
published
at
,
includes
a
header
line
,
no
further
metadata
annotations
are
given.
The
tabular
data
file
is
provided
below:
default
).
http://example.org/countries.csv
countryCode,latitude,longitude,name AD,42.546245,1.601554,Andorra AE,23.424076,53.847818,"United Arab Emirates" AF,33.93911,67.709953,Afghanistan
The
value
of
name
annotated
table
generated
from
parsing
the
tabular
data
file
is
shown
below
and
provides
the
basis
for
the
name/value
pair
SHALL
be
provided
by
conversion
to
JSON.
Annotations for the resulting table T , with 4 columns and 3 rows, are shown below:
id | core annotations | ||||
---|---|---|---|---|---|
url | columns | rows | |||
T |
|
C1 , C2 , C3 , C4 | R1 , R2 , R3 |
Annotations
for
the
column
description
object
.
columns
,
rows
and
cells
in
table
T
are
shown
in
the
tables
below.
In
accordance
with
[
json
Column
],
all
unicode
characters
may
be
used.
However,
the
following
characters
SHALL
be
escaped
:
annotations:
id | core annotations | |||||
---|---|---|---|---|---|---|
table | number | source number | cells | name | titles | |
C1 | T | 1 | 1 | C1.1 , C2.1 , C3.1 |
|
|
C2 | T | 2 | 2 | C1.2 , C2.2 , C3.2 |
|
|
C3 | T | 3 | 3 | C1.3 , C2.3 , C3.3 |
|
|
C4 | T | 4 | 4 | C1.4 , C2.4 , C3.4 |
name
|
name
|
The
value
of
Row
annotations:
id | core annotations | |||
---|---|---|---|---|
table | number | source number | cells | |
R1 | T | 1 | 2 | C1.1 , C1.2 , C1.3 , C1.4 |
R2 | T | 2 | 3 | C2.1 , C2.2 , C2.3 , C2.4 |
R3 | T | 3 | 4 | C3.1 , C3.2 , C3.3 , C3.4 |
Cell annotations:
id | core annotations | |||||
---|---|---|---|---|---|---|
table | column | row |
string
value
|
value | property URL | |
C1.1 | T | C1 | R1 |
"AD"
|
"AD"
|
null
|
C1.2 | T | C2 | R1 |
"42.546245"
|
"42.546245"
|
null
|
C1.3 | T | C3 | R1 |
"1.601554"
|
"1.601554"
|
null
|
C1.4 | T | C4 | R1 |
"Andorra"
|
"Andorra"
|
null
|
C2.1 | T | C1 | R2 |
"AE"
|
"AE"
|
null
|
C2.2 | T | C2 | R2 |
"23.424076"
|
"23.424076"
|
null
|
C2.3 | T | C3 | R2 |
"53.847818"
|
"53.847818"
|
null
|
C2.4 | T | C4 | R2 |
"United
Arab
Emirates"
|
"United
Arab
Emirates"
|
null
|
C3.1 | T | C1 | R3 |
"AF"
|
"AF"
|
null
|
C3.2 | T | C2 | R3 |
"33.93911"
|
"33.93911"
|
null
|
C3.3 | T | C3 | R3 |
"67.709953"
|
"67.709953"
|
null
|
C3.4 | T | C4 | R3 |
"Afghanistan"
|
"Afghanistan"
|
null
|
Minimal
mode
subject
to
the
effect
of
the
metadata
properties
output
for
that
column
(if
any
are
specified).
this
example
is
provided
below:
[{ "countryCode": "AD", "latitude": "42.546245", "longitude": "1.601554", "name": "Andorra" }, { "countryCode": "AE", "latitude": "23.424076", "longitude": "53.847818", "name": "United Arab Emirates" }, { "countryCode": "AF", "latitude": "33.93911", "longitude": "67.709953", "name": "Afghanistan" }]
Given
the
lack
of
multi-lingual
support
The
about
URL
annotation
has
not
been
set
for
cells
in
JSON,
internationalized
strings
table
T
(
{
"url":
"http://example.org/countries.csv"}
);
cells
in
a
given
row
where
about
URL
has
not
been
specified
are
simply
copied
verbatim
into
assumed
to
refer
to
the
output
graph
same
subject
without
any
additional
locale
information.
Also
note
that
and
so
the
name-value
pairs
associated
with
the
cell
values
of
metadata
property
name
must
be
unique
that
row
occur
within
a
table
.
Therefore
if,
say,
English
and
French
versions
of
the
same
object
.
Given
that
the
property
are
provided
as
complementary
columns
URL
is
null
for
cells
in
a
CSV
file
then
their
table
T
(
name
{
"url":
"http://example.org/countries.csv"}
properties
must
be
different;
),
the
simplified
name
is
used
in
the
name-value
pairs;
e.g.
title_en
countryCode
and
rather
than
titre_fr
.
It
may
be
possible
http://example.org/countries.csv#countryCode
Standard
mode
output
for
applications
to
infer
a
language
from
this
example
is
provided
below:
{ "table": [{ "url": "http://example.org/countries.csv", "row": [{ "url": "http://example.org/countries.csv#row=2", "rownum": 1, "describes": [{ "countryCode": "AD", "latitude": "42.546245", "longitude": "1.601554", "name": "Andorra" }] }, { "url": "http://example.org/countries.csv#row=3", "rownum": 2, "describes": [{ "countryCode": "AE", "latitude": "23.424076", "longitude": "53.847818", "name": "United Arab Emirates" }] }, { "url": "http://example.org/countries.csv#row=4", "rownum": 3, "describes": [{ "countryCode": "AF", "latitude": "33.93911", "longitude": "67.709953", "name": "Afghanistan" }] }] }] }
Even
though
the
name
of
table
was
defined
in
isolation,
the
annotated
table
is
wrapped
in
a
column
group
of
tables
.
The
name-value
pair
with
name
url
provides
reference
to
the
original
tabular
data
file
and
to
specific
rows
therein.
The
row
number
-
but
this
is
entirely
dependant
on
provided
for
each
row
using
name-value
pair
with
name
rownum
.
The
object
containing
the
syntax
used
by
name-values
pairs
associated
with
the
metadata
author
when
defining
cell
values
of
a
row
are
related
to
the
object
for
that
row
using
the
name-value
pair
with
name
property.
describes
.
This
example
is
based
on
row-level
mapping
behaviour
Use
Case
#11
-
City
of
Palo
Alto
Tree
Data
and
comprises
a
single
annotated
table
describing
an
inventory
of
tree
maintenance
operations.
The
input
tabular
data
file,
published
at
http://example.org/tree-ops-ext.csv
,
and
the
associated
metadata
description
http://example.org/tree-ops-ext.csv-metadata.json
are
provided
below:
GID,On Street,Species,Trim Cycle,Diameter at Breast Ht,Inventory Date,Comments,Protected,KML 1,ADDISON AV,Celtis australis,Large Tree Routine Prune,11,10/18/2010,,,"<Point><coordinates>-122.156485,37.440963</coordinates></Point>" 2,EMERSON ST,Liquidambar styraciflua,Large Tree Routine Prune,11,6/2/2010,,,"<Point><coordinates>-122.156749,37.440958</coordinates></Point>" 6,ADDISON AV,Robinia pseudoacacia,Large Tree Routine Prune,29,6/1/2010,cavity or decay; trunk decay; codominant leaders; included bark; large leader or limb decay; previous failure root damage; root decay; beware of BEES,YES,"<Point><coordinates>-122.156299,37.441151</coordinates></Point>"
{ "@context": ["http://www.w3.org/ns/csvw", {"@language": "en"}], "@id": "http://example.org/tree-ops-ext", "url": "tree-ops-ext.csv", "dc:title": "Tree Operations", "dcat:keyword": ["tree", "street", "maintenance"], "dc:publisher": [{ "schema:name": "Example Municipality", "schema:url": {"@id": "http://example.org"} }], "dc:license": {"@id": "http://opendefinition.org/licenses/cc-by/"}, "dc:modified": {"@value": "2010-12-31", "@type": "xsd:date"}, "notes": [{ "@type": "oa:Annotation", "oa:hasTarget": {"@id": "http://example.org/tree-ops-ext"}, "oa:hasBody": { "@type": "oa:EmbeddedContent", "rdf:value": "This is a very interesting comment about the table; it's a table!", "dc:format": {"@value": "text/plain"} } }], "dialect": {"trim": true}, "tableSchema": { "columns": [{ "name": "GID", "titles": [ "GID", "Generic Identifier" ], "dc:description": "An identifier for the operation on a tree.", "datatype": "string", "required": true, "suppressOutput": true }, { "name": "on_street", "titles": "On Street", "dc:description": "The street that the tree is on.", "datatype": "string" }, { "name": "species", "titles": "Species", "dc:description": "The species of the tree.", "datatype": "string" }, { "name": "trim_cycle", "titles": "Trim Cycle", "dc:description": "The operation performed on the tree.", "datatype": "string", "lang": "en" }, { "name": "dbh", "titles": "Diameter at Breast Ht", "dc:description": "Diameter at Breast Height (DBH) of the tree (in feet), measured 4.5ft above ground.", "datatype": "integer" }, { "name": "inventory_date", "titles": "Inventory Date", "dc:description": "The date of the operation that was performed.", "datatype": {"base": "date", "format": "M/d/yyyy"} }, { "name": "comments", "titles": "Comments", "dc:description": "Supplementary comments relating to the operation or tree.", "datatype": "string", "separator": ";" }, { "name": "protected", "titles": "Protected", "dc:description": "Indication (YES / NO) whether the tree is subject to a protection order.", "datatype": {"base": "boolean", "format": "YES|NO"}, "default": "NO" }, { "name": "kml", "titles": "KML", "dc:description": "KML-encoded description of tree location.", "datatype": "xml" }], "primaryKey": "GID", "aboutUrl": "http://example.org/tree-ops-ext#gid-{GID}" } }
The notes annotation in the metadata description uses the Open Annotation data model currently under development within the Web Annotations Working Group . This is purely illustrative; no constraints are placed on the value of the notes annotation.
The
following
annotated
table
generated
from
parsing
the
tabular
data
file
and
associated
metadata
properties
modify
is
shown
below
and
provides
the
way
that
cell
values
basis
for
the
conversion
to
JSON.
Core
annotations
for
the
resulting
table
T
,
with
9
columns
and
3
rows
,
are
incorporated
into
shown
below:
id | core annotations | ||||
---|---|---|---|---|---|
id | url | columns | rows | notes | |
T | <http://example.org/tree-ops-ext> |
http://example.org/tree-ops-ext.csv
| C1 , C2 , C3 , C4 , C5 , C6 , C7 , C8 , C9 | R1 , R2 , R3 |
[{
"@type":
"oa:Annotation",
...
}]
|
Non-core
annotations
for
the
output
graph
:
table
T
are:
null
dc:title
null
"Tree
Operations"
separator
dcat:keyword
separator
["tree",
"street",
"maintenance"]
separator
dc:publisher
[{
"schema:name":
"Example
Municipality",
"schema:url":
{
"@id":
"http://example.org"
}
}]
datatype
dc:license
format
{
"@id":
"http://opendefinition.org/licenses/cc-by/"
}
dc:modified
datatype
"2010-12-31"
The
value
of
the
column
notes
SHALL
be
inferred
to
hold
values
of
datatype
string
.
annotation
has
been
shortened
for
clarity
in
the
table
above.
The
following
datatypes
Annotations
for
the
columns
,
rows
and
cells
in
table
T
are
given
special
attention:
shown
in
the
tables
below.
Datatypes
with
embedded
syntax:
Column
annotations:
id | core annotations | annotations | |||||||
---|---|---|---|---|---|---|---|---|---|
table | number | source number | cells | name | titles | required | suppress output |
| |
C1 | T | 1 | 1 | C1.1 , C2.1 , C3.1 |
|
,
Generic
Identifier
|
|
|
An
identifier
for
the
operation
on
a
|
C2 | T | 2 | 2 | C1.2 , C2.2 , C3.2 |
|
On
Street
|
The
street
that
the
| ||
C3 | T | 3 | 3 | C1.3 , C2.3 , C3.3 |
|
|
The
species
of
the
tree.
| ||
C4 | T | 4 | 4 | C1.4 , C2.4 , C3.4 |
|
Trim
Cycle
|
The
operation
performed
on
the
| ||
C5 | T | 5 | 5 | C1.5 , C2.5 , C3.5 |
dbh
|
Diameter
at
Breast
Ht
|
Diameter
at
Breast
Height
(DBH)
of
| ||
C6 | T | 6 | 6 | C1.6 , C2.6 , C3.6 |
|
Inventory
Date
|
The
date
of
the
| ||
C7 | T | 7 | 7 | C1.7 , C2.7 , C3.7 |
|
|
Supplementary
comments
relating
to
the
operation
or
tree.
| ||
C8 | T | 8 | 8 | C1.8 , C2.8 , C3.8 |
|
Protected
|
Indication
(YES
/
NO)
whether
the
| ||
C9 | T | 9 | 9 | C1.9 , C2.9 , C3.9 |
kml
|
KML
|
KML-encoded
description
of
|
In
this
example,
output
graph
for
column
SHALL
include
the
value
C1
(
false
GID
;
else
)
is
not
required;
note
the
suppress
output
graph
SHALL
include
the
cell
value
annotation
on
this
column
.
Row
verbatim.
annotations:
id | core annotations | ||||
---|---|---|---|---|---|
table | number | source number | cells | primary key | |
R1 | T | 1 | 2 | C1.1 , C1.2 , C1.3 , C1.4 , C1.5 , C1.6 , C1.7 , C1.8 , C1.9 | C1.1 |
R2 | T | 2 | 3 | C2.1 , C2.2 , C2.3 , C2.4 , C2.5 , C2.6 , C2.7 , C2.8 , C2.9 | C2.1 |
R3 | T | 3 | 4 | C3.1 , C3.2 , C3.3 , C3.4 , C3.5 , C3.6 , C3.7 , C3.8 , C3.9 | C3.1 |
Numbers:
Cell
annotations:
id | core annotations | |||||
---|---|---|---|---|---|---|
table | column | row | string value | value | about URL | |
C1.1 | T | C1 | R1 |
|
|
|
C1.2 | T | C2 | R1 |
|
|
|
C1.3 | T | C3 | R1 |
|
"Celtis
australis"
|
<http://example.org/tree-ops-ext#gid-1>
|
C1.4 | T | C4 | R1 |
"Large
Tree
Routine
Prune"
|
"Large
Tree
Routine
Prune"
(English)
|
<http://example.org/tree-ops-ext#gid-1>
|
C1.5 | T | C5 | R1 |
"11"
|
11
|
<http://example.org/tree-ops-ext#gid-1>
|
C1.6 | T | C6 | R1 |
"10/18/2010"
|
2010-10-18
|
<http://example.org/tree-ops-ext#gid-1>
|
C1.7 | T | C7 | R1 |
""
|
null
|
<http://example.org/tree-ops-ext#gid-1>
|
C1.8 | T | C8 | R1 |
""
|
false
|
<http://example.org/tree-ops-ext#gid-1>
|
C1.9 | T | C9 | R1 |
"<Point><coordinates>-122.156485,37.440963</coordinates></Point>"
|
"<Point><coordinates>-122.156485,37.440963</coordinates></Point>"
(XML)
|
<http://example.org/tree-ops-ext#gid-1>
|
C2.1 | T | C1 | R2 |
"2"
|
"2"
|
<http://example.org/tree-ops-ext#gid-2>
|
C2.2 | T | C2 | R2 |
"EMERSON
ST"
|
"EMERSON
ST"
|
<http://example.org/tree-ops-ext#gid-2>
|
C2.3 | T | C3 | R2 |
"Liquidambar
styraciflua"
|
"Liquidambar
styraciflua"
|
<http://example.org/tree-ops-ext#gid-2>
|
C2.4 | T | C4 | R2 |
"Large
Tree
Routine
Prune"
|
"Large
Tree
Routine
Prune"
(English)
|
<http://example.org/tree-ops-ext#gid-2>
|
C2.5 | T | C5 | R2 |
"11"
|
11
|
<http://example.org/tree-ops-ext#gid-2>
|
C2.6 | T | C6 | R2 |
"6/2/2010"
|
2010-06-02
|
<http://example.org/tree-ops-ext#gid-2>
|
C2.7 | T | C7 | R2 |
""
|
null
|
<http://example.org/tree-ops-ext#gid-2>
|
C2.8 | T | C8 | R2 |
""
|
false
|
<http://example.org/tree-ops-ext#gid-2>
|
C2.9 | T | C9 | R2 |
"<Point><coordinates>-122.156749,37.440958</coordinates></Point>"
|
"<Point><coordinates>-122.156749,37.440958</coordinates></Point>"
(XML)
|
<http://example.org/tree-ops-ext#gid-2>
|
C3.1 | T | C1 | R3 |
"6"
|
"6"
|
<http://example.org/tree-ops-ext#gid-6>
|
C3.2 | T | C2 | R3 |
"ADDISON
AV"
|
"ADDISON
AV"
|
<http://example.org/tree-ops-ext#gid-6>
|
C3.3 | T | C3 | R3 |
"Robinia
pseudoacacia"
|
"Robinia
pseudoacacia"
|
<http://example.org/tree-ops-ext#gid-6>
|
C3.4 | T | C4 | R3 |
"Large
Tree
Routine
Prune"
|
"Large
Tree
Routine
Prune"
(English)
|
<http://example.org/tree-ops-ext#gid-6>
|
C3.5 | T | C5 | R3 |
"29"
|
29
|
<http://example.org/tree-ops-ext#gid-6>
|
C3.6 | T | C6 | R3 |
"6/1/2010"
|
2010-06-01
|
<http://example.org/tree-ops-ext#gid-6>
|
C3.7 | T | C7 | R3 |
"cavity
or
decay;
trunk
decay;
codominant
leaders;
included
bark;
large
leader
or
limb
decay;
previous
failure
root
damage;
root
decay;
beware
of
BEES"
|
"cavity
or
decay"
,
,
,
,
,
,
,
|
|
C3.8 | T | C8 | R3 |
"YES"
|
true
|
<http://example.org/tree-ops-ext#gid-6>
|
C3.9 | T | C9 | R3 |
"<Point><coordinates>-122.156299,37.441151</coordinates></Point>"
|
"<Point><coordinates>-122.156299,37.441151</coordinates></Point>"
(XML)
|
<http://example.org/tree-ops-ext#gid-6>
|
The
lists
of
values
from
cells
that
in
column
C7
(
"name":
"comments"
)
are
asserted
assumed
to
be
numeric
shall
be
expressed
in
unordered
as
the
output
graph
boolean
ordered
as
numbers;
double
quotes
will
be
omitted.
It
is
not
uncommon
for
numbers
within
tabular
data
to
be
formatted
for
human
consumption,
annotation,
which
may
involve
using
commas
for
decimal
points,
grouping
digits
in
the
number
using
commas,
or
adding
currency
symbols
or
percent
signs
defaults
to
the
number.
Metadata
property
,
has
not
be
format
MAY
false
provided
to
describe
the
formatting
of
the
cell
values
to
assist
the
mapping
application
convert
set
within
the
cell
value
metadata
description.
Minimal
mode
to
a
number
format
readily
consumable
by
downstream
applications.
output
for
this
example
is
provided
below:
[{ "@id": "http://example.org/tree-ops-ext#gid-1", "on_street": "ADDISON AV", "species": "Celtis australis", "trim_cycle": "Large Tree Routine Prune", "dbh": 11, "inventory_date": "2010-10-18", "protected": false, "kml": "<Point><coordinates>-122.156485,37.440963</coordinates></Point>" }, { "@id": "http://example.org/tree-ops-ext#gid-2", "on_street": "EMERSON ST", "species": "Liquidambar styraciflua", "trim_cycle": "Large Tree Routine Prune", "dbh": 11, "inventory_date": "2010-06-02", "protected": false, "kml": "<Point><coordinates>-122.156749,37.440958</coordinates></Point>" }, { "@id": "http://example.org/tree-ops-ext#gid-6", "on_street": "ADDISON AV", "species": "Robinia pseudoacacia", "trim_cycle": "Large Tree Routine Prune", "dbh": 29, "inventory_date": "2010-06-01", "comments": [ "cavity or decay", "trunk decay", "codominant leaders", "included bark", "large leader or limb decay", "previous failure root damage", "root decay", "beware of BEES" ], "protected": true, "kml": "<Point><coordinates>-122.156299,37.441151</coordinates></Point>" }]
Describing
The
subject
described
by
each
row
is
explicitly
defined
using
the
formatting
about
URL
annotation;
e.g.
the
subject
of
numbers
row
R1
is
currently
unresolved
and
http://example.org/tree-ops-ext#gid-1
.
Output
for
column
C1
(
{
"name":
"GID"
}
)
is
likely
to
require
information
on
decimal
separator
characters,
grouping
characters
and
possibly
others
such
not
included
as
Infinity,
Nan,
currency
tokens,
negative
numbers
appearing
in
parentheses
etc.
column
suppress
output
annotation
is
true
.
In
the
interim,
mapping
applications
are
not
required
to
undertake
any
reformatting
Cells
C1.7
and
may
simply
pass
the
cell
value
to
C2.7
(
rows
R1
and
R2
;
column
,
{
"name":
"comments"
}
)
have
null
values
-
no
output
is
included
for
these
cells
.
Cell
C3.7
(
row
R3
;
column
,
{
"name":
"comments"
}
)
contains
a
sequence
of
values;
the
set
of
values
are
included
in
an
array
.
Standard
mode
output
graph
verbatim.
for
this
example
is
provided
below:
{ "table": [{ "@id": "http://example.org/tree-ops-ext", "url": "http://example.org/tree-ops-ext.csv", "dc:title": "Tree Operations", "dcat:keyword": [ "tree", "street", "maintenance" ], "dc:publisher": [{ "schema:name": "Example Municipality", "schema:url": "http://example.org" }], "dc:license": "http://opendefinition.org/licenses/cc-by/", "dc:modified": "2010-12-31", "notes": [{ "@type": "oa:Annotation", "oa:hasTarget": "http://example.org/tree-ops-ext", "oa:hasBody": { "@type": "oa:EmbeddedContent", "rdf:value": "This is a very interesting comment about the table; it's a table!", "dc:format": "text/plain" } }], "row": [{ "url": "http://example.org/tree-ops-ext.csv#row=2", "rownum": 1, "describes": [{ "@id": "http://example.org/tree-ops-ext#gid-1", "on_street": "ADDISON AV", "species": "Celtis australis", "trim_cycle": "Large Tree Routine Prune", "dbh": 11, "inventory_date": "2010-10-18", "protected": false, "kml": "<Point><coordinates>-122.156485,37.440963</coordinates></Point>" }] }, { "url": "http://example.org/tree-ops-ext.csv#row=3", "rownum": 2, "describes": [{ "@id": "http://example.org/tree-ops-ext#gid-2", "on_street": "EMERSON ST", "species": "Liquidambar styraciflua", "trim_cycle": "Large Tree Routine Prune", "dbh": 11, "inventory_date": "2010-06-02", "protected": false, "kml": "<Point><coordinates>-122.156749,37.440958</coordinates></Point>" }] }, { "url": "http://example.org/tree-ops-ext.csv#row=4", "rownum": 3, "describes": [{ "@id": "http://example.org/tree-ops-ext#gid-6", "on_street": "ADDISON AV", "species": "Robinia pseudoacacia", "trim_cycle": "Large Tree Routine Prune", "dbh": 29, "inventory_date": "2010-06-01", "comments": [ "cavity or decay", "trunk decay", "codominant leaders", "included bark", "large leader or limb decay", "previous failure root damage", "root decay", "beware of BEES" ], "protected": true, "kml": "<Point><coordinates>-122.156299,37.441151</coordinates></Point>" }] }] }] }
Dates,
times
and
durations:
date
,
time
,
datetime
,
Table
T
(
dateTime
{
"url":
"http://example.org/tree-ops-ext.csv"}
and
)
has
been
explicitly
identified:
.
duration
{
"@id":
"<http://exmple.org/tree-ops-ext>"}
A
standard
syntax
for
dates
and
times
is
defined
by
[
iso8601
Non-core
annotations
].
This
format
can
be
readily
consumed
by
software
applications.
However,
dates
and
times
notes
specified
for
table
T
(
{
"url":
"http://example.org/tree-ops-ext.csv"}
)
are
often
provided
included
in
a
locale-specific
format,
or
use
alternate
calendars
and/or
eras.
the
output.
This
example
uses
a
single
annotated
table
describing
a
listing
of
cell
values
music
events.
Each
row
from
the
tabular
data
file
corresponds
to
three
resources;
the
music
event
itself,
the
location
where
that
event
occurs
and
assist
the
mapping
application
offer
to
sell
tickets
for
that
event.
The
goal
is
to
convert
the
cell
value
CSV
content
into
schema.org
to
markup
that
a
date,
time,
date-time
or
duration
format
readily
consumable
by
downstream
applications.
search
engine
such
as
Google
can
use
to
index
music
events.
Details
of
how
Google
expects
this
information
to
be
structured
can
be
found
here
.
The
input
tabular
data
file,
published
at
http://example.org/events-listing.csv
,
and
the
associated
metadata
description
http://example.org/events-listing.csv-metadata.json
are
provided
below:
Name, Start Date, Location Name, Location Address, Ticket Url B.B. King,2014-04-12T19:30,"Lupo’s Heartbreak Hotel","79 Washington St., Providence, RI",https://www.etix.com/ticket/1771656 B.B. King,2014-04-13T20:00,"Lynn Auditorium","Lynn, MA, 01901",http://frontgatetickets.com/venue.php?id=11766
{ "@context": ["http://www.w3.org/ns/csvw", {"@language": "en"}], "url": "events-listing.csv", "dialect": {"trim": true}, "tableSchema": { "columns": [{ "name": "name", "titles": "Name", "aboutUrl": "#event-{_row}", "propertyUrl": "schema:name" }, { "name": "start_date", "titles": "Start Date", "datatype": { "base": "datetime", "format": "yyyy-MM-ddTHH:mm" }, "aboutUrl": "#event-{_row}", "propertyUrl": "schema:startDate" }, { "name": "location_name", "titles": "Location Name", "aboutUrl": "#place-{_row}", "propertyUrl": "schema:name" }, { "name": "location_address", "titles": "Location Address", "aboutUrl": "#place-{_row}", "propertyUrl": "schema:address" }, { "name": "ticket_url", "titles": "Ticket Url", "datatype": "anyURI", "aboutUrl": "#offer-{_row}", "propertyUrl": "schema:url" }, { "name": "type_event", "virtual": true, "aboutUrl": "#event-{_row}", "propertyUrl": "rdf:type", "valueUrl": "schema:MusicEvent" }, { "name": "type_place", "virtual": true, "aboutUrl": "#place-{_row}", "propertyUrl": "rdf:type", "valueUrl": "schema:Place" }, { "name": "type_offer", "virtual": true, "aboutUrl": "#offer-{_row}", "propertyUrl": "rdf:type", "valueUrl": "schema:Offer" }, { "name": "location", "virtual": true, "aboutUrl": "#event-{_row}", "propertyUrl": "schema:location", "valueUrl": "#place-{_row}" }, { "name": "offers", "virtual": true, "aboutUrl": "#event-{_row}", "propertyUrl": "schema:offers", "valueUrl": "#offer-{_row}" }] } }
The
CSV
to
JSON
translation
is
limited
to
providing
one
statement,
or
triple,
per
column
in
the
table
.
The
target
schema.org
markup
requires
10
statements
to
describe
each
event.
As
the
base
tabular
data
publishers
SHOULD
file
contains
5
columns,
an
additional
5
virtual
columns
have
been
added
in
order
to
provide
dates
for
the
full
complement
of
statements—including
the
relationships
between
the
3
resources
(event,
location,
and
times
in
offer)
described
by
each
row
of
the
[
iso8601
table
.
Note
that
the
virtual
annotation
is
true
for
these
virtual
columns
]
format.
However,
where
data
publishers
choose
.
Furthermore,
note
that
no
attempt
is
made
to
use
locale-specific
date
and
time
formatting,
they
SHOULD
also
provide
equivalent
values
in
[
iso8601
reconcile
between
locations
or
offers
that
may
be
associated
with
more
than
one
event;
every
row
]
format
(e.g.
in
the
table
will
create
both
a
complementary
column).
new
location
resource
and
offer
resource
in
addition
to
the
event
resource.
If
considered
necessary,
applications
such
as
OpenRefine
may
be
used
to
identify
and
reconcile
duplicate
location
resources
once
the
JSON
output
has
been
generated.
Describing
The
annotated
table
generated
from
parsing
the
formatting
of
dates
tabular
data
file
and
times
is
currently
unresolved.
The
favoured
option
associated
metadata
is
to
defer
the
parsing
of
dates
shown
below
and
times
to
implementations
based
a
picture
string
provided
in
provides
the
metadata.
Unfortunately,
there
is
no
standard
syntax
basis
for
picture
strings,
therefore
an
array
of
picture
strings
relating
to
common
implementations
seems
like
the
best
option.
For
example:
conversion
to
JSON.
Annotations for the resulting table T , with 10 columns and 2 rows , are shown below:
id | core annotations | ||||
---|---|---|---|---|---|
url | columns | rows | |||
T |
|
C1 , C2 , C3 , C4 , C5 , C6 , C7 , C8 , C9 , C10 | R1 , R2 |
Annotations for the columns , rows and cells in table T are shown in the tables below.
Column annotations:
id | core annotations | ||||||
---|---|---|---|---|---|---|---|
table | number | source number | cells | name | titles | virtual | |
C1 | T | 1 | 1 | C1.1 , C2.1 |
|
|
|
C2 | T | 2 | 2 | C1.2 , C2.2 |
|
|
|
C3 | T | 3 | 3 | C1.3 , C2.3 |
|
| |
C4 | T | 4 | 4 | C1.4 , C2.4 |
location_address
|
Location
Address
| |
C5 | T | 5 | 5 | C1.5 , C2.5 |
ticket_url
|
Ticket
Url
| |
C6 | T | 6 | 6 | C1.6 , C2.6 |
type_event
|
true
| |
C7 | T | 7 | 7 | C1.7 , C2.7 |
type_place
|
true
| |
C8 | T | 8 | 8 | C1.8 , C2.8 |
type_offer
|
true
| |
C9 | T | 9 | 9 | C1.9 , C2.9 |
location
|
true
|
|
C10 | T | 10 | 10 | C1.10 , C2.10 |
offers
|
true
|
Row annotations:
id | core annotations | |||
---|---|---|---|---|
table | number | source number | cells | |
R1 | T | 1 | 2 | C1.1 , C1.2 , C1.3 , C1.4 , C1.5 , C1.6 , C1.7 , C1.8 , C1.9 , C1.10 |
R2 | T | 2 | 3 | C2.1 , C2.2 , C2.3 , C2.4 , C2.5 , C2.6 , C2.7 , C2.8 , C2.9 , C2.10 |
Where
an
implementation
is
able
to
interpret
one
of
the
provided
picture
strings,
the
date-time
value
reformatted
in
[
iso8601
Cell
annotations:
id | core annotations | |||||||
---|---|---|---|---|---|---|---|---|
table | column | row |
string
value
|
value
|
about URL | property URL | value URL | |
C1.1 | T | C1 | R1 |
"B.B.
King"
|
"B.B.
King"
|
<http://example.org/events-listing.csv#event-1>
|
schema:name
| |
C1.2 | T | C2 | R1 |
"2014-04-12T19:30"
|
2014-04-12T19:30:00
|
<http://example.org/events-listing.csv#event-1>
|
schema:startDate
| |
C1.3 | T | C3 | R1 |
"Lupo’s
Heartbreak
Hotel"
|
"Lupo’s
Heartbreak
Hotel"
|
<http://example.org/events-listing.csv#place-1>
|
schema:name
| |
C1.4 | T | C4 | R1 |
"79
Washington
St.,
Providence,
RI"
|
"79
Washington
St.,
Providence,
RI"
|
<http://example.org/events-listing.csv#place-1>
|
schema:address
| |
C1.5 | T | C5 | R1 |
"https://www.etix.com/ticket/1771656"
|
<https://www.etix.com/ticket/1771656>
|
<http://example.org/events-listing.csv#offer-1>
|
schema:url
| |
C1.6 | T | C6 | R1 |
""
|
null
|
<http://example.org/events-listing.csv#event-1>
|
rdf:type
|
schema:MusicEvent
|
C1.7 | T | C7 | R1 |
""
|
null
|
<http://example.org/events-listing.csv#place-1>
|
rdf:type
|
schema:Place
|
C1.8 | T | C8 | R1 |
""
|
null
|
<http://example.org/events-listing.csv#offer-1>
|
rdf:type
|
schema:Offer
|
C1.9 | T | C9 | R1 |
""
|
null
|
<http://example.org/events-listing.csv#event-1>
|
schema:location
|
<http://example.org/events-listing.csv#place-1>
|
C1.10 | T | C10 | R1 |
""
|
null
|
<http://example.org/events-listing.csv#event-1>
|
schema:offers
|
<http://example.org/events-listing.csv#offer-1>
|
C2.1 | T | C1 | R2 |
"B.B.
King"
|
"B.B.
King"
|
<http://example.org/events-listing.csv#event-2>
|
schema:name
| |
C2.2 | T | C2 | R2 |
"2014-04-13T20:00"
|
2014-04-13T20:00:00
|
<http://example.org/events-listing.csv#event-2>
|
schema:startDate
| |
C2.3 | T | C3 | R2 |
"Lynn
Auditorium"
|
"Lynn
Auditorium"
|
<http://example.org/events-listing.csv#place-2>
|
schema:name
| |
C2.4 | T | C4 | R2 |
"Lynn,
MA,
01901"
|
"Lynn,
MA,
01901"
|
<http://example.org/events-listing.csv#place-2>
|
schema:address
| |
C2.5 | T | C5 | R2 |
"http://frontgatetickets.com/venue.php?id=11766"
|
<http://frontgatetickets.com/venue.php?id=11766>
|
<http://example.org/events-listing.csv#offer-2>
|
schema:url
| |
C2.6 | T | C6 | R2 |
""
|
null
|
<http://example.org/events-listing.csv#event-2>
|
rdf:type
|
schema:MusicEvent
|
C2.7 | T | C7 | R2 |
""
|
null
|
<http://example.org/events-listing.csv#place-2>
|
rdf:type
|
schema:Place
|
C2.8 | T | C8 | R2 |
""
|
null
|
<http://example.org/events-listing.csv#offer-2>
|
rdf:type
|
schema:Offer
|
C2.9 | T | C9 | R2 |
""
|
null
|
<http://example.org/events-listing.csv#event-2>
|
schema:location
|
<http://example.org/events-listing.csv#place-2>
|
C2.10 | T | C10 | R2 |
""
|
null
|
<http://example.org/events-listing.csv#event-2>
|
schema:offers
|
<http://example.org/events-listing.csv#offer-2>
|
A
list
of
potential
date-time
formatting
implementations
needs
to
be
defined.
Minimal
mode
output
for
this
example
is
provided
below:
[{ "@id": "http://example.org/events-listing.csv#event-1", "@type": "schema:MusicEvent", "schema:name": "B.B. King", "schema:startDate": "2014-04-12T19:30:00", "schema:location": { "@id": "http://example.org/events-listing.csv#place-1", "@type": "schema:Place", "schema:name": "Lupo’s Heartbreak Hotel", "schema:address": "79 Washington St., Providence, RI" }, "schema:offer": { "@id": "http://example.org/events-listing.csv#offer-1", "@type": "schema:Offer", "schema:offer": "https://www.etix.com/ticket/1771656" } }, { "@id": "http://example.org/events-listing.csv#event-2", "@type": "schema:MusicEvent", "schema:name": "B.B. King", "schema:startDate": "2014-04-13T20:00:00", "schema:location": { "@id": "http://example.org/events-listing.csv#place-2", "@type": "schema:Place", "schema:name": "Lynn Auditorium", "schema:address": "Lynn, MA, 01901" }, "schema:offer": { "@id": "http://example.org/events-listing.csv#offer-2", "@type": "schema:Offer", "schema:offer": "http://frontgatetickets.com/venue.php?id=11766" } }]
Three
resources
are
defined
for
each
row
within
the
metadata
property
table;
event,
location
and
offer.
Therefore
three
objects
are
created
for
each
row
.
Each
column
description
explicitly
defines
both
separator
aboutUrl
is
specified
(e.g.
to
indicate
that
a
cell
value
is
to
be
parsed
into
a
list
of
values),
the
datatype
specified
by
and
datatype
propertyUrl
SHALL
be
inferred
to
apply
properties
which
are
used
to
create
the
members
of
about
URL
and
property
URL
annotations
on
the
resulting
list.
column's
cells
.
Columns
C6
,
C7
and
C8
(
,urlTemplate
{
"name":
"type_event"}
{
"name":
"type_place"}
If
metadata
property
and
urlTemplate
{
"name":
"type_offer"}
is
specified,
)
define
the
value
used
in
semantic
types
of
the
output
graph
SHALL
be
resources
described
by
each
row
:
schema:MusicEvent
,
schema:Place
and
schema:Offer
respectively—noting
that
the
result
use
of
rdf:type
is
converted
to
the
URI
Template
expansion,
as
defined
in
Section
3.1
Property
Syntax
name
of
@type
(as
used
in
[
tabular-metadata
json-ld
].
])
by
this
conversion
application.
Once
Column
C9
(
{
"name":
"location"}
)
uses
the
about
URL
has
been
generated
via
the
template
expansion,
relative
URLs
are
resolved
against
the
base
,
property
URL
and
value
URL
to
create
an
absolute
URL.
assert
the
relationship
between
the
event
and
location
resources.
Column
C10
(
)
uses
the
about
URL
,
property
URL
and
value
URL
to
assert
the
relationship
between
the
event
and
offer
resources.
default
{
"name":
"offer"}
If
metadata
property
default
Standard
mode
output
for
this
example
is
specified
provided
below:
{ "table": [{ "url": "http://example.org/events-listing.csv", "row": [{ "url": "http://example.org/events-listing.csv#row=2", "rownum": 1, "describes": [{ "@id": "http://example.org/events-listing.csv#event-1", "@type": "schema:MusicEvent", "schema:name": "B.B. King", "schema:startDate": "2014-04-12T19:30:00", "schema:location": { "@id": "http://example.org/events-listing.csv#place-1", "@type": "schema:Place", "schema:name": "Lupo’s Heartbreak Hotel", "schema:address": "79 Washington St., Providence, RI" }, "schema:offers": { "@id": "http://example.org/events-listing.csv#offer-1", "@type": "schema:Offer", "schema:url": "https://www.etix.com/ticket/1771656" } }] }, { "url": "http://example.org/events-listing.csv#row=3", "rownum": 2, "describes": [{ "@id": "http://example.org/events-listing.csv#event-2", "@type": "schema:MusicEvent", "schema:name": "B.B. King", "schema:startDate": "2014-04-13T20:00:00", "schema:location": { "@id": "http://example.org/events-listing.csv#place-2", "@type": "schema:Place", "schema:name": "Lynn Auditorium", "schema:address": "Lynn, MA, 01901" }, "schema:offers": { "@id": "http://example.org/events-listing.csv#offer-2", "@type": "schema:Offer", "schema:url": "http://frontgatetickets.com/venue.php?id=11766" } }] }] }] }
The
resources
described
by
each
row
are
explicitly
defined
using
the
about
URL
annotation—in
this
case
three
resources
per
row
(event,
location,
and
offer).
The
objects
containing
the
name-values
pairs
associated
with
the
cell
value
values
is
deemed
of
a
row
are
related
to
be
null
,
then
the
value
of
default
SHALL
be
used
object
for
each
subject
in
that
row
using
the
output
graph
.
name-value
pair
with
name
describes
.
This example is based on Use Case #4 - Publication of public sector roles and salaries and uses four annotated tables published as a group of tables . Information about senior roles and junior roles within a government department or organization are published in CSV format by each department. These are validated against a centrally published schema to ensure that all the data published by departments is consistent. Additionally, lists of organizations and professions are also published centrally, providing controlled vocabularies against which departmental submissions are validated.
Information published about junior and senior roles provides summary information for each post within the government department or organization. Whilst the junior role information is anonymous, providing only an indication of the number of full-time-equivalent (FTE) staff occupying a given post, the senior role information specifies the named individual occupying each post. As such, each row from the tabular data file describing senior roles corresponds to two resources; the post and the person occupying that post.
This example is concerned only with converting the information provided each government department or organization not the centrally published information listing organizations and professions.
The input tabular data files and associated metadata descriptions are provided below:
Organization Unique Reference,Organization Name,Department Reference hefce.ac.uk,Higher Education Funding Council for England,bis.gov.uk bis.gov.uk,"Department for Business, Innovation and Skills",xx
Profession Finance Information Technology Operational Delivery Policy
Post Unique Reference,Name,Grade,Job Title,Reports to Senior Post,Profession,Organization Reference 90115,Steve Egan,SCS1A,Deputy Chief Executive,90334,Finance,hefce.ac.uk 90334,Sir Alan Langlands,SCS4,Chief Executive,xx,Policy,hefce.ac.uk
Reporting Senior Post,Grade,Payscale Minimum (£),Payscale Maximum (£),Generic Job Title,Number of Posts (FTE),Profession,Organization Reference 90115,4,17426,20002,Administrator,8.67,Operational Delivery,hefce.ac.uk 90115,5,19546,22478,Administrator,0.5,Operational Delivery,hefce.ac.uk
{ "@type": "TableGroup", "@context": ["http://www.w3.org/ns/csvw", {"@language": "en"}], "tables": [{ "url": "gov.uk/data/organizations.csv", "tableSchema": "gov.uk/schemas/organizations.json", "suppressOutput": true }, { "url": "gov.uk/data/professions.csv", "tableSchema": "gov.uk/schemas/professions.json", "suppressOutput": true }, { "url": "senior-roles.csv", "tableSchema": "gov.uk/schemas/senior-roles.json" }, { "url": "junior-roles.csv", "tableSchema": "gov.uk/schemas/junior-roles.json" }] }
{ "@id": "http://example.org/gov.uk/schema/organizations.json", "@context": "http://www.w3.org/ns/csvw", "columns": [{ "name": "ref", "titles": "Organization Unique Reference", "datatype": "string", "required": true, "propertyUrl": "dc:identifier" }, { "name": "name", "titles": "Organization Name", "datatype": "string", "propertyUrl": "foaf:name" }, { "name": "department", "titles": "Department Reference", "datatype": "string", "null": "xx", "propertyUrl": "org:subOrganizationOf", "valueUrl": "http://example.org/organization/{ref}" }], "primaryKey": "ref", "aboutUrl": "http://example.org/organization/{ref}", "foreignKeys": [{ "columnReference": "department", "reference": { "schemaReference": "http://example.org/gov.uk/schema/organizations.json", "columnReference": "ref" } }] }
{ "@id": "http://example.org/gov.uk/schema/professions.json", "@context": "http://www.w3.org/ns/csvw", "columns": [{ "name": "name", "titles": "Profession", "datatype": "string", "required": true }], "primaryKey": "name" }
{ "@id": "http://example.org/gov.uk/schema/senior-roles.json", "@context": "http://www.w3.org/ns/csvw", "columns": [{ "name": "ref", "titles": "Post Unique Reference", "datatype": "string", "required": true, "propertyUrl": "dc:identifier" }, { "name": "name", "titles": "Name", "datatype": "string", "aboutUrl": "http://example.org/organization/{organizationRef}/person/{_row}", "propertyUrl": "foaf:name" }, { "name": "grade", "titles": "Grade", "datatype": "string", "propertyUrl": "http://example.org/gov.uk/def/grade" }, { "name": "job", "titles": "Job Title", "datatype": "string", "propertyUrl": "http://example.org/gov.uk/def/job" }, { "name": "reportsTo", "titles": "Reports to Senior Post", "datatype": "string", "null": "xx", "propertyUrl": "org:reportsTo", "valueUrl": "http://example.org/organization/{organizationRef}/post/{reportsTo}" }, { "name": "profession", "titles": "Profession", "datatype": "string", "propertyUrl": "http://example.org/gov.uk/def/profession" }, { "name": "organizationRef", "titles": "Organization Reference", "datatype": "string", "propertyUrl": "org:postIn", "valueUrl": "http://example.org/organization/{organizationRef}", "required": true }, { "name": "post_holder", "virtual": true, "propertyUrl": "org:heldBy", "valueUrl": "http://example.org/organization/{organizationRef}/person/{_row}" }], "primaryKey": "ref", "aboutUrl": "http://example.org/organization/{organizationRef}/post/{ref}", "foreignKeys": [{ "columnReference": "reportsTo", "reference": { "schemaReference": "http://example.org/gov.uk/schema/senior-roles.json", "columnReference": "ref" } }, { "columnReference": "profession", "reference": { "schemaReference": "http://example.org/gov.uk/schema/professions.json", "columnReference": "name" } }, { "columnReference": "organizationRef", "reference": { "schemaReference": "http://example.org/gov.uk/schema/organizations.json", "columnReference": "ref" } }] }
{ "@id": "http://example.org/gov.uk/schema/junior-roles.json", "@context": "http://www.w3.org/ns/csvw", "columns": [{ "name": "reportsToSenior", "titles": "Reporting Senior Post", "datatype": "string", "propertyUrl": "org:reportsTo", "valueUrl": "http://example.org/organization/{organizationRef}/post/{reportsToSenior}", "required": true }, { "name": "grade", "titles": "Grade", "datatype": "string", "propertyUrl": "http://example.org/gov.uk/def/grade" }, { "name": "min_pay", "titles": "Payscale Minimum (£)", "datatype": "integer", "propertyUrl": "http://example.org/gov.uk/def/min_pay" }, { "name": "max_pay", "titles": "Payscale Maximum (£)", "datatype": "integer", "propertyUrl": "http://example.org/gov.uk/def/max_pay" }, { "name": "job", "titles": "Generic Job Title", "datatype": "string", "propertyUrl": "http://example.org/gov.uk/def/job" }, { "name": "number", "titles": "Number of Posts (FTE)", "datatype": "number", "propertyUrl": "http://example.org/gov.uk/def/number_of_posts" }, { "name": "profession", "titles": "Profession", "datatype": "string", "propertyUrl": "http://example.org/gov.uk/def/profession" }, { "name": "organizationRef", "titles": "Organization Reference", "datatype": "string", "propertyUrl": "org:postIn", "valueUrl": "http://example.org/organization/{organizationRef}", "required": true }], "foreignKeys": [{ "columnReference": "reportsToSenior", "reference": { "schemaReference": "http://example.org/gov.uk/schema/senior-roles.json", "columnReference": "ref" } }, { "columnReference": "profession", "reference": { "schemaReference": "http://example.org/gov.uk/schema/professions.json", "columns": "name" } }, { "columnReference": "organizationRef", "reference": { "schemaReference": "http://example.org/gov.uk/schema/organizations.json", "columns": "ref" } }] }
This
example
makes
extensive
use
of
the
example.org
domain.
As
described
in
[
RFC6761
],
this
domain
is
used
for
illustrative
examples
don't
really
show
within
documentation.
In
reality,
the
edge
cases
-
probably
need
to
rework
them
resources
described
here
with
the
URL
path
/gov.uk
would
be
centrally
published
by
the
UK
Government
at,
say,
the
domain
data.gov.uk
.
The
first
example
illustrates
how
a
CSV
file
Given
that
these
resources
are
centrally
published
with
an
aspiration
for
reuse,
the
schema
descriptions
have
been
factored
out
into
separate
resources.
As
such,
the
top-level
metadata
annotations
drawn
description
resource
metadata.json
simply
provides
the
list
of
tables
and
binds
each
of
them
to
the
appropriate
schema
that
is
defined
elsewhere.
Finally,
note
that
because
the
centrally
published
metadata
descriptions
are
intended
to
be
reused
across
many
government
departments
and
organizations,
extra
consideration
has
been
given
to
defining
URIs
for
the
only
person
and
post
resources
defined
in
each
row
of
the
senior
roles
tabular
data
and
subsequently
referenced
from
the
junior
roles
tabular
data.
To
ensure
that
naming
clashes
are
avoided,
the
unique
reference
for
the
organization
to
which
the
person
or
post
belongs
has
been
included
in
a
header
line
path
segment
of
the
identifier.
For
example,
the
URI
template
property
aboutUrl
used
to
identify
the
senior
post
is
processed.
specified
as
http://example.org/organization/{organizationRef}/post/{ref}
,
thus
yielding
the
URI
http://example.org/organization/hefce.ac.uk/post/90115
for
the
post
described
in
the
first
row
of
the
senior
roles
tabular
data.
The
group
of
tables
generated
from
parsing
the
tabular
data
describes
lists
countries,
giving
their
country
code
files
and
name.
There
are
two
columns,
named
country
associated
metadata
is
shown
below
and
name
,
provides
the
basis
for
the
conversion
to
JSON.
Annotations
for
the
group
of
tables
G
and
the
four
rows.
tables
Ta
,
Tb
,
Tc
,
and
Td
are
shown
below.
Group of Tables annotations:
id | core annotations |
---|---|
tables | |
G | Ta , Tb , Tc , Td |
Table annotations:
id | core annotations | ||||
---|---|---|---|---|---|
url
|
| rows | suppress output | foreign keys | |
|
http://example.org/gov.uk/data/organizations.csv
| Ca1 , Ca2 , Ca3 | Ra1 , Ra2 |
true
| Fa1 |
|
http://example.org/gov.uk/professions.csv
| Cb1 | Rb1 , Rb2 , Rb3 , Rb4 |
true
|
|
|
http://example.org/senior-roles.csv
| Cc1 , Cc2 , Cc3 , Cc4 , Cc5 , Cc6 | Rc1 , Rc2 |
false
| Fc1 , Fc2 , Fc3 |
|
http://example.org/junior-roles.csv
|
Cd1 , Cd2 , Cd3 , Cd4 , Cd5 , Cd6 , Cd7 | Rd1 , Rd2 |
false
| Fd1 , Fd2 , Fd3 |
In
this
example,
output
for
the
centrally
published
lists
of
organizations
and
professions,
tables
Ta
and
Tb
(
http://example.org/country-codes-and-names.csv
http://example.org/gov.uk/data/organizations.csv
):
and
http://example.org/gov.uk/data/professions.csv
respectively),
are
not
required;
only
information
from
the
departmental
submissions
is
to
be
translated
to
RDF.
Note
the
suppress
output
annotation
on
this
table
.
The
resulting
JSON
output
graph:
following
foreign
keys
are
defined:
id | columns in table | columns in referenced table |
---|---|---|
Fa1 | Ca3 | Ca1 |
Fc1 | Cc5 | Cc1 |
Fc2 | Cc6 | Cb1 |
Fc3 | Cc7 | Ca1 |
Fd1 | Cd1 | Cc1 |
Fd2 | Cd7 | Cb1 |
Fd3 | Cd8 | Ca1 |
The
second
example
illustrates
how
the
mapping
is
modified
with
Annotations
for
the
addition
of
metadata
annotations
columns
,
rows
and
cells
in
table
T
are
shown
in
a
metadata
document.
The
CSV
file
is
a
small
extract
from
a
much
larger
Tree
Inventory
dataset
from
the
City
tables
below.
Column annotations:
id | core annotations | |||||||
---|---|---|---|---|---|---|---|---|
table | number | source number | cells | name | titles | required | virtual | |
Ca1 | Ta | 1 | 1 | Ca1.1 , Ca2.1 |
ref
|
Organization
Unique
Reference
|
true
| |
Ca2 | Ta | 1 | 1 | Ca1.2 , Ca2.2 |
name
|
Organization
Name
| ||
Ca3 | Ta | 1 | 1 | Ca1.3 , Ca2.3 |
department
|
Department
Reference
| ||
Cb1 | Tb | 1 | 1 | Cb1.1 , Cb2.1 , Cb3.1 , Cb4.1 |
name
|
Profession
|
true
| |
Cc1 | Tc | 1 | 1 | Cc1.1 , Cc2.1 |
ref
|
Post
Unique
Reference
|
true
| |
Cc2 | Tc | 2 | 2 | Cc1.2 , Cc2.2 |
name
|
Name
| ||
Cc3 | Tc | 3 | 3 | Cc1.3 , Cc2.3 |
grade
|
Grade
| ||
Cc4 | Tc | 4 | 4 | Cc1.4 , Cc2.4 |
job
|
Job
Title
| ||
Cc5 | Tc | 5 | 5 | Cc1.5 , Cc2.5 |
reportsTo
|
Reports
to
Senior
Post
| ||
Cc6 | Tc | 6 | 6 | Cc1.6 , Cc2.6 |
profession
|
Profession
| ||
Cc7 | Tc | 7 | 7 | Cc1.7 , Cc2.7 |
organizationRef
|
Organization
Reference
|
true
| |
Cc8 | Tc | 8 | 8 | Cc1.8 , Cc2.8 |
post_holder
|
true
| ||
Cd1 | Td | 1 | 1 | Cd1.1 , Cd2.1 |
reportsToSenior
|
Reporting
Senior
Post
|
true
| |
Cd2 | Td | 2 | 2 | Cd1.2 , Cd2.2 |
grade
|
Grade
| ||
Cd3 | Td | 3 | 3 | Cd1.3 , Cd2.3 |
min_pay
|
Payscale
Minimum
(£)
| ||
Cd4 | Td | 4 | 4 | Cd1.4 , Cd2.4 |
max_pay
|
Payscale
Maximum
(£)
| ||
Cd5 | Td | 5 | 5 | Cd1.5 , Cd2.5 |
job
|
Generic
Job
Title
| ||
Cd6 | Td | 6 | 6 | Cd1.6 , Cd2.6 |
number
|
Number
of
| ||
Cd7 | Td | 7 | 7 | Cd1.7 , Cd2.7 |
|
| ||
Cd8 | Td | 8 | 8 | Cd1.8 , Cd2.8 |
|
|
|
Column
Cc8
,
with
the
virtual
annotation
specified
as
true
,
and
three
rows.
is
used
to
relate
the
person
resource,
whose
name
is
provided
in
column
Cc2
,
to
the
associated
post
resource
within
the
current
row
of
table
Tc
(
{
"url":
"http://example.org/senior-roles.csv"
}
).
Row annotations:
id | core annotations | |||
---|---|---|---|---|
|
|
|
|
|
Ra1 | Ta | 1 |
|
|
|
| 2 | 3 | Ca2.1 , Ca2.2 , Ca2.3 |
Rb1 | Tb | 1 | 2 |
|
|
|
| 3 | Cb2.1 |
Rb3 | Tb | 3 |
|
|
|
| 4 | 5 | Cb4.1 |
Rc1 | Tc | 1 | 2 | Cc1.1 , Cc1.2 , Cc1.3 , Cc1.4 , Cc1.5 , Cc1.6 , Cc1.7 , Cc1.8 |
Rc2 | Tc | 2 | 3 | Cc2.1 , Cc2.2 , Cc2.3 , Cc2.4 , Cc2.5 , Cc2.6 , Cc2.7 , Cc2.8 |
Rd1 | Td | 1 | 2 | Cd1.1 , Cd1.2 , Cd1.3 , Cd1.4 , Cd1.5 , Cd1.6 , Cd1.7 , Cd1.8 |
Rd2 | Td | 2 | 3 | Cd2.1 , Cd2.2 , Cd2.3 , Cd2.4 , Cd2.5 , Cd2.6 , Cd2.7 , Cd2.8 |
The
CSV
input
(published
at
Cell
annotations:
id | core annotations | |||||||
---|---|---|---|---|---|---|---|---|
table | column | row | string value | value | about URL | property URL | value URL | |
Ca1.1 | Ta | Ca1 | Ra1 |
|
|
<http://example.org/organization/hefce.ac.uk>
|
dc:identifier
| |
Ca1.2 | Ta | Ca2 | Ra1 |
"Higher
Education
Funding
Council
for
England"
|
"Higher
Education
Funding
Council
for
England"
|
<http://example.org/organization/hefce.ac.uk>
|
foaf:name
| |
Ca1.3 | Ta | Ca3 | Ra1 |
"bis.gov.uk"
|
"bis.gov.uk"
|
<http://example.org/organization/hefce.ac.uk>
|
org:subOrganizationOf
|
<http://example.org/organization/bis.gov.uk>
|
Ca2.1 | Ta | Ca1 | Ra2 |
"bis.gov.uk"
|
"bis.gov.uk"
|
<http://example.org/organization/bis.gov.uk>
|
dc:identifier
| |
Ca2.2 | Ta | Ca2 | Ra2 |
"Department
for
Business,
Innovation
and
|
"Department
for
|
<http://example.org/organization/bis.gov.uk>
|
foaf:name
| |
Ca2.3 | Ta | Ca3 | Ra2 |
"xx"
|
null
|
<http://example.org/organization/bis.gov.uk>
|
org:subOrganizationOf
| |
Cb1.1 | Tb | Cb1 | Rb1 |
"Finance"
|
"Finance"
| |||
Cb2.1 | Tb | Cb1 | Rb2 |
"Information
Technology"
|
"Information
Techology"
| |||
Cb3.1 | Tb | Cb1 | Rb3 |
"Operational
Delivery"
|
"Operational
Delivery"
| |||
Cb4.1 | Tb | Cb1 | Rb4 |
"Policy"
|
"Policy"
| |||
Cc1.1 | Tc | Cc1 | Rc1 |
"90115"
|
"90115"
|
<http://example.org/organization/hefce.ac.uk/post/90115>
|
dc:identifier
| |
Cc1.2 | Tc | Cc2 | Rc1 |
"Steve
Egan"
|
"Steve
Egan"
|
<http://example.org/organization/hefce.ac.uk/person/1>
|
foaf:name
| |
Cc1.3 | Tc | Cc3 | Rc1 |
"SCS1A"
|
"SCS1A"
|
<http://example.org/organization/hefce.ac.uk/post/90115>
|
<http://example.org/gov.uk/def/grade>
| |
Cc1.4 | Tc | Cc4 | Rc1 |
"Deputy
Chief
Executive"
|
"Deputy
Chief
Executive"
|
<http://example.org/organization/hefce.ac.uk/post/90115>
|
<http://example.org/gov.uk/def/job>
| |
Cc1.5 | Tc | Cc5 | Rc1 |
"90334"
|
"90334"
|
<http://example.org/organization/hefce.ac.uk/post/90115>
|
org:reportsTo
|
<http://example.org/organization/hefce.ac.uk/post/90334>
|
Cc1.6 | Tc | Cc6 | Rc1 |
"Finance"
|
"Finance"
|
<http://example.org/organization/hefce.ac.uk/post/90115>
|
<http://example.org/gov.uk/def/profession>
| |
Cc1.7 | Tc | Cc7 | Rc1 |
"hefce.ac.uk"
|
"hefce.ac.uk"
|
<http://example.org/organization/hefce.ac.uk/post/90115>
|
org:postIn
|
<http://example.org/organization/hefce.ac.uk>
|
Cc1.8 | Tc | Cc8 | Rc1 |
""
|
null
|
<http://example.org/organization/hefce.ac.uk/post/90115>
|
org:heldBy
|
<http://example.org/organization/hefce.ac.uk/person/1>
|
Cc2.1 | Tc | Cc1 | Rc2 |
"90334"
|
"90334"
|
<http://example.org/organization/hefce.ac.uk/post/90334>
|
dc:identifier
| |
Cc2.2 | Tc | Cc2 | Rc2 |
"Sir
Alan
Langlands"
|
"Sir
Alan
Langlands"
|
<http://example.org/organization/hefce.ac.uk/person/2>
|
foaf:name
| |
Cc2.3 | Tc | Cc3 | Rc2 |
"SCS4"
|
"SCS4"
|
<http://example.org/organization/hefce.ac.uk/post/90334>
|
<http://example.org/gov.uk/def/grade>
| |
Cc2.4 | Tc | Cc4 | Rc2 |
"Chief
Executive"
|
"Chief
Executive"
|
<http://example.org/organization/hefce.ac.uk/post/90334>
|
<http://example.org/gov.uk/def/job>
| |
Cc2.5 | Tc | Cc5 | Rc2 |
"xx"
|
null
|
<http://example.org/organization/hefce.ac.uk/post/90334>
|
org:reportsTo
| |
Cc2.6 | Tc | Cc6 | Rc2 |
"Policy"
|
"Policy"
|
<http://example.org/organization/hefce.ac.uk/post/90334>
|
<http://example.org/gov.uk/def/profession>
| |
Cc2.7 | Tc | Cc7 | Rc2 |
"hefce.ac.uk"
|
"hefce.ac.uk"
|
<http://example.org/organization/hefce.ac.uk/post/90334>
|
org:postIn
|
<http://example.org/organization/hefce.ac.uk>
|
Cc2.8 | Tc | Cc8 | Rc2 |
""
|
null
|
<http://example.org/organization/hefce.ac.uk/post/90334>
|
org:heldBy
|
<http://example.org/organization/hefce.ac.uk/person/2>
|
Cd1.1 | Td | Cd1 | Rd1 |
"90115"
|
"90115"
|
org:reportsTo
|
<http://example.org/organization/hefce.ac.uk/post/90115>
| |
Cd1.2 | Td | Cd2 | Rd1 |
"4"
|
"4"
|
<http://example.org/gov.uk/def/grade>
| ||
Cd1.3 | Td | Cd3 | Rd1 |
"17426"
|
17426
|
<http://example.org/gov.uk/def/min_pay>
| ||
Cd1.4 | Td | Cd4 | Rd1 |
"20002"
|
20002
|
<http://example.org/gov.uk/def/max_pay>
| ||
Cd1.5 | Td | Cd5 | Rd1 |
"Administrator"
|
"Administrator"
|
<http://example.org/gov.uk/def/job>
| ||
Cd1.6 | Td | Cd6 | Rd1 |
"8.67"
|
8.67
|
<http://example.org/gov.uk/def/number_of_posts>
| ||
Cd1.7 | Td | Cd7 | Rd1 |
"Operational
Delivery"
|
"Operational
Delivery"
|
<http://example.org/gov.uk/def/profession>
| ||
Cd1.8 | Td | Cd8 | Rd1 |
"hefce.ac.uk"
|
"hefce.ac.uk"
|
org:postIn
|
<http://example.org/organization/hefce.ac.uk>
| |
Cd2.1 | Td | Cd1 | Rd2 |
"90115"
|
"90115"
|
org:reportsTo
|
<http://example.org/organization/hefce.ac.uk/post/90115>
| |
Cd2.2 | Td | Cd2 | Rd2 |
"5"
|
"5"
|
<http://example.org/gov.uk/def/grade>
| ||
Cd2.3 | Td | Cd3 | Rd2 |
"19546"
|
19546
|
<http://example.org/gov.uk/def/min_pay>
| ||
Cd2.4 | Td | Cd4 | Rd2 |
"22478"
|
22478
|
<http://example.org/gov.uk/def/max_pay>
| ||
Cd2.5 | Td | Cd5 | Rd2 |
"Administrator"
|
"Administrator"
|
<http://example.org/gov.uk/def/job>
| ||
Cd2.6 | Td | Cd6 | Rd2 |
"0.5"
|
0.5
|
<http://example.org/gov.uk/def/number_of_posts>
| ||
Cd2.7 | Td | Cd7 | Rd2 |
"Operational
Delivery"
|
"Operational
Delivery"
|
<http://example.org/gov.uk/def/profession>
| ||
Cd2.8 | Td | Cd8 | Rd2 |
"hefce.ac.uk"
|
"hefce.ac.uk"
|
org:postIn
|
<http://example.org/organization/hefce.ac.uk>
|
Notice
that
value
URL
are
described
below.
The
metadata
is
not
specified
for
a
group
of
tables
SHALL
be
provided
by
a
table
group
description
cells
(as
defined
Ca2.3
and
Cc2.5
because
in
[
tabular-metadata
each
case
the
cell
value
])
within
is
null
and
the
associated
metadata
document.
virtual
annotation
of
column
Cb5
is
not
defined.
5.1
Minimal
mode
output
for
this
example
is
provided
below:
[{ "@id": "http://example.org/organization/hefce.ac.uk/post/90115", "dc:identifier": "90115", "org:heldBy": { "@id": "http://example.org/organization/hefce.ac.uk/person/1", "foaf:name": "Steve Egan" }, "http://example.org/gov.uk/def/grade": "SCS1A", "http://example.org/gov.uk/def/job": "Deputy Chief Executive", "org:reportsTo": "http://example.org/organization/hefce.ac.uk/post/90334", "http://example.org/gov.uk/def/profession": "Finance", "org:postIn": "http://example.org/organization/hefce.ac.uk" }, { "@id": "http://example.org/organization/hefce.ac.uk/post/90334", "dc:identifier": "90334", "org:heldBy": { "@id": "http://example.org/organization/hefce.ac.uk/person/2", "foaf:name": "Sir Alan Langlands" }, "http://example.org/gov.uk/def/grade": "SCS4", "http://example.org/gov.uk/def/job": "Chief Executive", "http://example.org/gov.uk/def/profession": "Policy", "org:postIn": "http://example.org/organization/hefce.ac.uk" }, { "org:reportsTo": "http://example.org/organization/hefce.ac.uk/post/90115", "http://example.org/gov.uk/def/grade": "4", "http://example.org/gov.uk/def/min_pay": 17426, "http://example.org/gov.uk/def/max_pay": 20002, "http://example.org/gov.uk/def/job": "Administrator", "http://example.org/gov.uk/def/number_of_posts": 8.67, "http://example.org/gov.uk/def/profession": "Operational Delivery", "org:postIn": "http://example.org/organization/hefce.ac.uk" }, { "org:reportsTo": "http://example.org/organization/hefce.ac.uk/post/90115", "http://example.org/gov.uk/def/grade": "5", "http://example.org/gov.uk/def/min_pay": 19546, "http://example.org/gov.uk/def/max_pay": 22478, "http://example.org/gov.uk/def/job": "Administrator", "http://example.org/gov.uk/def/number_of_posts": 0.5, "http://example.org/gov.uk/def/profession": "Operational Delivery", "org:postIn": "http://example.org/organization/hefce.ac.uk"Generating JSON}]
Where
present
in
the
table
group
description
,
any
Common
Properties
(as
Prefixes
defined
in
Section
3.3
Common
Properties
within
the
RDFa
1.1
Initial
Context
of
[
([
tabular-metadata
rdfa-core
])
SHALL
be
are
not
expanded;
e.g.
dc:
for
<http://purl.org/dc/terms/>.
Output
for
tables
Ta
and
Tb
(
{
"url":
"http://example.org/gov.uk/data/organizations.csv"
}
and
{
"url":
"http://example.org/gov.uk/data/professions.csv"
}
)
are
not
included
in
as
the
suppress
output
graph
within
annotation
has
the
root
object.
The
root
object
SHALL
contain
an
array
named
value
table
true
containing
one
object
for
each
of
the
tables
listed
in
the
resources
array
of
the
table
group
description
.
Each
table
The
property
URL
SHALL
be
processed
sequentially
according
to
the
appropriate
set
of
rules
is
specified
for
mapping
core
or
annotated
tabular
data
.
Refer
to
Section
3
Mapping
Core
Tabular
Data
all
cells
and
Section
4
Mapping
Annotated
Tabular
Data
in
tables
for
further
details.
Tc
and
Td
.
The
JSON
generated
from
processing
Columns
Cc5
and
Cd1
(
{
"name":
"reportsTo"
}
and
{
"name":
"reportsToSenior"
}
)
use
the
tables
about
URL
,
property
URL
SHALL
be
incorporated
into
and
value
URL
annotations
to
assert
the
output
graph
relationship
between
the
given
post
and
the
senior
post
it
reports
to
for
the
cells
as
therein.
However,
since
senior
posts
and
junior
posts
are
described
in
different
tables
it
is
not
possible
to
create
nested
objects
within
the
table
array.
for
this
particular
case.
Any
of
the
inherited
properties
Similarly,
columns
Cc7
and
Cd8
(both
with
null
,
separator
,
format
,
datatype
,
or
default
{
"name":
"organizationRef"
}
defined
within
)
use
the
table
group
description
about
URL
,
property
URL
SHALL
be
used
and
value
URL
annotations
to
pre-populate
assert
the
column
description
objects
relationship
between
the
given
post
and
the
organization
to
which
it
belongs
for
the
cells
those
columns
.
Finally,
note
that
two
resources
are
created
for
each
row
within
table
in
Tc
(
{
"url":
"http://example.org/senior-roles.csv"
}
):
the
group.
Where
person
and
the
same
property
post
they
occupy.
The
relationship
between
these
resources
is
defined
in
specified
via
virtual
column
Cc8
(
{
"name":
"post_holder"
}
)
using
the
table
group
description
,
table
description
about
URL
,
schema
property
URL
or
column
description
and
value
URL
annotations.
The
person
object
provides
the
order
value
of
precedence
SHALL
the
name-value
pair
with
corresponding
name
org:heldBy
,
thus
nesting
the
person
be:
object
within
the
post
object
.
Issue
Standard
mode
output
for
this
example
is
provided
below:
{ "table": [{ "url": "http://example.org/senior-roles.csv", "row": [{ "url": "http://example.org/senior-roles.csv#row=2", "rownum": 1, "describes": [{ "@id": "http://example.org/organization/hefce.ac.uk/post/90115", "dc:identifier": "90115", "org:heldBy": { "@id": "http://example.org/organization/hefce.ac.uk/person/1", "foaf:name": "Steve Egan" }, "http://example.org/gov.uk/def/grade": "SCS1A", "http://example.org/gov.uk/def/job": "Deputy Chief Executive", "org:reportsTo": "http://example.org/organization/hefce.ac.uk/post/90334", "http://example.org/gov.uk/def/profession": "Finance", "org:postIn": "http://example.org/organization/hefce.ac.uk" }] }, { "url": "http://example.org/senior-roles.csv#row=3", "rownum": 2, "describes": [{ "@id": "http://example.org/organization/hefce.ac.uk/post/90334", "dc:identifier": "90334", "org:heldBy": { "@id": "http://example.org/organization/hefce.ac.uk/person/2", "foaf:name": "Sir Alan Langlands" }, "http://example.org/gov.uk/def/grade": "SCS4", "http://example.org/gov.uk/def/job": "Chief Executive", "http://example.org/gov.uk/def/profession": "Policy", "org:postIn": "http://example.org/organization/hefce.ac.uk" }] }] }, { "url": "http://example.org/junior-roles.csv", "row": [{ "url": "http://example.org/junior-roles.csv#row=2", "rownum": 1, "describes": [{ "org:reportsTo": "http://example.org/organization/hefce.ac.uk/post/90115", "http://example.org/gov.uk/def/grade": "4", "http://example.org/gov.uk/def/min_pay": 17426, "http://example.org/gov.uk/def/max_pay": 20002, "http://example.org/gov.uk/def/job": "Administrator", "http://example.org/gov.uk/def/number_of_posts": 8.67, "http://example.org/gov.uk/def/profession": "Operational Delivery", "org:postIn": "http://example.org/organization/hefce.ac.uk" }] }, { "url": "http://example.org/junior-roles.csv#row=3", "rownum": 2, "describes": [{ "org:reportsTo": "http://example.org/organization/hefce.ac.uk/post/90115", "http://example.org/gov.uk/def/grade": "5", "http://example.org/gov.uk/def/min_pay": 19546, "http://example.org/gov.uk/def/max_pay": 22478, "http://example.org/gov.uk/def/job": "Administrator", "http://example.org/gov.uk/def/number_of_posts": 0.5, "http://example.org/gov.uk/def/profession": "Operational Delivery", "org:postIn": "http://example.org/organization/hefce.ac.uk" }] }] }] }
The
document
has
undergone
substantial
changes
since
the
first
public
sector
roles
working
draft
.
Below
are
some
of
the
changes
made: