On Thu, Apr 9, 2009 at 10:37 PM, Bill Dueber b...@dueber.com wrote:
This is hard stuff. But it's worth doing right.
+1
The issue here isn't about serializations or transmission formats.
It's about data modeling. Our current bibliographic data model is
horribly inefficient, with antiquated
JCDL Workshop of possible interest:
Integrating Digital Library Content with Computational Tools and
Services ( 6/19 in Austin).
Pardon the forward! -Jodi
Begin forwarded message:
From: J. Stephen Downie jdow...@uiuc.edu
Date: April 9, 2009 10:35:15 AM EDT
To: undisclosed-recipients: ;
Bill and Peter,
Very nice posts. XML, RDF, MARC and DC are all different ways to present
information in a way (of course, XML, RDF, and DC are easier to read/processed
by machine).
However, down the fundamentals, I think that it can go deeper, basically data
structure and algorithms making
(Attention: lurker emerging)
To me what it comes down to is neither simplicity nor complexity, but
extensibility. In a perfect world, our data models should be capable of
representing very sophisticated and robust relationships at a high level
of granularity, while still accommodating ease of
Extensibility as absolutely key. I know that some people consider XML to
be inherently extensible, but I'm concerned that the conceptual model
presented by FRBR doesn't support extensibility. For example, the FRBR
entity Place represents only the place as a subject. If you want to
represent
I completely agree with Karen regarding how FRBR falls short in not
allowing for more relationships between Group 1-2 and Group 3 entities.
FRBRoo fleshes out some of these things, but in a woefully unweildy way,
IMO. Conversely, FRBR in RDF (at http://vocab.org/frbr) consolidates
some classes
Well, the thing is, those sem web folks LIKE what has resulted. They think it's
_good_ that http:// can be resolved with a certain protocol in some cases, but
can be an arbitrary identifier untied to protocol in others.
It definitely is convenient in some cases.
I have mixed feelings, I
