On
1/20/16 3:25 AM,
Oddrun Ohren
wrote:
Thanks
Ray Denenberg
for your
clarifications!
It might well be
that life-cycle
events are best
kept separate
from events as
entities
described or
captured in
works.
However,
I still think
that bf:Content
(or
bf:EventContent)
is unnecessary,
and I hope you
BIBFRAME 2.0
developers will
come round to
the same way of
thinking J.
(Concerning
examples of
events modeled
as works, I
think Tim
Thompson
provided several
good examples.
Referring to the
draft proposal,
perhaps the
battle
re-enactment
event may be
considered a
work)
IMHO
one should
always think
long and hard
before solving
any need for
increased
granularity by
subclassing
existing
classes. Class
hierarchies are
static
structures, and
should express
fairly stable
knowledge.
Therefore, I am
wondering if you
plan to do
something about
the bf:Work
class and its
subclassing into
media specific
sub-classes in
BIBFRAME 2.0?
As far as I can
see, none of the
Work subclasses
has additional
properties
(compared to
Work), a fact
which in itself
rather defeats
the purpose of
subclassing. A
more flexible
solution would
be to introduce
a property
“type” or
similar to Work,
and offer a
controlled
vocabulary of
work types as
potential value
set. A work type
vocabulary would
at any rate be
easier to
maintain through
changing media
types than would
a set of
subclasses.
Moreover, it
will then be
possible to use
other type
vocabularies in
domains where
these are more
relevant than
the
“recommended”
one.
It so happens that
I just did a short
blog post on
subclassing Work,
albeit related to
FRBR but possibly
valid also for
BIBFRAME.
http://kcoyle.blogspot.com/2016/01/sub-types-in-frbr.html
There are indeed
additional
properties, they
just haven't been
singled out as
such. Any
property, like
"bf:musicKey" is a
de facto indicator
of a sub-type (aka
sub-class).
BIBFRAME has a
number of
properties whose
names begin with
"cartographic..."
and others that
begin with
"music..." So the
type-specific
properties exist
they just haven't
been organized as
such (something
which might be
useful for folks
cataloging in
those areas).
I disagree that
subclassing is
static -- at least
not in RDF. Any
subject can be an
instance of more
than one class,
and classes only
have impact when
operated upon, as
in querying. It is
my understanding
that in RDF it is
very convenient to
operate on data
using classes,
much more so than
indicating types
using values. So
there may be a
practical reason
for sub-typing,
but it doesn't
have to impose
limitations,
AFAIK. Anyway,
it's worth
thinking about.
Note also that
some non-library
implementations of
FRBR have made use
of sub-typing of
WEM, some even
quite extensively:
http://speroni.web.cs.unibo.it/cgi-bin/lode/req.py?req=http:/purl.org/spar/fabio
The frbrCore
vocabulary
introduced just a
few sample
subtypes:
http://vocab.org/frbr/core.html
kc
>
• Not being sure
how explicitly
point *1.c*of the
proposal is meant,
I’d just like
>
to point out that
events may play
other roles than
being the
*subject* of some
The
line "A bf:Event
will be described
in the same manner
as other BIBFRAME
Subject Types.."
is poorly worded
(my fault).
Probably better
would be: "An
event will be
described in the
same manner as
other external
resources."
For
example, a
person. While a
bf:Person is a
BIBFRAME resource,
it consists of
simply a label,
and a link to an
external
description of the
person (a MADS
description, FOAF,
VIAF, etc.).
That's really all
that that was
trying to say: the
concept of a
bf:Event relies
on the
availability of an
external
description of
that event.
(Except that for
the event, there
may be some basic
properties besides
just the label
within the
BIBFRAME resource,
for example date
and time, but for
any additional
description there
will have to be an
external resource
describing the
event.)
>
represent
life-cycle events
of a work
(launching,
publication,
recording)
>
explicitly in some
cases. At any rate
we should take
care that the
Event class is
>
not modelled in
such a way that
one specific role
is assumed.
Event,
as we currently
envision it to be
modeled, will not
include these
life-cycle events,
we plan to model
these differently.
Tentatively, there
will be a property
with name
something like
bf:originationActivity
and class
bf:OriginationActivity,
with subclasses
like
bf:Publication,
bf:Distribution,
and so on, and
each of these will
have properties
like agent, date,
place.
>
able to see what
bf:Content
contributes other
than extra
>
(unnecessary)
complexity… o
Firstly, it is
problematic to
constrain
something as
>
general-sounding
as Content to be a
capture of an
Event.
We
are currently
considering
changing the name
to EventContent.
>
o Secondly, if
bf:depicts/bf:captures
are defined as
properties of both
Work and
>
Event (like their
parent bf:subject)
with expected
value *any
resource*
>
(instances of any
BIBFRAME class,
including Work),
there should be no
need for
>
bf:Content. This
way,
bf:depicts/bf:captures
could also be used
to represent the
>
fact that some
works capture
other works (e.g.
photographs of
paintings).
>
o Lastly, seeing
that the existing
subclasses of Work
are more or less
disjunct,
>
bf:Content will
create confusion,
as it clearly
overlaps several
of the existing
These
are good points
and we will need
to discuss them.
>
It will also be
possible to
represent
>
events as a work
where appropriate,
without losing the
possibility to
express
>
information about
capturing
Do
you have an
example of an
Event that could
be modelled as a
Work?
Thanks
much for your
comments and
suggestions.
--
Karen Coyle
[log in to unmask] http://kcoyle.net
m: +1-510-435-8234
skype: kcoylenet/+1-510-984-3600