Easy book citations

On 7/30/06, Tantek Çelik <tantekcs.stanford.edu> wrote:

> On 7/30/06 7:59 AM, "Fred Stutzman"
<fredmetalab.unc.edu> wrote:
>
> > I think microformat citations are a great idea.
>
> Hi Fred and thanks!
>
>
> > The good news is the hard
> > work has already been done for us.
> >
> > The .bib citation format is a flexible, open, and
widely used bibliographic
> > format.
>
> <snip>
>
> > I believe our task could be as simple as
microformatting the bib format.
>
> If the bib format was the overwhelmingly dominant
bibliographic/citation
> format, it could be that simple.  But it is not.  It is
one of many formats
> in wide use.

Correct, and it frustrates me to no end whenever some BibTeX
user pops
up and says this. It's just not true. Moreover, it's just
a bad model.

> The last time the "which format is newest / most
widely in use / most
> interoperable" questions were asked, I believe
OpenURL was the answer.  I
> could be mistaken, I've only been on the periphery of
the citation
> microformat work and there are several others here who
are much more
> familiar with the state of the work.

I think the place where we were heading -- we meaning
collective
consensus informed by tons of research and practical
implementation
experience -- is some standard properties like:

contributors (reusing hcard for the markup)
====================================
author
editor
translator
publisher

dates
=====
date
accessed

locator numbers
=======
volume
issue
document
page

titles
====
title
short-title
translated-title

I've long been arguing we need some relational --
dcterms:isPartOf
like -- structure, but in my more recent work on my citation
style
language (and a few different software implementations of
it,
includiing one a guy is writng in Javascript for a
forthcoming Firefox
extension *), I've come to the conclusion tha the only
critical
structures that need some relational sugar are titles.
Allowing <span
class="title series">Series
Title</span> keeps things simple while
allowing a lot of flexibilty.

It would also make sense to allow them on contributors, so
that you
easily get series editors and such.

Bruce

* <http://netapps.muohio.edu/bl
ogs/darcusb/darcusb/archives/2006/07/29/csl-progress>
_______________________________________________
microformats-discuss mailing list
microformats-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss

On Sun, 30 Jul 2006, Bruce D'Arcus wrote:

>> If the bib format was the overwhelmingly dominant
bibliographic/citation
>> format, it could be that simple.  But it is not. 
It is one of many formats
>> in wide use.
>
> Correct, and it frustrates me to no end whenever some
BibTeX user pops
> up and says this. It's just not true. Moreover, it's
just a bad model.

Well, of course it isn't the overwhelmingly dominant
bibliographic/citation 
format - but most of these citation formats are deployed
largely for 
machine-machine utilization (Z39.80 for example).  I'm not
going to stand 
up here and defend bib as perfect, but I will stand up and
defend it as 
adopted.

The simple fact of the matter is *many,many* vendors support
export and 
ingest of bib format citations.  In fact, unless you want to
use 
RefWorks and a few other smaller, proprietary citation
managers, bib is the 
only open game.

Of course, we can dream up blue-sky scenarios on how to make
a better 
citation format.  I'm sure we can do better.  But if we do,
we miss the 
boat and lose the collective value of all the software that
would natively 
support the format.

Anyway, I'll be happy to fill out the wiki with software
that supports bib.

Thanks,
Fred




>
>> The last time the "which format is newest /
most widely in use / most
>> interoperable" questions were asked, I
believe OpenURL was the answer.  I
>> could be mistaken, I've only been on the periphery
of the citation
>> microformat work and there are several others here
who are much more
>> familiar with the state of the work.
>
> I think the place where we were heading -- we meaning
collective
> consensus informed by tons of research and practical
implementation
> experience -- is some standard properties like:
>
> contributors (reusing hcard for the markup)
> ====================================
> author
> editor
> translator
> publisher
>
> dates
> =====
> date
> accessed
>
> locator numbers
> =======
> volume
> issue
> document
> page
>
> titles
> ====
> title
> short-title
> translated-title
>
> I've long been arguing we need some relational --
dcterms:isPartOf
> like -- structure, but in my more recent work on my
citation style
> language (and a few different software implementations
of it,
> includiing one a guy is writng in Javascript for a
forthcoming Firefox
> extension *), I've come to the conclusion tha the only
critical
> structures that need some relational sugar are titles.
Allowing <span
> class="title series">Series
Title</span> keeps things simple while
> allowing a lot of flexibilty.
>
> It would also make sense to allow them on contributors,
so that you
> easily get series editors and such.
>
> Bruce
>
> * 
> <http://netapps.muohio.edu/bl
ogs/darcusb/darcusb/archives/2006/07/29/csl-progress>
> _______________________________________________
> microformats-discuss mailing list
> microformats-discussmicroformats.org
> http://microformats.org/mailman/listinfo/microforma
ts-discuss
>

-- 
Fred Stutzman
claimID.com
919-260-8508
AIM: chimprawk

_______________________________________________
microformats-discuss mailing list
microformats-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss

On 7/30/06, Fred Stutzman <fredmetalab.unc.edu> wrote:

> Well, of course it isn't the overwhelmingly dominant
bibliographic/citation
> format

It's not even close. If you ask 100 people in my field
about BibTeX,
my guess is at least 90 of them of them won't even know
what you're
talking about. Of course, a lot of them probbaly manually
author their
bibliographies (!), but still RIS and Endnote are perhaps
even more
widely supported formats for personal reference management.
Both of
those formats are based on a more general three level model.

> Of course, we can dream up blue-sky scenarios on how to
make a better
> citation format.  I'm sure we can do better.  But if
we do, we miss the
> boat and lose the collective value of all the software
that would natively
> support the format.

Regardless of the end result, you will need software to
convert from
legacy formats into and out of hCite. There is no way around
that.

I've done enough work on this stuff -- and worked with
other
developers; people like Chris Putnam on his excellent
bibutils
converion tools -- to tell you that it's pretty easy to
design a a
good format that will be easy to use, extend, and process.
Nothing
"blue sky" about it. And it won't be hard to
convert into and out of
BibTeX either (except, of course, where BibTeX's limited
data
structure gets in the way).

But if you follow the BibTeX way strictly (where all
properties are
single values) you will end up with an hCite tha is
liimited, and
akward to extend. Every time someone needs to represent a
different
kind of resource, they'll have to go through some
complicated
community consensus process just to get their new ttitle,
etc.
propreties authorized.

There really is a better way.

Bruce
_______________________________________________
microformats-discuss mailing list
microformats-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss

On 7/30/06, Bruce D'Arcus <bdarcus.listsgmail.com> wrote:

> I've done enough work on this stuff -- and worked with
other
> developers; people like Chris Putnam on his excellent
bibutils
> converion tools -- to tell you that it's pretty easy
to design a a
> good format that will be easy to use, extend, and
process. Nothing
> "blue sky" about it. And it won't be hard
to convert into and out of
> BibTeX either (except, of course, where BibTeX's
limited data
> structure gets in the way).

Just to illustrate, a simple book encoding may have these
properties:

author
editor
translator
publilsher
title
date
uid (for isbns and such)

The first four reuse hCard.

All of those properties (except, I guess, uid, author, and
translator)
could also include an additional class attribute to be able
to capture
things like series editors and titles; e.g.:

    <span class="series title">Series
Title</span>

Is there really any reason why that would be a problem? 
It's simple,
it's easy to convert to BibTeX and other formats, and it's
flexible.

Bruce
_______________________________________________
microformats-discuss mailing list
microformats-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss

Bruce D'Arcus:
> But if you follow the BibTeX way strictly (where all
properties are
> single values) you will end up with an hCite tha is
liimited, and
> akward to extend. Every time someone needs to represent
a different
> kind of resource, they'll have to go through some
complicated
> community consensus process just to get their new
ttitle, etc.
> propreties authorized.
 
That sounds like an excellent way to discourage trivial
accretions - people
would only go through the process of extending the spec if
they really, really
needed it. This means you can start with something
relatively simple and easy
to get consensus on, and work from there.

What's the down-side again?

-- 
<dhd> even though I know what a 'one time pad' is,
it still sounds like
a feminine hygiene product.
_______________________________________________
microformats-discuss mailing list
microformats-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss

On Sun, 30 Jul 2006, Bruce D'Arcus wrote:

> On 7/30/06, Fred Stutzman <fredmetalab.unc.edu> wrote:
>
>> Well, of course it isn't the overwhelmingly
dominant bibliographic/citation
>> format
>
> It's not even close. If you ask 100 people in my field
about BibTeX,
> my guess is at least 90 of them of them won't even
know what you're
> talking about. Of course, a lot of them probbaly
manually author their
> bibliographies (!), but still RIS and Endnote are
perhaps even more
> widely supported formats for personal reference
management. Both of
> those formats are based on a more general three level
model.

I think this misses the point.  At the consumer level, the
citation format 
should be transaprent - they should not know what type of
citaiton they are 
authoring (do most people understand the RefWorks citiation
format? No).

The key is that many systems - web, desktop and
machine-to-machine have 
adopted this format.  It will be much easier for CiteULike,
CiteSeer, 
Connotea etc to implement with what they already have.

>
>> Of course, we can dream up blue-sky scenarios on
how to make a better
>> citation format.  I'm sure we can do better.  But
if we do, we miss the
>> boat and lose the collective value of all the
software that would natively
>> support the format.
>
> Regardless of the end result, you will need software to
convert from
> legacy formats into and out of hCite. There is no way
around that.
>
> I've done enough work on this stuff -- and worked with
other
> developers; people like Chris Putnam on his excellent
bibutils
> converion tools -- to tell you that it's pretty easy
to design a a
> good format that will be easy to use, extend, and
process. Nothing
> "blue sky" about it. And it won't be hard
to convert into and out of
> BibTeX either (except, of course, where BibTeX's
limited data
> structure gets in the way).

Indeed, it is easy to design a new standard.  It is not easy
to get people 
to adopt that new standard.

>
> But if you follow the BibTeX way strictly (where all
properties are
> single values) you will end up with an hCite tha is
liimited, and
> akward to extend. Every time someone needs to represent
a different
> kind of resource, they'll have to go through some
complicated
> community consensus process just to get their new
ttitle, etc.
> propreties authorized.

There is no requirement to follow bibtex strictly.  It seems
very 
reasonable to start with an existing standard and iterate
upon it.  There's 
no reason why we shouldn't be making it better.

>
> There really is a better way.
>
> Bruce
> _______________________________________________
> microformats-discuss mailing list
> microformats-discussmicroformats.org
> http://microformats.org/mailman/listinfo/microforma
ts-discuss
>

-- 
Fred Stutzman
claimID.com
919-260-8508
AIM: chimprawk

_______________________________________________
microformats-discuss mailing list
microformats-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss

On 7/30/06, Simon Cozens <simonsimon-cozens.org> wrote:

> That sounds like an excellent way to discourage trivial
accretions - people
> would only go through the process of extending the spec
if they really, really
> needed it. This means you can start with something
relatively simple and easy
> to get consensus on, and work from there.
>
> What's the down-side again?

The downside is that what you consider trivial I consider
essential
(say archival documents), and no doubt vice versa (I really
couldn't
care less about conference proceedings or patents, but you
may cite
them all the time).  Moreover, there is no objective methord
to fairly
measure this.

I, however, bet we all can agree that "title" is
an essential property.

The practical reality is that these fora are (aside frm a
few
exceptions) dominated by people from technical backgrounds,
who
typically do not understand the citation needs of fields
like law and
the humanities, and often do not want to try to understand.

What is thus "trivial" or falls in the "20
%" category, I would
submit, is heavily-biased. And my experience is that bias is
self-reinforcing. A lot of people still manually code
citations, and
it's because the tools they have tried, and the data models
they are
based on, don't fit their needs. And this is so because the
people
designing them didn't consider them. Those people don't
subsribe to
tech mailing lists or bother with wikis.

There are different ways to address this issue (containment,
doubling
class atttributes, using generic properties like
"container-title",
and "collection-title", etc.), but I really
think it's critical to get
this bit right.

Bruce
_______________________________________________
microformats-discuss mailing list
microformats-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss