Ross,
I'm not questioning the technical assertion -- obviously you can combine
properties from different vocabularies. My problem is with making sense
of FRBR in relation to the properties, either in RDA or in bibo. Do you
say that a particular grouping of properties is of type
FRBR:Manifesta
So, thanks to the help of my coworkers, here's the RDA Elements schema
reformatted in an easier to read presentation:
http://morph.talis.com/?data-uri[]=http%3A%2F%2Frdvocab.info%2FElements.rdf&input=&output=exhibit&callback=
I have to say I feel like this schema is trying to both do way too
much
On Sun, Apr 5, 2009 at 10:40 AM, Peter Schlumpf wrote:
> I want to get back to simple things. Imagine if there were no Marc records.
> Minimal layers of abstraction. No politics. No vendors. No SQL
> straightjacket. What would an ILS look like without those things?
Back to this original
Ross Singer wrote:
So, thanks to the help of my coworkers, here's the RDA Elements schema
reformatted in an easier to read presentation:
http://morph.talis.com/?data-uri[]=http%3A%2F%2Frdvocab.info%2FElements.rdf&input=&output=exhibit&callback=
I have to say I feel like this schema is trying to
On Apr 7, 2009, at 1:15 PM, Karen Coyle wrote:
Absolutely. The catalogers are still creating a textual document, not
data. At best you can mark up the text, as we do with the MARC
record...
Listen... What you hear from over here is the sound of a very heavy
sigh coming from a computer ty
See also the thread, 'RDA: A Standard Nobody Will Notice'.
http://www.mail-archive.com/code4lib@listserv.nd.edu/msg04422.html
A standard nobody will notice ... for good reason.
Rob
On Tue, 2009-04-07 at 18:24 +0100, Eric Lease Morgan wrote:
> On Apr 7, 2009, at 1:15 PM, Karen Coyle wrote:
>
>
On Tue, Apr 7, 2009 at 1:24 PM, Eric Lease Morgan wrote:
> Listen... What you hear from over here is the sound of a very heavy sigh
> coming from a computer type who really wants to help improve the way library
> data is used in a networked environment, but they can't convince their own
> to modi
And what you hear over here is a plea to not give up on catalogers.
Some are beyond ready to move from text to data. Hiding the data view
-- do you mean making it look like marc? -- sounds pretty awful.
Catalogers who are on board are trapped by the way sharing currently
works, i.e. record s
Well, and then you have the XOBIS work from Stanford that ksclarke was
involved with.
Roy
On 4/7/09 4/7/09 10:41 AM, "David Fiander" wrote:
> On Tue, Apr 7, 2009 at 1:24 PM, Eric Lease Morgan wrote:
>> Listen... What you hear from over here is the sound of a very heavy sigh
>> coming from a
Karen, thanks for this summary of the process. It's pretty
disheartening, sadly.
I got 'uri' wrong, btw, it's "Universal Resource Locator'
-
http://RDVocab.info/Elements/uniformResourceLocator";>
Uniform resource locator
The address of a remote access resource.
http://RDVocab.info/Element
Roy,
That's true. Unfortunately, I missed Kevin's talk at Access '02 in
Windsor, and since I wrote the first of those two papers I've mostly
been out of the loop, since it's not my area any more.
- David
On Tue, Apr 7, 2009 at 1:48 PM, Roy Tennant wrote:
> Well, and then you have the XOBIS work
It's not off-topic, at least I don't think so.
And I don't think anybody is asking to give up on catalogers. Just
like I don't think anybody would want the technologists to describe
the materials, I think the problem is that the catalogers tried to
apply their idea of a data model into tangible t
On Tue, Apr 7, 2009 at 1:44 PM, Anna Headley wrote:
> And what you hear over here is a plea to not give up on catalogers. Some
> are beyond ready to move from text to data. Hiding the data view -- do you
> mean making it look like marc? -- sounds pretty awful. Catalogers who are
> on board are
Also back to the original question, what is an ILS in the first place?
The discussion has focused on bibliographic records, but that's just one part
of what's in the ILS in use at the library where I work. I see one of the big
problems with current ILSs being not so much the ILS per se, but li
Well, there's the project by Alistair Miles that Karen alluded to earlier:
http://code.google.com/p/code4rda
The goals of this project are, in my mind, crucial in moving forward,
since it's taking our existing corpus of records and turning them into
RDA/RDF. Not only is it a good proof of concep
Which is why the interface specifications are at least as important,
if not more important, as the specs for each of the modules that you
enumerated. If the interfaces are well-defined, then the components
can be designed and developed with a minimum of further interactions
among developers. In fac
But the first one to take this on has no one to grab from. The sharing
argument may be a red herring in that the problem, from some
perspectives, isn't so much about sharing one's own work -- it's more
about using others' work. Or is there already a community of people
doing something like wh
Ross Singer wrote:
Well, there's the project by Alistair Miles that Karen alluded to earlier:
http://code.google.com/p/code4rda
The goals of this project are, in my mind, crucial in moving forward,
since it's taking our existing corpus of records and turning them into
RDA/RDF. Not only is it a
*** Please disseminate widely to students at your institution ***
CYBERINFRASTRUCTURE SUMMER INTERNSHIPS 2009 -
REMINDER: Student Application Deadline is April 13, 2009
http://hackathon.nescent.org/
Cyberinfrastructure_Summer_Traineeships_2009
Summer training internships are
no, that's not at all what it implies. the ofi/name identifiers were
minted as identifiers for namespaces of indentifiers, not as a wrapper
scheme for the identifiers themselves. Yes, it's a bit TOO meta, but
they can be safely ignored unless a new profile is desired.
On Apr 5, 2009, at 10
An interesting thread! It will take me a while for me to digest the ideas.
What I had in mind for something different is this: Think of a single database
of only associations between objects, and nothing more than that. Objects
defined in this database can reference any and all other objects
21 matches
Mail list logo
