On Wed, Aug 12, 2009 at 10:48 AM, Karen Coyle<[log in to unmask]> wrote:
> Ross Singer wrote:
>>
>> 3) What, specifically, is missing from DCTerms that would make a MODS
>> ontology needed? What, specifically, is missing from Bibliontology or
>> MusicOntology or FOAF or SKOS, etc. that justifies a new and, in many
>> places, overlapping vocabulary? Would time be better spent trying to
>> improve the existing vocabularies?
>>
>
> MARC: 182 fields, 1711 subfields, 2401 fixed field values
> DC: 59 properties
I see where you're going with this, but I'm not sure it's a fair
critique. It's sort of on par with saying that a Dodge Grand Caravan
is a more sophisticated vehicle than a Mini Cooper because it has more
horsepower, 3 times as many cup holders and vastly more cubic footage
in the interior. A Caravan /may/ be a more sophisticated vehicle, but
I'm not sure a quick run over the specs can necessarily reveal that.
One of the problems here is that it doesn't begin to address the DCAM
-- these are 59 properties that can be reused among 22 classes, giving
them different semantic meaning.
>
> Look at the sample records in MARCXML and DC at
> http://www.loc.gov/standards/marcxml and you will see how lossy it is.
Now I think you know you're being a little misleading here. For one
thing, it's using DC Elements and it's not doing /anything/ vaguely
RDF-related. Unfortunately, I think it's examples like this that have
led libraries to write DC off as next to worthless (and
understandably!).
Dublin Core is toothless and practically worthless in XML form. It is
considerably more powerful when used in RDF, however, because they
play to their mutual strengths, namely that in RDF, you generally
don't use a schema in isolation.
>Now,
> you could argue that no one needs all of the detail in MARC, and I'm sure it
> could be reduced down to something more rational, plus there is redundancy
> in it, but for pity's sake, DC doesn't have a way to indicate the EDITION of
> a work.
This is true. But this is also why I'm asking what is missing in
DCTerms that would be available in MODS -- The "win" of RDF is that
you aren't contrained by the limits of a particular schema. If a
particular vocabulary gets you a fair ways towards representing your
resource, but something is missing, it's perfectly reasonable (and
expected) to plug in other vocabularies to fill in the gaps.
For example, SKOS doesn't need to add coordinate properties to
properly define locations. Instead, you pull in a vocabulary that is
optimized for defining geographic place (say, wgs_84) and rather than
suboptimally retrofit a vocabulary designed for modeling thesauri, use
one that is explicitly intended to model the resource at hand (and,
preferably, only that).
I think it's somewhat analogous to the notion of domain-specific
languages: there's an abstraction between the resource and the most
efficient way to access it.
> FOAF has both *surname* and *family name* and says: "These are not
> current stable or consistent..." No sh*t. And try to clearly code a name
> like "Pope John Paul II" in FOAF. Oh, and death dates. No death dates in
> FOAF because you wouldn't have DEAD FRIENDS. But authors die.
>
FOAF isn't the only vocabulary available to model people and I'm
hardly saying it's "the answer" here. I mean, MARC is complicated in
this regard, too. "Rodrigo Jimenez Hernandez Garcia" "Liu Ming
Chung". Names are hard. I think pretty much any schema is going to
have to have rules and conventions to compensate for the variability
of how different cultures prescribe identity.
Maybe vCard would be better (maybe not). The Bio vocabulary might be
a better option for defining biographical "events" (birth, death,
etc.). It lacks some of the attributes that libraries use
(flourishing dates, for example) and shares the disadvantage inherent
in RDF that RDF can't express inexact dates very well.
I think a common misperception of RDF in library circles is that there
is no vocabulary that does everything we need. Rather, I think that
this is one of RDF's strength: no vocabulary can successfully model
the universe, so, instead, focus on the specifics. The library world
instead takes the opposite approach, which tends to cause things to
get shoehorned in to meet the shape of the model rather than be
expressed in a way more naturally suited to the resource.
-Ross.
|