Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats
On 12/7/06, Ryan King [EMAIL PROTECTED] wrote: ... Also, I'm not sure how 'people not getting their pet properties' is a problem specific to microformats. True. It doesn't mean it has to repeat the same mistake though. I would certainly hope the HTML 5 effort would be open minded about learning from all of the efforts in this space. HTML 5 has profile URIs and the specification is much more clear as to how they are to be used (thanks to Tantek bugging Hixie about that). I think HTML 5's current extension methods (profiles, rel and class) are sufficient. Let's review: Microformts are a clever set of conventions to reuse existing HTML attributes to encode some sort of structured meaning. However, using title to encode machine-readable content is pretty much a hack. Title, after all, is really for human readable labels. Likewise, using class to indicate both properties and, um, class, is also a hack. These hacks are no doubt necessary and practical in the context of current HTML and I really have no problem with it in that context, but it's precseily why there can be no generic microformat parser. In a world in which one CAN consider adding alternative attributes (HTML 5, etc.), it makes no sense to me one would simply say no. Bruce ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: class=hack? Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats
On 12/8/06, Dr. Ernie Prabhakar [EMAIL PROTECTED] wrote: On Dec 8, 2006, at 4:04 AM, Bruce D'Arcus wrote: Likewise, using class to indicate both properties and, um, class, is also a hack. I think that's probably where we part company. I suspect most of us here consider the use of HTML class for semantic information fully in line with the both the letter and spirit of the spec, and thus an entirely natural usage. My point, Ernie, is there's no obvious way to map it onto a model. I don't think that's such a controversial thing to say. We've got tables and columns (RDBMSes), resources and properties (RDF), objects and attributes (oo). Class and ... ? Bruce ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats
On 12/7/06, Ryan King [EMAIL PROTECTED] wrote: ... The RDF dream of having a generic parser and model has yet to win on the open web. I'm more than happy to let the market decide whether it's more value to have formats that are easy to publish, or those that are easy to parse (I'm sure you can guess which side I'll take). Why does this need to be an either/or choice? Why must ease-of-authoring trade-off generality here? ... Also, I'm not sure how 'people not getting their pet properties' is a problem specific to microformats. True. It doesn't mean it has to repeat the same mistake though. I would certainly hope the HTML 5 effort would be open minded about learning from all of the efforts in this space. Bruce ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats
On 12/5/06, Scott Reynen [EMAIL PROTECTED] wrote: ... In HTML or JSON, new formats need new parsers, which must be written by someone. Exactly. The point is if you have a generic model you have a generic parser. Elias is coming from an RDF background, and microformats simply aren't RDF, and they never will be. And that's a good thing. If what you want is RDF, just use RDF. The issue isn't really microformats vs. RDF (except as RDF provides a model), but microformats vs. RDFa. Both microformats and RDFa are addressing the exact same use cases and requirements (augmenting visible content with structured data). RDFa includes namespacing, the lack of which is already a problem in microformats (witness hCite and the serious awkwardness that title will be indicate using fn), and which will grow over time as more and more people want to mark up their content. Moreover, the need to write dedicate code for each new microformat will also present serious scalability problems. Finally, that there's no model at the heart of microformats with clear extension rules means that the vaunted social process here is a mess. It's all centralized, and people get frustrated when their pet property isn't included because they know what that means: the tools written for the blessed microformats won't see them. So while it might be comforting to dismiss RDFa and it's not our problem, I don't think it's good strategy. Bruce ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats
On 12/5/06, Mike Schinkel [EMAIL PROTECTED] wrote: For those on this list who are not following [whatwg], here is an interesting thread about inability to use Microformats: http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2006-December/00 8462.html I wonder if his issues can be addressed? I think the only way it can be addressed is with some effort to harmonize microformats and RDFa, which is not going to happen for what seem to me largely political reasons. The fact that we can't have a title property in hCite is already evidence of the practical problems that will result without such an effort. FWIW. Elias is an engineer (who writes code; rep sounds to me more marketing, but maybe tha's just me). Bruce ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: Re: [uf-discuss] [citation] url field
On 11/30/06, Michael McCracken [EMAIL PROTECTED] wrote: If you mean why not call it URI?, Yeah, that's what I mean, and worried about collapsing the notion of URI as a name, and URL as a location. I'm skeptical we can rely on parsing a URL fo extracting a DOI/ISBN/etc. Bruce ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] [citation] url field
On 11/30/06, Michael McCracken [EMAIL PROTECTED] wrote: I also suggest that in the case of identifiers like a DOI or ISBN which can be represented as a parameter in a link to doi.org or some other resolver, that the format encourage using a URL field for those identifiers and not include separate fields for each such identifier. In other words, I think that class=url uid is sufficient to encode DOI/ISBN/etc., and we shouldn't add a separate DOI class, a separate ISBN class, and so on. What about non-http URIs? Bruce ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Custom Fields Microformat?
On 11/25/06, Manuel Simoni [EMAIL PROTECTED] wrote: ... For example, XOXO would force implementors to adapt a list structure, which probably is too rigid for them. The hcustomfield-* classes let implementors use any layout they desire, and my examples show that the use of these three simple classes is enough to unify two major existing implementations (Wordpress and Drupal). Though the problem with the custom property-value approach is that properties then must be visible. It also seems to go against the current of current practice (where properties are encoded as meaningful class names). Bruce ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCite progress
On 11/16/06, Andy Mabbett [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED], Ross Singer [EMAIL PROTECTED] writes If you can't grab total number of pages, does your plan of absolute bird book aggregation fail miserably? I'm not sure what you think can be achieved by such an asinine comment. I'm going to challenge you here, Andy, because this is yet another time (e.g. not the first) when I think you're stepping over the line. You're being hostile, and I don't think it's appropriate for productive discussion. Bruce ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCite progress
On 11/15/06, Scott Reynen [EMAIL PROTECTED] wrote: ... If I were to quote something specific, or refer to a specific idea or statement in a journal article on page 40, I would use some variation of the following: John Doe, Lorem Ipsum Dolor, _Sit Amet_ vol. 81, no. 3 (2000), 40. If, however, I would want to refer to the entire article, I would use the following: John Doe, Lorem Ipsum Dolor, _Sit Amet_ 81, no.3 (2000), 37-65. I don't see how leaving pages as a simple string can account for this difference. I wouldn't want a parser to say that the article is only one page long, and that it exists only on page 40 of a journal. I think the idea is that the parser isn't saying much of anything about the pages, just that a given string is a textual description of them, and a human reader needs to take it from there. This is kind of tricky though. Jeremy is showing a style common in history, where citations are represented as notes. So in an author-date style, his example might be (Doe, 2000:4). A page in that context is simply not the same as a page in a full bibliographic entry. You'd have to call it cited-pages or some such. ... I'm not really sure offhand how to remedy this, but I'll certainly think about it and offer up whatever I come up with. (I've tended to do that on this list; raise questions without offering much on solutions. My apologies.) Does anyone else have thoughts about this? There are specific formatting rules for page ranges in various formal citation styles, right? Right. Are they clear and consistent enough that we can just adopt one of those for page ranges? Here's a problem: there are different algorithms to collapse page ranges. E.g. 120-129 -- 120-9. Chicago actually lists the rules. ... class=month, etc. markup. And for syntax that doesn't follow a given syntax standard, we could use abbr just like with the date syntax standard, e.g. abbr class=pages title=20-3020 to 30/abbr. +1 Bruce ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCite progress
On 11/13/06, Andy Mabbett [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED], Bruce D'Arcus [EMAIL PROTECTED] writes But citation uFs are being recommended for more than pure academic citations - in resumes, for example, where the page count is likely to be far more relevant. I seriously doubt it. That's your prerogative; but foolish. Particularly as it was mentioned just today: http://microformats.org/discuss/mail/microformats-discuss/2006-November/007103.html I fully accept the argument that hCite might be used for resumes. But that message from Ryan says nothing about page count. Bruce ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCite progress
On 11/14/06, Jeremy Boggs [EMAIL PROTECTED] wrote: On Nov 13, 2006, at 3:11 PM, Bruce D'Arcus wrote: Page count is only relevant to publishers and book stores (maybe). Page count is also important in academic and non-academic reviews of books, specifically when the review prints the information of the book in question. True; I'd forgotten about that. But it's still a fairly narrow kind of use case. Bruce ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCite progress
On 11/13/06, Brian Suda [EMAIL PROTECTED] wrote: 1) The term Pages i think that actually has two meanings which i have confused in the implied schema. The first being This book is 45 pages long which is metadata about the book, and is in the realm of media-info microformat. Then there is this sites pages 43-45 meaning a location. So now we need figure out what we are to do? Pages to indicate the length of a book should be beyond scope. It's not relevant to citations. Beyond that, there are two kinds of locators of this sort: 1) to indicate the place of an item within a larger container 2) so-called point locators which indicate specific pages/paragraphs/etc. within a cited item; typically included in citations (Doe, 1999, p12). For the best balance of simplicity and generality, I'd suggest just pages. Don't worry about start and end because, as you noted, pages can be discontinuous. 2) one of the manditory properties across several different citation formats is TYPE. Is this a Book, Journal entry, Thesis, Video, etc. Usually and enumerated list of values. The issue is that EVERYONE does it differently... And from my own experience, this is not at all easy to do. I've been talking about this issue of late with the Zotero guys, because every week people keep asking for more types on their forums. But if you just keep adding them without some kind of design logic -- and a mapping to the formatting system and its type logic -- you end up with a mess. So, I do think a list is important, but I suggest that this not be the focus for hCite 1.0, and maybe see if we can find some agreement as a separate effort. Bruce ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCite progress
On 11/13/06, Chris Messina [EMAIL PROTECTED] wrote: In terms of type... How important is that designation? If you have an open-ended list, isn't that similar to a tag or is there real consequence to its type-designation? It's very important for conversion into some formats (BibTeX, RIS, etc.), and sort of important too for formatting in the sense the there are different conventions (rules) for formatting different kinds of references. Note, though, that as someone who designed both a citation style language and code to format citations, I think sometimes people get too distracted by type. Often times, formatting rules are more about other details than type. For example, someone on the Zotero forums recently claimed edited books get formatted differently than books. Well, not really. What gets formatted differently are editors and authors (the former gets a role label added to it). Bruce ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCite progress
On 11/13/06, Scott Reynen [EMAIL PROTECTED] wrote: On Nov 13, 2006, at 12:35 PM, Bruce D'Arcus wrote: For the best balance of simplicity and generality, I'd suggest just pages. Don't worry about start and end because, as you noted, pages can be discontinuous. So what would that look like in markup for, say, pages 10-50? We don't have to list every single page, do we? Sometimes you have periodical articles that span multiple discontinuous pages, and they all get included; e.g. 1-5, 9. OTOH, legal citations typically list only the first page. Bruce ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCite progress
On 11/13/06, Andy Mabbett [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED], Bruce D'Arcus [EMAIL PROTECTED] writes Pages to indicate the length of a book should be beyond scope. It's not relevant to citations. I disagree, not least because people often cite a whole book, rather than part of it. Which is exactly why the length of the book is irrelevant. The only time you include pages in a citation is if you are referring to a section within a book (typically a chapter), and the purpose there is simply to help you find it. Page count does nothing to help you with that, and for that reason they are never included in citations in my experience. Page count is only relevant to publishers and book stores (maybe). For the best balance of simplicity and generality, I'd suggest just pages. Don't worry about start and end because, as you noted, pages can be discontinuous. But what about inter-operability with other standards? Which ones? There is no standard way to do this; some use start/end and others a single property. Bruce ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCite progress
On 11/13/06, Andy Mabbett [EMAIL PROTECTED] wrote: But citation uFs are being recommended for more than pure academic citations - in resumes, for example, where the page count is likely to be far more relevant. I seriously doubt it. I certainly wouldn't include it (and don't) in my CV. Page count is only relevant to publishers and book stores (maybe). That's an assertion for which you can provide no evidence. Likewise. Look, I don't have time to track down a heap of evidence for you; either accept my argument, or don't. ... some use start/end and others a single property. So why not allow both to be marked up? I'm really not that invested in this. I gave my suggestion for the best solution. You're entitled to your's. Either way is more-or-less fine by me. But I do feel strongly that page count is beyond scope. Do we want to then include ways to encode the length of a CD or a DVD film or an HTML document? I think not, particularly when there are more important issues to worry about. Bruce ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: Re: [uf-discuss] Apple adds support for hcard in dotmac webmail
On 10/29/06, Chris Messina [EMAIL PROTECTED] wrote: Put it this way: there's a convergence coming between OpenID, microformats (especially XFN and hcard) and being able to specify assertions about a given hcard without having all information, in my thinking, is valuable. Also been some discussion on Planet RDF about using OpenID URLs as identifier for FOAF and such (they are just URIs, after all), which I also think a good idea. ... Thoughts? In the absence of an OpenID, borrow another approach from the FOAF world: use a hash of an email address? Bruce ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Visual Art Titles Microformat Proposal
On 10/21/06, Jeremy Boggs [EMAIL PROTECTED] wrote: It sounds like this might be a good addition to the citation microformat effort [1] and related pages. [2] I think the majority of the discussion/efffort for the citation has focused on text documents, but a case could certainly be made (and one that I would support) that the citation microformat should include works of art and other visual works (photographs, sculptures). Yes. As you mention, some of the basic components (title, creator, date) are already in use in the citation microformat. Well, actually, title is not going to be included, because of the no-namespace problem. E.g. it would conflict with hCard title, which is different. But fn is essentially used to achieve the same thing (if really awkwardly). There are a few other components (medium, size, unit of size) that might not be included. Medium and/or format ought to be included in hCite, since that information typically gets included for any non-physical-text items. E.g. if you cite a film, you might include DVD. Bruce ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: Re: [uf-discuss] Citation Microformat: LazyWeb for BibTeXperts
On 10/6/06, Brian Suda [EMAIL PROTECTED] wrote: On 10/6/06, Bruce D'Arcus [EMAIL PROTECTED] wrote: Why? Seems quite awkward to me to call a title a fn. --- part of this goes back to no-namespacing in Microformats. ... OK, I see. That wall I mentioned. ... As for KEY, that is something that is NOT currently in the implied schema (again the examples might have been more PRODUCT pages rather than a bibliographic list of citations). KEY could be handled as an ID (most sites have some sort of hyperlink back to the internal reference) or as it's own class=key, but that sounds alot like IDENTIFIERS to me, and then we are back to the idea of span class=identifier span class=typeKEY/span: span class=valueSU06/span/span. Then does KEY need to be GLOBALLY unique (sounds like a URI) or just locally unique in the .BIB file (because that could be generated by the Web Service)? Yes, there is no way that the conventions of BibTeX -- conventions which preceded the web-- ought to be in any way privileged in hCite. Key is one of these. They are indeed just identifiers. Within BibTeX, keys only need to be locally unique. For reference, I use URIs to achieve the same thing in my citations, but in more robust ways. One thing I'll repeat is that not all data needs to be displayed. Bruce ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: RE: [uf-discuss] Citation Microformat: LazyWeb for BibTeXperts
On 10/6/06, Brian Suda [EMAIL PROTECTED] wrote: On 10/6/06, Joe Andrieu [EMAIL PROTECTED] wrote: I'm assuming that means it isn't included in what you've done so far. --- correct. From the examples online[1] most (if any) did not have a dateAccessed. [well one did CiteProc_XHTML_Output[2], which doesn't fall into the 80/20]. I'm not against exploring dateAccessed, there might be ways to extract an access date without actually declaring it explicitly. Run this search on Google: site:wikipedia.org accessed on It's not very precise (it probably misses some stuff), but I get over 6,800 hits; from one site! Fair to say it's pretty real world. If you are looking for the DATETIME that you viewed the article, then that could be added by the transforming application (this might be a bad idea?) and/or use the timestamp that is sent in HTTP Headers (Last-Modified date - again, maybe a bad idea?) All an access date does it authenticate a URL; it says the URL was valid on this date. URLs change, so citations REQUIRE access dates. I have never seen an exception to this rule. Whether we call it dtvalid or dtaccessed doesn't matter that much. BTW, worth looking at Zotero, which has just gone live: http://zotero.org They'll be supporting hCite once it's done. Bruce ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Re: Software Projects Description
On 10/6/06, Lachlan Hunt [EMAIL PROTECTED] wrote: One thing that would actually be very useful for users on a download page is a way to markup a check sum (commonly MD5 or SHA) and semantically associate it with the file to be downloaded. I couldn't find anything like that covered with DOAP. To quote from Edd: Specifically not in scope for the first iteration is the description of software releases. Work on this can be investigated as a follow-up initiative. http://www-128.ibm.com/developerworks/xml/library/x-osproj.html Bruce ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: Software Projects Description Re: [uf-discuss] Potential Microformats
On 10/5/06, Tantek Çelik [EMAIL PROTECTED] wrote: snip I didn't follow microformats.org process, though I do believe some of the key prerequisites have been fulfilled. This is the key. Just taking an existing format and translating them to class names is not enough - as the folks working on citations will tell you. I don't think the domains are equivalent though. Citation metadata covers a whole lot of ground (basically everything referenced on Wikipedia), and has a long legacy. Not so with project descriptions, and I think DOAP is pretty much the only game in town there (and really well designed). Bruce ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Citation Microformat: LazyWeb for BibTeXperts
On 10/5/06, Brian Suda [EMAIL PROTECTED] wrote:
I have updated my Straw proposal slightly to avoid collisions with
class values and to bring it in line with other formats (e.g. hResume,
what was 'title' is now 'fn')
Why? Seems quite awkward to me to call a title a fn.
...
Taking the implied schema, i began to create an XSLT that maps those
values to BibTeX. NOTE: this is NOT a 1:1 mapping of BibTeX, it is a
mapping of COMMON values in the wild to their BibTeX equivalents (or
atleast i think they are equivalent - some one will tell me otherwise
i'm sure). Eventually, there will be XSLTs to map between the
microformat and other citation formats through the Implied Schema.
XHTML-2-Citations
http://suda.co.uk/projects/microformats/X2C/
You have a list of formats. I'd call RIS (and the related
Refer/Endnote) an important legacy format; much more so than some of
the others. I'd be willing to send you some XSLTs I've written that
convert my RDF vocab to/from MODS, which might help. Contact me
off-list if interested.
...
let me know. Is the Straw proposal adequate? Is KEY required (can this
be accomplied with the ID attribute)?
I take you mean the bibtex key? I'm pretty sure it's required.
I don't your simple example is quite right. This:
@PDF{
TITLE=Using Microformats,
ABSTRACT=Interest in microformats has been steadily on the increase.
Microformats are easy to learn and implement. If you are a
Web-designer, a back-end programmer, or an interface engineer,
microformats are relevant to your field.,
KEYWORDS=book,oreilly,pdf,microformats,brian+suda,
YEAR=2006,
MONTH=09,
AUTHOR=Brian Suda,
PUBLISHER=O'Reilly Publishing,
ADDRESS=1005 Gravenstein Highway North, Sebastopol, CA 95472, USA,
}
... should be:
@BOOK{some-key,
TITLE=Using Microformats,
ABSTRACT=Interest in microformats has been steadily on the increase.
Microformats are easy to learn and implement. If you are a
Web-designer, a back-end programmer, or an interface engineer,
microformats are relevant to your field.,
KEYWORDS=book,oreilly,pdf,microformats,brian+suda,
YEAR=2006,
MONTH=09,
AUTHOR=Brian Suda,
PUBLISHER=O'Reilly Publishing,
ADDRESS=1005 Gravenstein Highway North, Sebastopol, CA 95472, USA,
}
@PDF is not a valid type, nor is it even a type in any case; it's a format.
Bruce
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] copy-and-paste metadata prior art?
On 10/2/06, John Allsopp [EMAIL PROTECTED] wrote: In an application I developed in 1994-6, Palimpsest you could cut and paste the links (I called them cross references) and annotations, which had rich meta data in them. You could tag links and annotations with labels, links and annotations had creators, creation dates, etc. All this data was maintained when copying and pasting within the app. But not on the system pasteboard? I don't think the difference is significant, but it seems to me the application claims it is (indeed, imagine next-generation desktop functionality where one could paste metadata long with content). I've gotten two pieces of information/suggestions: 1) On formal process: To have your materials considered during the substantive examination process, you'll want to file your prior art under rule 1.99 which is for post-publication protest. It requires payment of a fee and does not allow you to provide commentary on the prior art submissions but Rule 1.291 submissions have to be done before publication.. Not sure what the fee is, but it's telling that you have to pay one! 2) More informal: a number of people suggested writing an article for Groklaw. Problem is I'm not competent enough in patent law to do that. Bruce ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Process to handle decentralized creation of new microformats?
On 10/1/06, Costello, Roger L. [EMAIL PROTECTED] wrote: Centralized control of the creation of microformats is akin to the XML community mandating that all XML tags be created by a central clearinghouse. Indeed. There are lots of really smart people on this list. There must be a solution. Can you think of a process for allowing a decentralized creation of microformats, without the ensuing chaos alluded to above? This goes back to the suggestion that has come up on this list in the past (but which got shot down) that it'd make sense to have some cooperation between this community and the related RDF/A and embedded RDF efforts. I personally don't think you can have decentralized development that scales without two technical prerequisites: a clear and consistent model and namespaces. And without those two things, microformats are going to hit a wall. Bruce ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Process to handle decentralized creation of new microformats?
On 10/1/06, Tantek Çelik [EMAIL PROTECTED] wrote: [...] And without those two things, microformats are going to hit a wall. Then let us find that wall. I'm not afraid of a problem we don't have. That's a reasonable perspective. ... Until then, everybody has a choice of two paths. Don't worry about it and work on solving immediate practical problems, OR, worry about it, and work on solving theoretical meta-format problems (the so-called boiling the ocean). There are plenty of folks working on the latter. This community is focusing on the former. That's a bit of a false choice. There are good practical reasons to want an extensible model that allows decentralized development. Not a choice between theory and practice; maybe more about scope of concerns. I'm content to not worry about it now, but I do think that wall may be around the bend;-) Bruce ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] copy-and-paste metadata prior art?
Does anyone know of any prior art that might be used to contest this patent? http://www.macnn.com/blogs/?p=110 From what I can tell, Apple is trying to patent the ability to copy-and-paste metadata to the clipboard, which would I think have far reacing impacts (doesn't stuff like LiveClipboard cover this ground?). Bruce ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] copy-and-paste metadata prior art?
On 9/30/06, Chris Messina [EMAIL PROTECTED] wrote: Not exactly copy paste, but I think that this patent definitely ought be challenged (or else the future of mF is indeed imperiled if Apple chooses to enforce this -- as it surely will). Right, and not just microformats, but the next generation of smenatic web-like data functionality in general. That we cannot now easily copy-and-paste metadata with content ought to be a temporary limitation. Another example of what's wrong with patents in this country, but I'd like to proactively head it off so it doesn't get approved. Bruce ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] copy-and-paste metadata prior art?
On 9/30/06, Chris Messina [EMAIL PROTECTED] wrote: BlogAssist (http://www.dejal.com/blogassist/) does something similar... and in fact, I had designed Flock's quotation system to work this way, using the blockquote cite= tag/attribute combo to retain the original data's source. Worth noting the patent application was filed in March of 2005. A lot of stuff I've seen publicly comes after that. Notwithstanding prior art, I don't think the idea itself should be patentable. There's nothing terribly novel about associating some properties with copied content. Fundamentally, whether they are font-style=italic or title=random title should matter. Bruce ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: Re: [uf-discuss] copy-and-paste metadata prior art?
On 9/30/06, Chris Messina [EMAIL PROTECTED] wrote: It is a patent application...not a patent. Yes, I said that. The point is I don't want it to become a patent ;-) ... So no need to worry just yet, but we should watch this and contest it if possible. Right. Bruce ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] copy-and-paste metadata prior art?
On 9/30/06, Andy Mabbett [EMAIL PROTECTED] wrote: Which country? Sorry; U.S. Bruce ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] [citation]: Brian's outstanding issues 2:
On 9/25/06, Ross Singer [EMAIL PROTECTED] wrote: That would be a reasonable option, though I'd also suggest a more generic document fallback (because real world citation practice just doesn't fit pre-defined boxes). Also, *if* you have a container typed as a journal then you also need a broader periodical. Well, periodical is fine... it could be mapped to journal (and monograph to book -- I mean, that seems like the logical analogy). The labels aren't that important as long as we can kind of match them (and, no doubt, OpenURL is an inexact science). I don't know, there seems to be a balance that can be struck -- universality vs. immediate functionality (and I think some balance needs to be struck in both directions). I agree, and part of it is just defininig a core model that can be logically extended without pain. Goes back to my suggestion that thinking in terms of class hierarchy is helpful. You start with the basics and then if need be, let people extend them. So start with: - Document - Book - Chapter - Article - Report - Collection - Periodical - Journal - Event - Conference ... or something like that. In fact, if someone wants to work with me on revising the documentation for my bibliographic schema (current new working title is Description of Citation Sources (DOCS), but I suck at names, so that might change) to clearly segment out a core set of types per above, I'm happy to do that. Something like this: http://www.users.muohio.edu/darcusb/citations/classes.png Bruce ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] [citation]: Brian's outstanding issues 2:
Followup blog post: http://netapps.muohio.edu/blogs/darcusb/darcusb/archives/2006/09/26/reference-types Bruce ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] [citation]: Brian's outstanding issues 2:
On 9/25/06, Michael McCracken [EMAIL PROTECTED] wrote: I do agree that using an element with type class instead of a huge number of type classes is the way to go here, to avoid class namespace pollution. I actually don't like using the separate element, in part because this information is usally not displayed, but rather used for processing (styling and conversion). The type does matter for display, in other words, but in more subtle ways that have the user see book. Before we settle this, can we go over the technical arguments against using classes? I know, for example, that Tantek once said it's not generally good practice to double up classes (hcite book) but I'd like some explanation about why. But I will say that in either case, one must allow for extensions. I've worked on this for a long time, and defining a fixed list of types that is anything but arbitrary is pretty much impossible. Bruce ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] [citation]: Brian's outstanding issues 3: nesting
First, a URL for the wiki page you are referring to would be helpful ;-) On 9/25/06, Michael McCracken [EMAIL PROTECTED] wrote: option 1: requires class names for every reference type. I don't like this option either. option 2: uses type class, but makes it confusing IMO - what if you want to include more data about the containing reference than just one element? Does the type continue to influence sibling elements until another type element cancels it out? Can't comment on the above since I don't know the context. I have another option that might work: option 3: nest ufs. I've used this a few times in examples without anyone commenting on it. Is this OK? What are the pros/cons? I have parsed HTML using a DOM traversal before, and this seems like it'd be reasonably easy to parse. It's also a little easier to write and more obvious than #2, IMO, since it's clear that the elements under the container span are all referring to the item that's of type book... span class=citationspan class=typechapter/span: span class=titlestuff/span span class=citation containerspan class=typebook/span span class=titleA collection of stuff/span I thnk that's fine, notwithstanding my other quetion about the type span (which seems even more funky in this case). Also, citation could probably be hcite? Bruce ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
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
[uf-discuss] firefox developer needed
I'm sorry if this is a little off-topic and hope I'm not breaking any rule for posting this, but given that this project is in part a really cool implementation of microformats (well, will be once hCite is done!) ... http://zotero.org They're really looking for an experience Firefox developer in particular; see below ... Bruce Senior Programmer: The Center for History New Media (http:// chnm.gmu.edu) at George Mason University is seeking a programmer to work primarily on Zotero (http://www.zotero.org), an open source bibliographic management and note-taking tool for the Firefox web browser. Applicants should have an advanced knowledge of JavaScript, XUL, XML, CSS, and other technologies critical for Firefox development, such as XPCOM. Applicants should also have a working knowledge of PHP, Java, and MySQL, and have solid command-line Linux skills. Ability to work in a team is very important. This is a grant- funded, two-year position at the Center for History and New Media (http://chnm.gmu.edu), which is known for innovative work in digital media. Located in Fairfax, Virginia, CHNM is 15 miles from Washington, DC, and accessible by public transportation. Please send a cover letter, resume, and three references to [EMAIL PROTECTED] with subject line senior programmer. Applications without a cover letter and resume will not be considered. The cover letter should include salary requirements and a description of relevant programming projects and experience. We will begin considering applications on 10/15/2006 and continue until the position is filled. Technology Evangelist: The Center for History New Media at George Mason University is seeking a technology evangelist for Zotero (www.zotero.org), an open source bibliographic management and note- taking tool for the Firefox web browser. The technology evangelist will be responsible for building alliances with scholarly organizations and libraries, encouraging scholars to try Zotero, developing and maintaining user documentation, and building awareness of this next-generation research tool. We are looking for an energetic, well-organized individual with excellent written and oral communication skills. Applicants should have at least some graduate training in library science or one of the humanities or social science disciplines as well as familiarity with relevant technologies (e.g., XML, RDF, metadata standards, and Firefox extensions) and scholarly research practices. This is a grant-funded, two-year position at the Center for History and New Media (http:// chnm.gmu.edu) at George Mason University, which is known for innovative work in digital media. Located in Fairfax, Virginia, CHNM is 15 miles from Washington, DC, and accessible by public transportation. Please send letter of application, CV, or resume, and three references to [EMAIL PROTECTED] with the subject line Technology Evangelist. We will begin considering applications October 15, 2006, and continue until the position is filled. About CHNM: Since 1994, the Center for History and New Media at George Mason University has used digital media and computer technology to change the ways that people—scholars, students, and the general public—learn about and use the past. We do that by bringing together the most exciting and innovative digital media with the latest and best historical scholarship. We believe that serious scholarship and cutting edge multimedia can be combined to promote an inclusive and democratic understanding of the past as well as a broad historical literacy that fosters deep understanding of the most complex issues about the past and present. CHNM's work has been internationally recognized for cutting-edge work in history and new media. Located in Fairfax, Virginia, CHNM is 15 miles from Washington, DC, and is accessible by public transportation. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Proposal: species
On 9/16/06, Andy Mabbett [EMAIL PROTECTED] wrote: [...] Thoughts, anyone? Sounds like a good idea to me; could be used in hCite too (since titles often include species names and such). Bruce ___ 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] vcard fn for name in A. B. Smith format
On 8/31/06, Jeremy Keith [EMAIL PROTECTED] wrote: For example, the name might be Charles Windsor, but the form of address is His Royal Highness, The Prince of Wales. What about honorific-prefix? 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, 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] vcard fn for name in A. B. Smith format
On 8/28/06, Brian Suda [EMAIL PROTECTED] wrote: Good Question Andy, you have several potential quirks with the string A. B. Smith. I am assuming 'A' is an abberiviation for a first name? 'B' is a middle name, and 'Smith' is the last name you can do the following: Yeah, but I don't think you can asssume that. Better to just treat A. B. as the given-name string. Bruce ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] vcard fn for name in A. B. Smith format
On 8/29/06, Ciaran McNulty [EMAIL PROTECTED] wrote: That's a good point, there are quite a few people whose given name is their 'middle' name, it could be A. Brian Smith or Anthony B. Smith, you can't necessarily assume. Exactly. Middle name is a silly concept in the real world, particularly when you get beyond North America and maybe parts of Wstern Europe. One of the things I think vCard got right is that the name model is quite international-friendly. It does not assume anything in particular about the relation between sort order and name part type. It's why there's no first/last/middle structures, and why they have the sort-string property. Bruce ___ 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] Automatic conversion of XML to microformat and vice versa; recommendation for handling XML attributes?
On 8/27/06, Costello, Roger L. [EMAIL PROTECTED] wrote: ... I am having problems with mapping XML leaf nodes that have attributes, e.g., aircraft_altitude units=meters12000/aircraft_altitude Can you change your XML? E.g.: aircraft altitude meters12000/meters /altitude /aircraft I'd say as a general rule, if in doubt, use elements to represent content in XML. Bruce ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Citation Example
On 8/23/06, Xiaoming Liu [EMAIL PROTECTED] wrote: The convention of eprints should come from rfc2731: http://www.ietf.org/rfc/rfc2731.txt http://dublincore.org/documents/dcq-html/ Excellent; thanks! Bruce ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] citation: another example of practice in the wild
On 8/15/06, Michael McCracken [EMAIL PROTECTED] wrote: Unfortunately, aside from optimism, that tool support is probably my only opportunity to help due to severe time constraints - it's getting pretty discouraging to watch the list for movement and not be able to help until things are more solidified. Though there was some recent hints that things are about to start moving again. FWIW, I've been working on the metadata stuff for ODF, and modeling bibliographic data in RDF. The vocularies I used? DC, Qualified DC (for relations mostly), and vCard, plus a handful of biblio-specific properties (volume, issue, pages and such). I really think we need an hDC and hDCQ. It's really not the microformat tradition, it seems to me, to invent full standalone formats. BTW, I tihnk the best real world example out there is Wikipedia. Bruce ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] citation: another example of practice in the wild
On 8/16/06, Michael McCracken [EMAIL PROTECTED] wrote: Bruce wrote: Though there was some recent hints that things are about to start moving again. That's encouraging - what hints were you referring to? Anything in public we can echo here? Yeah, recent list discussion; Tantek throwing down the gauntlet for a 0.1 August 30 release, Brian saying that sounded reasonable, etc. I really think we need an hDC and hDCQ. It's really not the microformat tradition, it seems to me, to invent full standalone formats. I'm afraid I'm only slightly familiar with how DC elements are being used. It seems like they're only being used (in HTML) now to describe whole pages, not parts of pages. I just read the DCQ page [1] about using DC terms in meta and link elements in the HTML head element - that's where I'm getting this from. Are you suggesting a new design pattern for using dublin core elements and qualifiers in all microformats? Or a specific microformat to cover some particular cases when you'd use DC? The former. DC and DCQ cover generic stuff: contributors, dates, titles, subjects, relations. Those are important in lots of contexts beyond citaitons. It makes more sense to me that hCite would use that, and that other formats could too, than that we'd define it all in hCite. FWIW, here's the demo I prepared for the ODF group to show namepsace and vocabularly mxing, and example of the relational character of citation data.. It's RDF, but I'm sure you can imagine a mapping to microformats. rdf:RDF xmlns:rdf=http://www.w3.org/1999/02/22-rdf-syntax-ns#; xmlns:dc=http://purl.org/dc/elements/1.1/; xmlns:meta=urn:oasis:names:tc:opendocument:xmlns:meta:1.0 xmlns:b=http://purl.org/net/biblio#; xmlns:v=http://nwalsh.com/rdf/vCard#; xmlns:dcq=http://purl.org/dc/terms/; xmlns:foo=http://foo.net/; b:Reference rdf:about=x b:author v:VCard v:n v:Name v:given-nameJane/v:given-name v:family-nameDoe/v:family-name /v:Name /v:n /v:VCard /b:author !-- use dc:type for typing, with controlled URI list -- dc:type rdf:resource=http://purl.org/net/biblio#Article/ dc:titleSome Title/dc:title dcq:isPartOf b:Collection dc:titleJournal Title/dc:title dc:type rdf:resource=http://purl.org/net/biblio#Journal/ /b:Collection /dcq:isPartOf b:volume23/b:volume b:issue2/b:issue b:pages123-165/b:pages /b:Reference b:Reference rdf:about=urn:isbn:0226738892 b:author v:VCard v:n v:Name v:given-nameCarl/v:given-name v:family-nameSchmidt/v:family-name /v:Name /v:n /v:VCard /b:author dc:title xml:lang=enPolitical Theology: Four Chapters on the Concept of Sovereignty/dc:title dc:date2005/dc:date dc:type rdf:resource=http://purl.org/net/biblio#Book/ dc:publisher v:VCard v:fnUniversity of Chicago Press/v:fn v:adr v:Adr v:localityChicago/v:locality /v:Adr /v:adr /v:VCard /dc:publisher dcq:isVersionOf b:Reference dc:title xml:lang=dePolitische Theologie: Vier Kapital zur Lehre von der Souveranitat/dc:title dc:publisher v:VCard v:fnDuncker Humbolt/v:fn v:adr v:Adr v:localityBerlin/v:locality /v:Adr /v:adr /v:VCard /dc:publisher dc:date1922/dc:date /b:Reference /dcq:isVersionOf /b:Reference /rdf:RDF Bruce ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] citation: another example of practice in the wild
On 8/16/06, Michael McCracken [EMAIL PROTECTED] wrote: OK: http://microformats.org/wiki/citation-examples#Wikipedia http://microformats.org/wiki/citation-examples-markup#Wikipedia_Examples Good job; thanks for that. I had put a couple examples there earlier, but this is better! More examples can probably stand to be added. I'm sure there's one of every kind of reference in there somewhere. Exactly; why it's such a good real world example ;-) [...] I am also not a lawyer, so I just parsed the string CASE NO. CV 04-9484 AHM (SHx) as case number, when I'm pretty sure those TLAs at the end mean something more. Case number, FWIW, can be understand as a kind of document number; not unlike report number and such. Acronyms like AHM often are kinds of abbreviated periodical titles, for court reporters (which are not what they sound like -- people -- but rather periodicals). Bruce ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] citation: another example of practice in the wild
On 8/16/06, Michael McCracken [EMAIL PROTECTED] wrote: I tried my imagination on one of my straw examples. Does this fit what you were expecting? In general, yes, though I'm not that comfortable commenting on the details of microfomrat design (exactly how best to encode the class attributes and such). One thing I noticed was that there seemed to be no DC term for what I had as 'instantiation', or the link to a copy of the actual resource. Maybe there's somewhere else we can borrow a term from, or was I missing a good choice from DC? I don't have much experience with using them, but dc:format/dcq:hasFormat I think covers this. Bruce ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] citation: another example of practice in the wild
On 8/16/06, Michael McCracken [EMAIL PROTECTED] wrote: Case number, FWIW, can be understand as a kind of document number; not unlike report number and such. Acronyms like AHM often are kinds of abbreviated periodical titles, for court reporters (which are not what they sound like -- people -- but rather periodicals). So, is is enough to mark these up as one big string and call it number, or would it be necessary to include extra markup for those abbreviations? I dunno on the markup, but yes on the generic number (aside from needing to make explicit that it's not the same thing as number in BibTeX). Bruce ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] citation: another example of practice in the wild
On 8/16/06, Tantek Çelik [EMAIL PROTECTED] wrote: FWIW, I don't think DC provides a particularly good set of names, far too theoretically designed, and eclipsed in practical usage by several of the other established formats (OpenURL, Bibtex). Come on Tantek; that's an entirely arbitrary assessment, without any real factual basis. Given the wide-spread use across a whole slew of formats (HTML, RSS, OpenDocument, the new MS XML formats, Adobe's XMP) how can you possibly say that it's theoretical? More stuff is described using DC than probably any format or term set in existance. But rather than argue about this, let's step back and pull out what we can likely agree on. The first group is so obvious I really don't think we could possible disagree: * dc:title (absolutely need a title term, for all kinds of things) * dc:date (and the qualfiers issued, etc.) * dc:subject (aka tag, keyword, etc.) * dc:publisher * dc:identifier And then there's the following, which have one issue or another where reasonable people can disagree: * dc:creator (OK, maybe a little problematic in different ways, but widely understood and useful, if too broad for most citation needs) * dcterms:isPartOf and isVersionOf. OK, yes, a little bit abstract, but they are excellent ways to describe critical relations in bibliographic data, in ways that don't resume upfront a limited scope of description. Document isPartOf collection, track isPartOf album, article isPartOf journal, etc. Am happy if someone comes up with better terms, so long as they still retain some flexibililty. Most of the rest isn't that important for citation data, but could be for other things (different media, say). Bruce ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] books, ids
Just an FYI of relevance to recent discussions of book encoding and ids, uris, etc. The OCLC has a new (and nice!) web version of its catalog: http://www.worldcat.org ... complete with pretty URIs. http://www.worldcat.org/oclc/26396865 http://www.worldcat.org/isbn/0816621268 Could be useful for hCite? Bruce ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCard and vCard
On 8/3/06, Tantek Çelik [EMAIL PROTECTED] wrote: On 8/3/06 5:07 AM, Ben Buchanan [EMAIL PROTECTED] wrote: Hmm, well the resulting vCard wouldn't actually be especially useful :) If it at least associated the person with a URL it would create a useful chunk of information. But I guess it does change it from bit of text to someone's name so yeah. But it is awfully borderline :) It is only minimally useful, in that it is still identifying that Ben Barren is semantically a *person*. Is vcard really that semantically specific? Bruce ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] relatinal modeling in microformats?
So I've been saying we need for hCite to correctly model the relational character of bibliographic data so that we keep a foucsed core, but also leave flexiblity. The more I think of this, the more I think this is a general issue. For example, say I'm using hCal (which I've not), how do I indicate that an event is part of another event? I can find these examples of conference schedules: http://www.gustavus.edu/events/nobelconference/2006/schedule.cfm http://2006.dconstruct.org/schedule/ Here there are calendars with embedded events for each presentation. But it seems to me the nested event relations are only implicit. In the second case, for example, there is an event description for the conference, but it is in no way associated with the calendar for the conference. And what if I am writing a weblog post about a particular presentation, and want to make clear that that event is part of a conference? I want to say I saw Jane Doe give talk entitled X, Y, Z at the ABC Conference. How would I do that using microformats? The problem, it seems to me, is the same as indicating the relation between an article and a periodical, or a post and a weblog. And, of course, citations can themselves be references to events. Bruce ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] relatinal modeling in microformats?
On 8/2/06, Scott Reynen [EMAIL PROTECTED] wrote: [...] Or is there something you'd expect parsers to do with that information beyond treating it like a tag? I don't know of any calendar applications that handle events-within-events, so I'm not sure what the use case is here. I didn't really have any particular expectations associated with the question, but if it's not modelled, then of course those possibilities are more limited. Not all even data ought to be specific to calendar applications. Come to think of it, tnough, if I decide to post a CV online that includes among other things (includng publications) conference presentations, then if I can consistantly model those relations (article partOf journal, paper prsentation partOf conference), I could imagine interesting mashups and such, like maybe grabbing all the CV data for a group or department and processing it; members X, Y, Z presented at ABC Conference, etc. Bruce ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Easy book citations
On 7/31/06, Ross Singer [EMAIL PROTECTED] wrote: I think one of the stumbling blocks we're having here is trying to figure out what we're really using citations for. 1) There's obviously a group that wants this data to be used with bibliographic management software 2) There's a group that wants these citations to be able to link to fulltext/print/etc. for any person's library 3) There's a group (I think?) that wants to be able to display properly formatted citations (or, at least more properly). Are we leaving a scenario out? #3 seems the most complicated. If the goals of #1 are met, then #2 will most likely be met, as well (although not necessarily the reverse). Does this seem accurate? On 3, I've been working on cracking the formatting nut for the past couple years, and am just about done [1]. It is indeed quite difficult, but I mostly see it as distantly related to hCite. But I see citation metadata as a cycle. I want ulitmately to be able to output good uF metadata such that users can: - view a nicely formatted document in their browser, complete with proper citations - click some button and go to the original article or book - click some other thingy and import citations into my browser-based reference database (coming real soon, GPL licensed!), or copy-and paste the citation content directly into Word or OpenOffice - be able to use that data to create other documents with citations So yeah, a good data format supports 3, though is not so much its own requirement. Bruce [1] http://netapps.muohio.edu/blogs/darcusb/darcusb/archives/2006/07/29/csl-progress ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Easy book citations
On 7/30/06, Tantek Çelik [EMAIL PROTECTED] wrote: On 7/30/06 7:59 AM, Fred Stutzman [EMAIL PROTECTED] 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 seriesSeries 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/blogs/darcusb/darcusb/archives/2006/07/29/csl-progress ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Easy book citations
On 7/30/06, Simon Cozens [EMAIL PROTECTED] wrote: Now, it is a happy coincidence that the microformat I've created as an ad-hoc thing and am using on You Need To Read This uses exactly the same namespace as BibTeX - but that is because author, title and book are pretty obvious names for the things they describe. :) Actually, book shows the problem with the BibTeX model. It's not at all obvious. Now, if you had book title, then maybe. But that's only when you are encoding chapters. If you have a standalone book, then you use title. OTOH, if you just have a single title structure and allow it to include an additional class attribute to qualify it (like container or publication), problem solved. Bruce ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Easy book citations
On 7/30/06, Simon Cozens [EMAIL PROTECTED] wrote:
Bruce D'Arcus:
BibTeX - but that is because author, title and book are pretty
obvious names for the things they describe. :)
[ Something about a problem ]
OTOH, if you just have a single title structure and allow it to
include an additional class attribute to qualify it (like container
or publication), problem solved.
I do, yes. There wasn't a problem to be solved. :) My format looks like
div class=book
span class=title Foo /span
/div
BibTeX has
@Book{Thingy,
title = { Foo }
}
Looks rather similar. But I didn't design it that way consciously because of
BibTeX - I designed it that way because it seemed to be the simplest and most
obvious way of doing it.
No, books per se are the easiest things in the world ot model, and
it's hard to ever find an argument about this one.
The examples I am referring to -- and which start to show difficulty
-- are thiings like parts (chapters) within books. If you encode the
title for the book as span class=publication titleBook
Title/span (or use container instead of publication), then
great!
If, OTOH, you insist on span class=book-titleBook Title/span
(e.g. a single class attribute, a la BibTeX) then I'm afraid I'll have
to fight you tooth-and-nail ;-)
Perhaps the authors of BibTeX thought so too. :)
I'll be blunt: BibTeX is a hack. It was written by a scientist (no
consideration of the needs of humanities or social sciences people)
before the internet, before unicode, widely available relational
databases, before XML, etc, and it shows.
Bruce
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Easy book citations
On 7/30/06, Simon Cozens [EMAIL PROTECTED] wrote: Oh, I've read it all. I'm just of the opinion that following process, collating examples, performing analysis, holding discussion, forming consensus, trialling implementations, reviewing implementations, and issuing specifications is a way to ensure that nothing gets done, ever. The citation process started a year ago. There's still, apparently, nothing I can use today - at least, nothing better than the ad-hocery I just created. Do you really think that consensus on a difficult topic ilke this is easy? Sure, we all can create ad hoc stuff. The point is to come to some collective aggreement (though see below). I think if you couple my suggested list of properties with Brian's straw man from awhile back, you'll kniow where we are: http://microformats.org/discuss/mail/microformats-discuss/2006-April/thread.html#3952 I pinged Brian about gettnig back to this a few days ago. He's been swamped with other things, but sid time would open up soon-ish. I should also add for the record that the participants in this discussion were moving toowards consensus after an IRC meetup, but Tantek had rather a different idea of process that left a lot of us frustrated: http://microformats.org/discuss/mail/microformats-discuss/2006-April/thread.html#3643 Bruce ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Easy book citations
On 7/30/06, Fred Stutzman [EMAIL PROTECTED] wrote: On Sun, 30 Jul 2006, Bruce D'Arcus wrote: The examples I am referring to -- and which start to show difficulty -- are thiings like parts (chapters) within books. If you encode the title for the book as span class=publication titleBook Title/span (or use container instead of publication), then great! Bib natively supports inbook citations. I'm not sure I see what the problem is? The problem is the totally flat data model, and fields like booktitle and journal. These are basically hacks to suggest implicitly the relation in question. They work within their narrow realms, but they break when you deal with even subtly different relations and reference types: newspaper articles, legal cases (published in court reporters, which are just a kind of periodical/publication), etc., etc. The thing you have to recognize in designing a good, extensible, format is that biblioigraphic data is fundmentally relational. It makes sense to hide that complexity where you can, but there are some places where I think it's really bad pratice to do so. Title is an example. Bruce ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Easy book citations
On 7/30/06, Fred Stutzman [EMAIL PROTECTED] 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-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Easy book citations
On 7/30/06, Bruce D'Arcus [EMAIL PROTECTED] 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 titleSeries 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-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Easy book citations
On 7/30/06, Fred Stutzman [EMAIL PROTECTED] wrote: On Sun, 30 Jul 2006, Bruce D'Arcus wrote: The thing you have to recognize in designing a good, extensible, format is that biblioigraphic data is fundmentally relational. It makes sense to hide that complexity where you can, but there are some places where I think it's really bad pratice to do so. Title is an example. I see no reason why we couldn't implement relational characteristics in the microformat. The general idea is to take a standard and to make it better as it becomes a microformat. In this context, we'd be improving upon the bib format. OK, cool. That's all I've been saying. Bruce ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Google Disses TBL and the Semantic Web
On 7/19/06, Chris Messina [EMAIL PROTECTED] wrote: Ah ha! http://news.com.com/2100-1025_3-6095705.html A rather self-serving argument. Of course Google wants all the intelligence in search engines. Bruce ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] RDFa and microformats
On 5/30/06, Scott Reynen [EMAIL PROTECTED] wrote: On May 30, 2006, at 1:25 PM, Elias Torres wrote: We could gain more if we gave it a shot at working together by leveraging the unbelievable momentum uFs have and the more general goals of RDFa even though in the end we might end up with *A* totally different specification that what either of the current proposals started as in their respective organizations. I think the disconnect right now is that the process of microformat development requires real-world implementations on which to make decisions, and RDFa has no real-world implementations. WRT to recent blog posts comparing the different ways of embedding metadata in XHTML, I found this summary quite good: http://www.bnode.org/archives2/58 FWIW, I strongly support the suggestions from Evan and Elias. Bruce ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: RDFA - ugly, unnecessary and offtopic (was Re: [uf-discuss] RDFa)
On 5/19/06, Tantek Çelik [EMAIL PROTECTED] wrote: * The use of QNames is *NOT* a use of standard XML namespaces, not by a long shot. QNames don't work with CSS Selectors, thus being impractical for presentation, thus failing to satisfy the primary use of semantic markup. I wonder about that too. At the OpenDocument TC, we discussed another way to sort of split the difference here, which is to allow an optional uri to be attached to a style. So, you use styles just as normal, but have the ability to attach further semantics to the definition. * The fact that this draft had to invent a new form of URI (CURIE) should be a strong indicator that there is something wrong. Whenever you find yourself inventing new piece of technology for an orthogonal part of the stack, it usually means you're doing something wrong in your layer. Yeah, but I think the problem here is with QNames, not RDFA. Bruce ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Citation Straw Proposal II (Recap)
On 5/5/06, Bruce D'Arcus [EMAIL PROTECTED] wrote: A given article citation is part of a journal (which is just another citation). The problem is that they would share ALOT of the same info (PubDate, Publisher, etc) It would be difficult to publish an article in a journal by two different publishers? (or i am off the mark here?) So i'm not sure how much benefit there is in nesting citations. You see the benefit even in really simple examples like chapters in edited collections. The chapter author is a creator on the main level, while the editor is attached to the container. Just to expand a bit, I don't think the issue you raise is that much of a problem in practical use. I'm saying that it's pretty crucial to be able to associate, in particular, contributors and titles with their relevant relations. In fact, the majority of bibliographic data formats I'm aware of (RIS, Refer, TEI, MODS) use some kind of level or relation encoding to capture this. So you could do (just using titles for illustration): li class=citation span class=titleChapter Title/span span class=container span class=titleBook Title/span /span /li li class=citation span class=titleConference Paper Title/span span class=event span class=titleConference Title/span /span /li ... or: li class=citation span class=titleChapter Title/span span class=container titleBook Title/span /li Note: the current publication thing covers similar ground as container, though is more narrow. li class=citation span class=titleConference Paper Title/span span class=event titleConference Title/span /li Without either of those, it won't scale, which becomes even more clear when you throw contributors into the mix. And the only benefit the non-nested example offers is it's more terse. But it's also more difficult to process. Bruce ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Citation Straw Proposal II
On 5/3/06, Joe Andrieu [EMAIL PROTECTED] wrote: Perhaps a Retrieved Date or Access Date would be appropriate for citing online resources. Yes, it's critical for academic references. I'd vote for accessed. FWIW, this is simply a convention to account for the fact that urls may not be stable. Bruce ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Adobe's XMP Platform (for media metadata)
On 4/30/06, Chris Messina [EMAIL PROTECTED] wrote: [...] We've talked much about media-metadata and fotonotes... I wonder where XMP fits into this, as it's open source... At the very least we should do due diligence, eh? FWIW, XMP is just marketing speak for an RDF subset. And while there is an open source toolkit, it's C++-only. The format itself is not particularly open. Bruce ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Citation Straw Proposal II
On 4/29/06, Brian Suda [EMAIL PROTECTED] wrote: - IsPartOf is another property that has been discussed which is not represented. Bringing this together with the publication and journal proprties: Are these relations, or simple properties (strings)? They need to be the former, and I think it's important that we clarify the precise list. I'd prefer a generic relation similar in concept to isPartOf, which would then be coupled with more specific genres/types like: publication periodical journal series Otherwise, looks good. Bruce ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Citation Straw Proposal II
On 4/29/06, Ross Singer [EMAIL PROTECTED] wrote: Author/Editor/Translator should be a priority. I realize this is more important in the computer vs. human continuum, but it doesn't seem /that/ difficult to make it an easy win for both camps. I agree. Books, for example, can have all three, and it's important to distinguish them (though I'call editor a secondary contributor role; not quite a creator). Bruce ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: uid microformats? (was Re: [uf-discuss] ISBN mark-up)
On 4/26/06, Joe Andrieu [EMAIL PROTECTED] wrote: [..snip...] By my interpretation that has both a format UID and a locator URI for that format. Shouldn't there be a similar disambiguation for the microformat class one is using? This seems related to namespaces and I know only that they caused some challenges with RDF... Does it make sense for a microformat to actually label itself as such, including a UID and a URI? div class=microformat uid=hCoupon href=http://www.joeandrieu.com/hCoupon; I think you ask some good questions! See RDF/A for one answer: http://www.w3.org/TR/xhtml-rdfa-primer/ Likewise, Ian Davis has done some work with RDF embedded in XHTML (basically a mf). Both involve declaring vocabularies in xhtml:head, and then using prefixes in the class (and other) attributes. Bruce ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: uid microformats? (was Re: [uf-discuss] ISBN mark-up)
On 4/26/06, Tantek Çelik [EMAIL PROTECTED] wrote: The naming 'uri' vs 'uid' aside, would it be reasonable to RECOMMEND that a URI is used (thus including URLs) and leaving the door open to less useful ids should people want to use them? Yes, and I have just added similar details to uid-brainstorming, preferring URLs first, then URNs. I'm glad there's some progress in this discussion, but you're still trying to come up with a general rule for disparate things. At the risk of throwing major confusion into this discussion, but with the thought that it might help clarify things further, I'd like to whip out FRBR again. The FRBR model says that when talking about stuff, we can think in terms of four levels of abstraction; from top to bottom: 1) work - an abstract creation 2) expression - some realization of a work (say, an english language text) 3) manifestation (a physical production, like a book) 4) item - the specific thing you have in your hand or on your screen URLs are in essence focused on 4; they are about locating items. With web documents, that URL is in essence equivelant to the manifestation too. If one wants to get article x, one goes to one particular url. No problem. But when we're talking about stuff that exists independently of the web, this breaks down, which is why the value of more abstract uris for identification. If one uses a urn to indicate a book isbn, we are at the manifestation level, and using that makes it possible to then locate any one of thousands of individual items, If one uses an asin to indicate a movie, say, one is identifying the work level, which can then be used to locate multiple expressions (theatrical releases, special editions, etc.), whcih in turn can have multiple manifestations (DVD vs. VHS), etc. So I'd say that URLs should only be preferred where one is referring to a particular item whose canonical location is in fact on the web. E.g. when you have a web resource, use a URL. Otherwise, prefer a urn, and then perhaps other similar options such as info. Can we perhaps agree on that? Bruce ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: uid microformats? (was Re: [uf-discuss] ISBN mark-up)
On 4/25/06, Tantek Çelik [EMAIL PROTECTED] wrote: On 4/25/06 12:01 PM, Xiaoming Liu [EMAIL PROTECTED] wrote: First hopefully we all agree on the problem to be addressed here, I think it is a microformat for indicating something *is* an identifier, and I will presume there are three possible solutions: URL, UID, URI. URL is good and I agree we should choose to resolvable URLs if possible. However URL identifies a resource via a network location, thus limits its scope, This isn't a limitation, this is a deliberate preference. We *want* resources that can be identified by network location and thus a system that shows a bias *for* that is a *good* thing. In short, it's a feature, not a bug. ;) That all depends on the context. In the context that Xiaoming and I are talking (where uris are used to identify abstract concepts), I'd call it a bug. many well-established identifiers are not based on URL. e.g. In a typical library application, we really want to identify the books in Amazon and local catalog are referencing same thing, Ah, you just introduced a new requirement, and perhaps that is where the disconnect is. You are assuming that we need to design into the format a way to identify that two *different* references to a book are the *same* thing. There are MANY contexts in which there's a need to identify abstract things, which by definition cannot have fixed locations. That's what ASIN, ISBN, ISSN, pubmed ID, etc., etc., etc. all do. Books are just one simple example. We don't actually need to solve that problem in the scope of the microformat design. That is something that we may leave up to implementations instead. In other words, I see no reason to solve this problem at the format level. The requirement that we are looking at is: globally unique, that is, two *different* events/contacts don't end up using the same UID. That's it. If the same event in two places uses different UIDs, that is actually ok. That's something that implementations can actually deal with. So what we will end up with is that forward-looking people will use standardized uris of these sorts, but may call it something else: a broader concept called uid? UID might be good in their original scope (vcard and iCalendar), but I am afraid it is not sufficient for a wider scope, both semantically and syntactically. The original scope was the global exchange of contact and event information. The scope for hCard and hCalendar is the same. The scope has not changed. But you suggested using this in more general contexts, so it's perfectly reasonable to raise the question of scope. [...snip...] similarly, in an identifier microformat you may also want to encourage standard value to be used to allow interoperability. While UID allows *any* text value, there are good practices of URI schemes and specifications. Hence we are suggesting that a good UID is actually a URL, which is an even stronger statement than just URI. It may be stronger, but it's problematic in many cases. I believe the syntax issue is rather important, because without clear specification, all kinds of things can be stuffed in, therefore defeating the purpose of interoperability, as illustrated by DOI/ISBN examples in [1]. It does not defeat the purpose, it merely allows the market to select the better scheme. Those that use poor identifiers are more often ignored by the market. We don't need to solve this problem at the format level. So then for dates, it's unimportant to say that they must conform (when encoded in title attributes) to any standardized date representation; just let the market decide? Bruce ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: uid microformats? (was Re: [uf-discuss] ISBN mark-up)
On 4/25/06, Tantek Çelik [EMAIL PROTECTED] wrote: It may be stronger, but it's problematic in many cases. Then we postpone those cases and focus on the ones that work now. Except that the thread that got merged into the uid one was, in fact, about marking up isbns and such, which is one of these cases. I believe the syntax issue is rather important, because without clear specification, all kinds of things can be stuffed in, therefore defeating the purpose of interoperability, as illustrated by DOI/ISBN examples in [1]. It does not defeat the purpose, it merely allows the market to select the better scheme. Those that use poor identifiers are more often ignored by the market. We don't need to solve this problem at the format level. So then for dates, it's unimportant to say that they must conform (when encoded in title attributes) to any standardized date representation; just let the market decide? ISO8601 is fairly well accepted. The battle is over. So we pick the current winner and go with it. Exactly, and I'd argue the same of uris. ;-) FWIW, I like Xiaoming's suggestion. Bruce ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: uid microformats? (was Re: [uf-discuss] ISBN mark-up)
On 4/24/06, Tantek Çelik [EMAIL PROTECTED] wrote: Third, I actually see disadvantages in using URIs as a basic unit rather than URLs. URLs are far more useful in that they assert you can go get this thing, it has a location, most likely on the Web. Thus as a pattern we should use URLs in microformats, not URIs. I have no strong opinion on the general issue of uid vs. uri; was just raising what I think might be an important question. But I do disagree with the above. Ids like isbns and asins are used to refer to abstract concepts (books, and audiovisual works* respectively), so it's rather meaningless to assert that you can grab such a thing from any one location. Yes, a book might be available at Amazon, but it's also available in thousands of other locations. Likewise with dois, which might resolve to different locations depending on various factors. There are some library hackers (Dan Chudnov et al) doing some interesting work with proxies that take standardized uris of this sort and then, depending on the prefixes, grab the associated metadata from the approprirate service (pubmed, Amazon, Flickr, etc.). I believe that this question in part was connected to that sort of work, since Ed is involved in that. Bruce * for more on the notion of works and abstraction, see FRBR http://www.ifla.org/VII/s13/frbr/frbr.htm. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: validating microformats (was Re: [uf-discuss] Google Gdata new syndication protocol!)
On 4/22/06, Tantek Çelik [EMAIL PROTECTED] wrote: In fact, DTD, Schema, etc. are insufficient to validate any real world adopted format, whether SGML, XML or something else. That's too strong. If you say DTD and XML Schema are both rather limited WRT to validating XML, fine, but with RELAX NG it's actually pretty easy to validate complex real world XML. While I haven't really worked iwth it,, I'd bet the RNG schema for Atom does a really good job validating Atom instances. But as Norm's post pointed out, it does assume that important structural information is encoded as elements or attributes, as opposed to more funky stuff like token lists *in* attributes. Bruce ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] ISBN mark-up
On 4/21/06, Andy Mabbett [EMAIL PROTECTED] wrote: If any one of those were marked up, something like: span class=ISBN0 9507881-2-0\span or even: isbn0 9507881-2-0/isbn then user agents could be written in such a way that the spaces and hyphens were ignored. ISBN is a registered URN, so I'd rather see coding that supported that; e.g. urn:isbn:0950788120. Bruce ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Google Gdata new syndication protocol!
On 4/20/06, Chris Messina [EMAIL PROTECTED] wrote: Holy hell. This is rediculous. Gdata == the Word document format of web 2.0. Does anyone know *anyone* in Google that will tell us why they're ignoring microformats?? What value do microformats provide in this context? They hardly seem ideal for the sort of straight data transport that seems to be the focus on the gdata stuff. Bruce ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Google Gdata new syndication protocol!
On 4/20/06, Scott Reynen [EMAIL PROTECTED] wrote: What value do microformats provide in this context? They hardly seem ideal for the sort of straight data transport that seems to be the focus on the gdata stuff. The same value they provide everywhere else. Human-readable data is easier for human programmers to work with, even if it's being consumed and produced entirely by machines. When it's not being used solely by machines (as RSS and Atom are not), it also cuts down on data repetition, which reduces opportunity for error and is just less work for everyone involved. Why should I produce a feed of my events in Gdata format, when I already have them in microformatted HTML, which both humans and computers can already read? Call me sceptical. Dedicated XML formats (like Atom) that can be validated with standard XML tools are more valuable for data exchange it seems to me; easier to read and to write. Bruce ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCard and Life Dates?
On 4/18/06, Dr. Ernie Prabhakar [EMAIL PROTECTED] wrote: I would vote of hCalendar --- this really is a full event, the life of one person. It also would be the most natural extension of a birthday event. Ian Davis has a series of posts on this sort of modelling -- using Einstein in fact -- in RDF. Here's the first: http://iandavis.com/blog/2005/04/refactoring-bio-with-einstein-part-1-first-steps?year=2005monthnum=04name=refactoring-bio-with-einstein-part-1-first-steps Bruce ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Citation format straw proposal on the wiki
On 3/30/06, Tim White [EMAIL PROTECTED] wrote: [... snip ...] In short, I'd like to be able to talk about a book on my blog: I am reading cite class=hcitation titleOperating Manual for Spaceship Earth/cite ... AND, be able to cite it at the end of a longer piece: cite class=hcitation span class=vcardspan class=author fnR. Buckminster Fuller/span/span. span class=titleOperating Manual for Spaceship Earth/span. span class=publisherPocket Book/span, abbr class=dtpublished title=19701970/abbr. span class=pages127 pages/span. ISBN: span class=isbn671-78046-8/span. /cite Make sense? Yup :-) Although, to clarify, your distinction above is really between an in-text citation, and a full bibliographic reference. Bruce ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Citation format straw proposal on the wiki
On 3/28/06, Ross Singer [EMAIL PROTECTED] wrote: On 3/28/06, Bruce D'Arcus [EMAIL PROTECTED] wrote: I have to disagree on the usefulness of the OpenURL stuff in this context. Can you explain this? w/r/t HTML, I find OpenURL the /most/ useful in this context, with this context being web content and OpenURL being a means to link a citation to an appropriate copy/service. In fact, I think if you use the 80/20 rule, your majority of users would be /much/ happier finding fulltext for a given citation than the ability to effectively load it into their citation manager. Not aimed at you in particular Ross, but I really hate it when people trot out the 80/20 rule, whose subtext is always about placing the argument of others in the 20 category. And usually when people do it in the context of citations, it is people who come from the hard sciences telling the humanities people to be quiet (usually in the form of BibTeX is great, why use anything else?). So if we do want to talk about 80/20 here, we need to clarify: whose 80/20? Do we only create a MF that works for geeks who code their own HTML? Or do we consider a more inclusive approach that would be appropriate for a broader range of users? I'm not dismimssing OpenURL out of hand. Indeed, I added the in this context qualifier, and certainly one could include OpenURL's (and DOI's) within a MF. But I do reject the notion that the existing OpenURL journal article schema, for example, provides a good model to design a more general microformat. It's just flat key/value pairs, which does not scale. To me a test of an 80/20 format is can a user/developer reliably and consistently encode the following: 1. articles (not just journal articles, but also for other periodicals) 2. speeches and other presentatiions (like a conference paper) The trick is to avoid genre-specific property names like jtitle or conference-title and exploit the nested possibilities of HTML and the fact that one can include more than one class attribute. But this does get us back to use cases and requirements. By your logic, we might not bother with citation text at all. For me, though, I want to be able to extract that content in addition to view it. We could probably cover both needs though. Aside: I typically send my publishers XHTML (generated from DocBook and RDF source), so my full citations and bibliographic entries are encoded in a microformat at that point. But there I have to conform to precise publisher requirements about citation style. Bruce ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Citation: display-first?
On 3/28/06, Michael McCracken [EMAIL PROTECTED] wrote: ... Basically, what I'm wondering is: if I'm marking up a citation, why does it matter if I sometimes need to do something like this: a class=title url href=http://www.library.yale.edu/scilib/modmodexplain.html;eprint Moderator Model/a span class=author vcard a href=http://pantheon.yale.edu/~dstern/dsbio.html; class=url fnDavid Stern/a /span and sometimes this: a class=title url href=http://www.library.yale.edu/scilib/modmodexplain.html;eprint Moderator Model/a span class=author vcard a href=http://pantheon.yale.edu/~dstern/dsbio.html; class=url fnDavid Stern/a /span I've not yet had my morning coffee, but aren't the two above the same? Also, what is it about the above that you think is different than the dominant thrust of the existing discussion? Because allowing that seems more in step with the humans-first microformats methodology - we don't need to define a data format that can represent everything, we *do* need to give people a way to mark up citations they already produce in a way that provides more structure. I think it's critical to get the basic structure of the modeling right, and that will achieve what you ask for above. The wrong approach is to just use a series of flat key-values, and to borrow those from BibTeX. The right approach is to define a basic set of relations, and a list of properties. Alf Eaton and I were discussing this just yesterday, in fact, and the example he sent me (hope he doesn't mind if I post it here!) is close to what I'd advocate: div class=bibliography id=x-JMIR-v7i4e49-bibliography ol class=reference-list li class=citation reference book chapter id=x-JMIR-v7i4e49-ref15 a class=uri href=urn:isbn:45346327/ span class=titleAdvanced interactive video design: new techniques and applications/span. span class=author nameDuppa N/span and span class=author nameAnderson K/span. span class=container span class=year1988/span. span class=titleBook Title/span span class=editors span class=editorJane Doe/span and span class=editorSimon Smith/span (Eds) /span span class=publisher span class=locationNew York/span span class=nameABC Books/span /span /span span class=pages span class=page-start33/span- span class=page-end56/span /span /li /ol /div My only complaint is that the book class really out to be on the container span. I also think there are some other details to address. But I like it, and I think it's critical that the MF recognize that bibliographic metadata is not flat, and that BibTeX fields like journal are thus too limiting. Does anyone think I'm way off base here? I've started a use-case section on citation-brainstorming, and added my personal axe to grind - I'm interested to see other takes on what specifically a citation microformat would be used for. To me your first use case is the most compelling. I think RSS/RDF already does a better job at handling syndication than can be reasonably achieved with microformats. An aside: I am on the OpenDocument Technical Committee. We've recently created a metadata subcommittee, whose task is to add enhanced metadata support to the file format. It is highly likely we will be using RDF in some form. So for me, an important requirement of any microformat is that it be easy to transform to RDF (and back). Bruce ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Citation: display-first?
On 3/28/06, brian suda [EMAIL PROTECTED] wrote: I also agree that Citations are NOT flat key=value pairs and that they do have a nested hierarchy. We also don't want to reinvent the wheel, there are already formats for describing address information[2] and people/organizations[3], so we should reuse as much as possible. Yes. FWIW, for my own bibliographic collection, I use RDF, with a current mix of the following vocabularies: 1) DC and Qualified DC for most of the properties and relations 2) FOAF and Norm Walsh's vCard interpretation for agent data (people and organizations, addresses) 3) My own schema for classes and a missing relation or two: http://purl.org/net/biblio I'm also using a bit of PRISM for stuff like volume and issue properties, though may remove those in favor of having the biblio schema cover all that. Bruce ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Citation: display-first?
On 3/28/06, Michael McCracken [EMAIL PROTECTED] wrote: If you mean what is different about my example, nothing. I just wanted to ask about the problems raised in the 'orignal hBib discussion' - where data ordering might be needed to be reworked for display, and my question was basically whether that was actually a problem for the design of the microformat. OIC. Yes, I saw that discussion earlier, and I think that particular goal (of being able to use CSS to style the citations, including handling reordering) is completely unrealistic. CSS cannot possibly handle the complexity of citation (re)styling. So this comment from that document I think is off: === There are hundreds of journal-specific formats for presenting bibliographic data. If CSS cannot transform structured biblographic information into at least 80% of the presentation format, the Microformats way fails. === If we accept that premise, then we might as well give up now. For my own use, I see XHTML + MF as only a rich output format, where the source is more robust formats like DocBook and RDF (and hopefully in the future OpenDocument). But that static output can itself be useful. A citation microformat would be an excellent choice to use as the content of RSS items, however ... There's already some pretty good solutions out there (CiteUlike and IngentaConnect come to mind) that use RSS 1.0 (.e.g RDF) for this sort of thing. I can't possibly imagine that a MF would offer any advantage over them, and would offer significant liabilities. Bruce ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Citation: display-first?
On 3/28/06, Michael McCracken [EMAIL PROTECTED] wrote: What about the advantage that a MF is viewable in a browser? I can ask people to add a little structure to their markup much easier than I can ask them to support entire new alternate formats. Good point :-) Could you explain more about the liabilities of using a MF in RSS that you refer to? I'm talking WRT to machine processing. With full formats like XML/RDF, you get namespaces, rich linking support with a solid and consistent underying model, etc. But you're right; most news readers only support a handful of elements (though the most important ones typically). Still, if possible I'd prefer to have a full rich machine-processable representation AND a nice human readable one that will work with existing news readers. Bruce ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Citation format straw proposal on the wiki
On 3/28/06, C. Hudley [EMAIL PROTECTED] wrote: But, the helpful part of the distinction is that when you're examining a reference external to the content at hand, you don't need the full bibliographic details. This immediately lets you eliminate stuff like subjects/keywords, pricing, copyright, licensing, owner, format, coverage, and audience, all of which are mapped in the citation-formats. All the above is true except for format/media. While for standard texts this information is not relevant, for other sources it is. (** to be precise, I'd just reuse the profiles defined in OpenURL for journals and books to start, since those are explicitly barebones subsets for following references, but you've heard that from me before...) I have to disagree on the usefulness of the OpenURL stuff in this context. Mike, I don't spend time designing microformats either, but just looking at your list of properties, a few comments: # title: required, text (class = fn) # subtitle: optional, text I've come around to the belief that title and abbreviatedTitle is more a more useful distinction. The latter can also cover things like journal title abbreviations. # authors: optional, use hCard You need editor and translator too. aside: I wonder WRT to names if there's some way to encode a normalized version somehow for easier conversion? # publication date: optional Dates are tricky. For example, my book has a copyright date (and hence, the citation date) of 2006, yet was publshed in 2005. In my own data, I tend to just use dc:date, and in some cases dcterms:issued and dcterms:dateCopyright. # link(s) to instantiations, optional, url or use rel-enclosure? (class=url) # UID, optional (for ISBN, DOI - use existing uid class) | permalink I think it's important to use unique ids that can map to uris where possible; e.g. info:doi/34135425, urn:isbn:2345354567, etc. # series (aka volume/issuenum) , optional (not as sure how to handle these - suggestions?) volume, issue, document # pages: startpage endpage, optional, text non-contiguous pages? # venue, optional (hCard) In the work I've been doing, I've been thinking about an event relation to capture things like conferences and hearings and such. Events have dates, names (or titles?), and sponsors. # publisher, optional (hCard) # container: optional (nested hCite) There's a third level of relevance, which are collections (series and collections, but technically periodicals would be as well). # abstract, optional (blockquote + class=abstract ?) # notes, optional (blockquote + class=notes ?) # keywords, optional (rel-tag) # image, optional (for inclusion inline, unlike the url) # copyright, optional (rel-license) Per above, it's probably true these are less important, though I have no objection to them being there. Bruce ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
