[uf-discuss] Citation: next steps?

[Michael McCracken]

Bruce, thanks for clearing that up.

On 8/29/06, Bruce D'Arcus <bdarcus.lists at gmail.com> wrote:
> Mike,
>
> On 8/29/06, Michael McCracken <michael.mccracken at gmail.com> wrote:
>
> > Do you just mean the ability to mark up a relation between two citation items?
> >
> > For instance, if BibTeX had a convention of things like this:
> >
> > @inbook{chapterkey,
> > title="chapter 1",
> > cites="articlekey,article2key,...",
> > partof="bookkey"}
>
> [... snip ...]
>
> > Would you consider that relational? That kind of thing fulfills what I
> > think you want, but I'd like to know if you're talking about something
> > else too.
>
> Yes, I'd frankly forgotten about macros, but they achieve the same
> thing I am after.

I think you might actually be thinking of crossref here, not bibtex macros.

Macros are just string substitution - they do this:

@string{acm = "Association for Computing Machinery"}
@misc{k, title="t", publisher= acm}
(note the lack of quotes around acm)

while crossref allows (single) inheritance of fields from one item to another:

@book{k1, editor= "foo", title = "book"}

@inbook{k2, author="bar", chaptertitle = "chapter", crossref="k1"}

then the chapter item 'k2' is typset with title=book and chaptertitle=chapter.

> I was more referring to the standard BibTeX fields, where you end up
> with stuff like:
>
>     journal="ABC Journal"
>
> ...or:
>
>     book="Book Title"
>
> This is what I object to as a basis for hCite. It effectively means
> that whenever you need to support a new kind of resource, you need to
> invent a new field name to describe the same thing: a related title.

OK, I understand. And I agree it's a bad thing - I am expecting the
microformat to deal with this by nesting items, but in a slightly
different way from what either you or Brian just mentioned. Here is
what I was expecting:

<div class="hcite">
  <span class="title">Chapter Title</span>
  <div class="hcite container">
     <span class="title">Book Title</span>
  </div>
</div>

I like this option because we aren't requiring a type, we don't need
to define enumerated lists of properties, and it's still clear what
the association is.

We could try the following for the optional type element:

<div class="hcite">
<span class="type">Book Chapter</span>
  <span class="title">Chapter Title</span>
  <div class="hcite container">
     <span class="title">Book Title</span>
  </div>
</div>

And although it looks a little awkward, it works. I'm not sure this is
the best way to do it, but I do think that types should be available,
but optional.

As for what happens if the type isn't in there in this case, I suspect
that most citation formatting solutions would still generate something
reasonable from this data because it is clear it is something
contained by something, and there's a decent chance of finding a good
default for that.

BTW, I used title here because 'fn' just seems awkward for a title,
but I'm not very concerned about it.

> > ISTR that you've also described BibTeX's model as flat because author
> > names in BibTeX are somewhat underspecified, but since a citation
> > microformat will use hCard, that's not an issue here, right?
>
> Right. I think hCard is nice improvement on the BibTeX contributor
> representation.
>
> In terms of "modular" I am referring to the fact that there is very
> little that is specific to citation metadata. Properties like title,
> subject, format, etc. can be used to describe a whole range of content
> beyond citations.
>
> It therefore seems to be more sensible -- both generally, as well as
> WRT to microformat practice -- to isolate the general pieces and give
> them a name (like, for example, hDC), and end up with an hCite format
> that mostly borrows from those more general formats (hDC, hCard, and
> maybe hCal).
>
> But this is less of a concern for me. It wouldn't be the end of the
> world for others to borrow from hCite.

I agree, it seems like microformat practice would have us borrow as
much as possible from elsewhere. I think modular is a pretty
overloaded term, and I was thinking in terms of software modularity,
which didn't make a lot of sense.

I'm not convinced that a formalized Dublin Core microformat class set
is necessary for a good citation microformat, and I do think it'd be a
distraction to getting the main goal completed.

I'd like to see a citation microformat use hCard for people,
certainly. The more rich information we get about people from a
citation, the better.

As for using hCalendar, I think that would be great to mark up
conferences, meetings, etc, in citations, but I don't think a citation
microformat should *require* it. According to the hcard-authoring wiki
page, a minimal hCalendar requires a summary, start date and end date
or duration. I almost never see end dates or durations being published
for citations in current practice, and I think requiring a valid
hCalendar would make it harder for publishers to adopt the citation
microformat.

-mike

-- 
Michael McCracken
UCSD CSE PhD Candidate
research: http://www.cse.ucsd.edu/~mmccrack/
misc: http://michael-mccracken.net/wp/