Re: [uf-discuss] Citation: next steps?
On 9/22/06, Michael McCracken [EMAIL PROTECTED] wrote: That is the most straightforward way, yes. The problem I have with it is the repeated role term will be displayed for every contributor, and will likely end up being more hidden data. No, I'm saying have two main terms: creator and contributor. Only add a role when it actually needs to be displayed (which is not the case for an author). Using creator for author is fine. Bruce ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Citation: next steps?
Back to the citation fray: I think the ROLE attribute of vcard means something different than what you guys were describing with a role. You were saying role = what this person's relationship to the cited work is I dug around for the vcard rfc, which says that the ROLE vcard attribute is based on job description, so for the hcard, role = what this person does for a living. It is also supposedly intended to draw from a list of roles described as business category or occupation, in (ANSI?) X.509, which I can't find online. I can easily imagine wanting the vcard role in addition to the citation role - for instance, on my CV page I want to have a single hcard for myself with the role graduate student, while my role on each paper I cite in my references list may be different. Unfortunately I don't have an answer for how I think we should mark up roles. I agree that having a creator,role,value structure is nice, but I can't think of a good way to mark it up. There's nothing I know of that's marking things up like that out there on the web, and unless it's a coincidence, all discussion on this topic stopped once we got onto the role idea. I stopped because I was waiting for an idea to come to me about how to write that in XHTML. The only ideas I have come up with involve hiding the span containing the role with CSS. If we just have a single creator class (and a small number of other role classes), we can do this: span class=vcard creator /*my vcard*//span with roles, we could do this: span class=vcardspan class=roleauthor/span/*my vcard info*//span but that clashes with the vcard 'role' attribute, which may be OK but may not. If we are parsing this, do we have to treat hcards that are in a citation differently from hcards elsewhere? (In order to avoid losing the 'role' element to the hcard, or to first look for a 'citerole' element or something before passing it off to an hcard parser?) I'd like to avoid that extra complexity. Does anyone have a good suggestion for marking this up? I'm not sure if I'm missing an obvious good solution here. Thanks, -mike On 9/1/06, Bruce D'Arcus [EMAIL PROTECTED] wrote: On 8/31/06, Timothy Gambell [EMAIL PROTECTED] wrote: [...] hCard has a role term, though I don't know if it is consistent with this? Certainly an appealing possibility. Unless the proprietors of hCard object, I think we should use it. Do you agree? Well, the problem with role to me is the semantics are unclear (a role isn't really a property of a person, but a relation between a person and some other thing). But I really have no strong opinion. It is; really more a producer. The DC group considers it a contributor, and has wanted to get rid of dc:publisher and use that instead. Dropping publisher and marking it up as a contributor with a role of publisher sounds like a good proposal to me. I'm not saying to drop it really; just giving an example of how to think about it. Bruce ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss -- Michael McCracken UCSD CSE PhD Candidate research: http://www.cse.ucsd.edu/~mmccrack/ misc: http://michael-mccracken.net/wp/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Citation: next steps?
On 8/31/06, Timothy Gambell [EMAIL PROTECTED] wrote: [...] hCard has a role term, though I don't know if it is consistent with this? Certainly an appealing possibility. Unless the proprietors of hCard object, I think we should use it. Do you agree? Well, the problem with role to me is the semantics are unclear (a role isn't really a property of a person, but a relation between a person and some other thing). But I really have no strong opinion. It is; really more a producer. The DC group considers it a contributor, and has wanted to get rid of dc:publisher and use that instead. Dropping publisher and marking it up as a contributor with a role of publisher sounds like a good proposal to me. I'm not saying to drop it really; just giving an example of how to think about it. Bruce ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Citation: next steps?
Bruce, thanks for clearing that up.
On 8/29/06, Bruce D'Arcus [EMAIL PROTECTED] wrote:
Mike,
On 8/29/06, Michael McCracken [EMAIL PROTECTED] 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=titleChapter Title/span
div class=hcite container
span class=titleBook 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=typeBook Chapter/span
span class=titleChapter Title/span
div class=hcite container
span class=titleBook 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/
___
microformats-discuss mailing list
Re: [uf-discuss] Citation: next steps?
On 8/30/06, Michael McCracken [EMAIL PROTECTED] wrote: [... snip ...] 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. A reasonable argument; I have no problem with that. 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. Maybe the duration requirement can be dropped? In any case, conferences and hearings and such have titles, dates (usually contiguous start/end but soemtimes not), and usually sponsors. Bruce ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Citation: next steps?
On 8/30/06 11:29 AM, Bruce D'Arcus [EMAIL PROTECTED] wrote: 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. Maybe the duration requirement can be dropped? This seems both reasonable, and reflective of existing practice in event listings (and even hCalendar usage in the wild). Many hCalendar events in the wild that I have seen (anecdotal) lack dtend/duration. Most seem to have summary, dtstart, url. Would it be useful to come up with implied durations for this case? In any case, conferences and hearings and such have titles, dates (usually contiguous start/end but soemtimes not), and usually sponsors. Yes. I think this could make a lot of sense, plus it affords the opportunity (and natural tendency?) to link to a page which more thoroughly describes the conference/hearing, more and more of which actually do have their own event pages if not whole sites. Thanks, Tantek ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Citation: next steps?
On Aug 30, 2006, at 12:42 PM, Michael McCracken wrote: 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. A modular system with hDC broken out does seem a little complex. I'm happy to borrow from hCite, and I'd hope that hCite would be designed to have pieces reused. I say that because I'm interested in using hCite to describe works of art. From my point of view, class names based on DC's very general terms seem like a good choice, class names based on a medium specific citation format like BibTeX seem less good. For example, BibTeX's author field implies the medium of the cited work (if it has an author, it must be text). This makes it difficult to reuse terminology: what if I'm talking about something that had a painter, not an author? Using a more general term, like DC's creator get's the same work done, and is more easily reused: it can be applied to text, paintings, websites, and so on. It would be great, then, if hCite were to be a superset of DC, using more medium specific terms from something like BibTeX only when no adequate alternative existed in DC. This way we sidestep the distraction of creating a DC format, but get the benefit of generic terms in the larger microformats class name pool. Thanks, Tim ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Citation: next steps?
On 8/30/06, Bruce D'Arcus [EMAIL PROTECTED] wrote: On 8/30/06, Timothy Gambell [EMAIL PROTECTED] wrote: For example, BibTeX's author field implies the medium of the cited work (if it has an author, it must be text). This makes it difficult to reuse terminology: what if I'm talking about something that had a painter, not an author? Using a more general term, like DC's creator get's the same work done, and is more easily reused: it can be applied to text, paintings, websites, and so on. I agree. I'd use creator and then also add author, editor and translator, since those three are widely used in citations, and it's important at least to distinguish the latter two (non-creator) roles from creator/author. In fact, I'd be fine with dropping author altogether; it's not strictly necessary. Yes, I think 'creator' covers 'author' and 'painter' (and 'vocalist', 'sculptor', 'singer', etc) perfectly well, and seems like this might be a useful tradeoff between being able to describe a variety of things without an explosion of class names and actually following the current practices on the web. Current practice seems to overwhelmingly use 'author' - every example we have uses 'author' except for the Oxford U. Press (USA), using 'byline'. So we may need more examples :) I think that given that tradeoff, the set of 'creator', 'editor', and 'translator' are reasonable 80% (probably 90%) choices. We need something like 'editor', and IMO, DC's 'contributor' is way too vague to be useful in comparison. Furthermore, I think none of those should be required, since I commonly see things with no author/editor/etc... Thanks, -mike -- Michael McCracken UCSD CSE PhD Candidate research: http://www.cse.ucsd.edu/~mmccrack/ misc: http://michael-mccracken.net/wp/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Citation: next steps?
Hi, aside from adding a few good examples of existing formats, it looks like there hasn't been any movement toward the Aug 30 deadline for hCite 0.1. Should we reschedule the goal? Also, what is the immediate next step on the path to a recommendation? Do we need to clarify the existing research on the wiki? Is anyone waiting for an answer or agreement before moving forward? Thanks, -mike -- Michael McCracken UCSD CSE PhD Candidate research: http://www.cse.ucsd.edu/~mmccrack/ misc: http://michael-mccracken.net/wp/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Citation: next steps?
Hello Mike, thanks for bringing this up. I spent a good portion of the weekend looking at my earlier straw proposal. I started to create an XMDP file and took the examples listed on the wiki and attempted to mark them-up with the citation microformat. This would help to find any deficiencies. The 3 main points i came across so far are: 1) IDENTIFIERS 2) FORMAT TYPES 3) NESTING 1) In hCard/hCalendar there is a UID field. Added with URL it makes for a great unique identifier. There are loads of other identifers besides URL, ISBN, LOC call number, SKU, ISSN, etc. Many of these are unique in their domain, but not globally unique. So how to they get marked-up? Much like the hCard TEL/ADR properties, we can use something like: div class=uidspan class=typeISBN/span: span class=value123456/span/div This makes the encoding the most extensible... if we start use class=isbn then it is an enumerated list, with class=type it is open ended. 2) I keep mis-using format, format is the medium - hardback, softback. The TYPE (there probably is a better word - container?) is book, article, conference, manifesto, etc. Much like the identifers we can make an enumerated list of values, class=book, class=article, but that boxes us in, whereas something like: span class=typearticle/span leaves things more open. 3) Nesting citation data in a citation. The ability to nest the same microformat inside itself is something that other microformats don't explicitly handle. The two options are: i) Using class=book div class=hcite div class=book span class=fnBook Title/span div class=chapter span class=fnChapter Title/span /div /div /div This makes things easy to nest and to figure out exactly what is associated with what, but the downside is that we have enumerated lists of values for the class properties. ii) using the TYPE for book div class=hcite div class=typebook/div span class=fnBook Title/span div class=typechapter/div span class=fnChapter Title/span /div now the class=fn is not nested inside the class=book or class=chapter so there would have to be some other mechanism to associate the data with the type. This is just a brief summary of the outstanding issues. I have been quite busy with other things, and i'm not sure exactly how or where to proceed? I have a feeling the citation discussion is pretty heavy and i don't want to waste people's time with all the back and forth messages on the mailing list - it is high traffic enough already... the wiki is nice, but not everyone keeps a close eye on it... IRC is another option. We've done 'meet-ups' in the past and they worked fairly well? so i'll leave it up to others on where/how we should proceed. maybe like the REST mailing list we need to spin off a temporary citations mailing list? (although that means YAML, Yet Another Mailing List) I am still working on exactly WHAT we are proceeding on. I'll be offline for the next few days due to traveling, so a deadline of the 30th is probably not realistic. I am certainly open to suggestions. -brian On 8/29/06, Michael McCracken [EMAIL PROTECTED] wrote: Hi, aside from adding a few good examples of existing formats, it looks like there hasn't been any movement toward the Aug 30 deadline for hCite 0.1. Should we reschedule the goal? Also, what is the immediate next step on the path to a recommendation? Do we need to clarify the existing research on the wiki? Is anyone waiting for an answer or agreement before moving forward? Thanks, -mike -- Michael McCracken UCSD CSE PhD Candidate research: http://www.cse.ucsd.edu/~mmccrack/ misc: http://michael-mccracken.net/wp/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss -- brian suda http://suda.co.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Citation: next steps?
On 8/29/06, Tantek Çelik [EMAIL PROTECTED] wrote: This is a good summary to date and deserving of being captured on the citation-brainstorming page. I agree. I think the fundmental last hump to get over is the choice between a largely monolithic and flat BibTeX-like approach, and a more modular and relational DC-like approach. The choice is crtiical because it has significant implications to the flexibility of hCite. On the nesting example, though, this would be the more typical case (chapter in a book, rather than vice versa), and one could forego typing: div class=hcite div class=chapter span class=titleChapter Title/span div class=isPartOf span class=titleBook Title/span /div /div /div To me typing is nice, but not critical, paricularly if the rest of the data is sound. Bruce ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Citation: next steps?
Bruce, do you have a canonical example that gets at exactly what you
mean by monolithic and flat vs. modular and relational? I think I used
to understand what you meant by those, but I want to be sure. Please
bear with me on this, I know I asked you a similar question a while
back, but I think that what you're asking for is actually not as
complicated as it may sound.
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}
@book{bookkey,
title=book}
@article{articlekey,
title=article}
etc...
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.
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?
Thanks,
-mike
On 8/29/06, Bruce D'Arcus [EMAIL PROTECTED] wrote:
On 8/29/06, Tantek Çelik [EMAIL PROTECTED] wrote:
This is a good summary to date and deserving of being captured on the
citation-brainstorming page.
I agree. I think the fundmental last hump to get over is the choice
between a largely monolithic and flat BibTeX-like approach, and a more
modular and relational DC-like approach. The choice is crtiical
because it has significant implications to the flexibility of hCite.
On the nesting example, though, this would be the more typical case
(chapter in a book, rather than vice versa), and one could forego
typing:
div class=hcite
div class=chapter
span class=titleChapter Title/span
div class=isPartOf
span class=titleBook Title/span
/div
/div
/div
To me typing is nice, but not critical, paricularly if the rest of the
data is sound.
Bruce
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss
--
Michael McCracken
UCSD CSE PhD Candidate
research: http://www.cse.ucsd.edu/~mmccrack/
misc: http://michael-mccracken.net/wp/
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss
