Re: [uf-discuss] Multi-word tagging
On 30 Dec 2007, at 02:09, Martin McEvoy wrote: On Sat, 2007-12-29 at 23:45 +, Andy Mabbett wrote: google+search This is the best approach I think if you are building a url "+" is just a space, tags I always thought were just single descriptive words and a link to the meaning or reference (just my thought) ;) Martin I think this has come up before. Delicious uses + to add terms to a search via the 'related tags' links on a page. eg. http://del.icio.us/eatyourgreens/video+music - links tagged with the separate tags 'video' and 'music' So + can indicate a space, but doesn't always. Which means you can't necessarily relate a tag on Wikipedia, say, to a tag on flickr or delicious. For real fun with tag spaces, have a look at this URL, which relates four individual tags (I think) to provide some context to the search http://www.flickr.com/photos/tags/woolwich/clusters/ london-thames-uk/ I think the answer to the original question is - there is no standard for encoding spaces in tags, so pick the scheme that works best for you. %20 or underscores seem pretty unambiguous to me. Jim Jim O'Donnell [EMAIL PROTECTED] http://eatyourgreens.org.uk http://flickr.com/photos/eatyourgreens ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCard to represent simple entities (was: Tentative proposal...)
On 3 Jan 2008, at 23:04, Andy Mabbett wrote: For clarity, the former can be distilled to: hCard is for representing people, companies, organizations, and places Reference strings, in TEI markup at least, can also refer to the names of books, ships, plays, films and pretty much anything that can be given a name. hCard works for people and places, but is it general enough to cover those cases? It would be handy to have a general method for preserving the semantics of the tag (http://tei.oucs.ox.ac.uk/Query/tag.xq? name=rs) when converting TEI documents to HTML for delivery over the web. Particularly the contents of the type attribute, which identifies what class of thing we are referencing. Very useful when digitising historical manuscripts, diaries and letters, for example. In the past we've converted to HTML links and left it to the reader to work out whether we're referring to a person, a place or a ship. For example, the links in this letter that we digitised years ago with TEI: http://www.nmm.ac.uk/flinders/DisplayDocument.cfm?ID=110 Jim Jim O'Donnell [EMAIL PROTECTED] http://eatyourgreens.org.uk http://flickr.com/photos/eatyourgreens ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCard to represent simple entities (was: Tentativeproposal...)
On 4 Jan 2008, at 18:29, Andy Mabbett wrote: On the names thing, I suppose I could be tagging something with the name "John Smith", in which case I'd use rel-tag, or making "John Smith" available to be downloaded as a vcard, in which case I'd use hcard. The semantics of "John Smith" haven't changed between those two examples. What I want to do with the phrase "John Smith" has, so the exact microformat I'd use depends on what I want to do with the names in the end, more than their semantics. But that's dependent on what *you"* want to do. If you use more consistent mark-up, then your users, and parsers, can deal with them as they see fit. Sorry, I should have been clearer. What I want to do, in terms of marking up content, is determined by how people are going to use the web site. If people want more intelligent searches - 'show me manuscripts written by Captain Cook' - then rel-tag seems like the natural tool for marking up names. On the other hand, if people want more intelligent social networking - 'take me to Andy Mabbett's blog' - then marking up names wth hCard seems like the way forward. I don't see a use case for getting the contact details of Captain Cook. hCard does a specific job very, very well - it enhances social networking. I'm struggling to see, though, how it generalises to marking up the names of all people, living and dead. For instance, adding a tag doesn't tell a future search engine that your text is about a person. I think the answer to this is the rel-tag microformat coupled with sensible URLs to give much more intelligent tags. Imagine if the Maritime Museum archives used tags like: William Hamilton's wife the Victory Captain Cook There's enough info in the HTML there to allow for some quite intelligent searching. Classes distinguishing between the different types of tag could be added to the links too. Jim Jim O'Donnell [EMAIL PROTECTED] http://eatyourgreens.org.uk http://flickr.com/photos/eatyourgreens ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] That pesky abbrevation tag (yet again)
Hello, There are couple of markup examples on the hcard examples page which don't make sense semantically. The URL is http://microformats.org/wiki/hcard-examples#3.2.1_ADR_Type_Definition where you can see US home address, for mail and shipments: 123 Main Street Any Town, CAspan>, 91921-1234 and immediately below it Please use the following address label for local delivery to my home of mail and packages: Mr.John Q. Public, Esq. Mail Drop: TNE QB 123 Main Street Any Town, CA 91921-1234 U.S.A. None of the tags are being used to mark up abbreviations, except maybe for 'US" where the expansion should be 'United States', not 'dom'. Is there a way of setting out these examples using semantic HTML? I'm worried that people, particularly those new to microfomats, will see that microformats.org supports semantic HTML and thus infer that examples, like these, on the wiki are written in semantic markup. These, quite clearly, are not. Cheers Jim Jim O'Donnell [EMAIL PROTECTED] http://eatyourgreens.org.uk http://flickr.com/photos/eatyourgreens ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] London, England event: BarCamp on "re-use of public sector information" 12 January 2008
This sounds like something I should go to, but I believe I'm busy next Saturday too. If anyone does go, could they write it up somewhere please? Jim On 5 Jan 2008, at 13:22, Andy Mabbett wrote: Anyone in London fancy going to this, and speaking about microformats? <http://www.freeourdata.org.uk/blog/?p=168> The Office of Public Sector Information, part of The National Archives, is holding a conference to ask re-users of public sector information to shape the future of public sector information re-use. The event is open to anyone interested in public sector re-use and will take place on the 12 January 2008, at the Spey & Ness Rooms, City Inn. "The aim of the web channel is to present public sector information with a commercial value in a user friendly way that will encourage its re-use and simplify its uptake, by improving interaction between departments and end-users. The format of the final channel will have been shaped by the user community contributions through the web channel forum: <http://www.opsi.gov.uk/forums/forums/index.asp> and this BarCamp 'unconference'. "The event follows the decision to launch a web-based channel as recommended by the Power of Information report that will "improve the Government's responsiveness to demands for public sector information". If you would like to attend the event you can register and shape the agenda by visiting: <http://barcamp.org/BarCampPOIR8> "The 'unconference' will take place at Spey & Ness Rooms, City Inn, 30 John Islip Street, Westminster, London." I have added microformats to the proposed topics for discussion, even though I shall not be able to attend. -- Andy Mabbett ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss Jim O'Donnell [EMAIL PROTECTED] http://eatyourgreens.org.uk http://flickr.com/photos/eatyourgreens ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCard to represent simple entities
On 5 Jan 2008, at 16:07, Andy Mabbett wrote: Sorry, I should have been clearer. What I want to do, in terms of marking up content, is determined by how people are going to use the web site. Yes, but you don't know how people are going to use it. Yes I do. If I'm building an archive of documents related to maritime history, I've got a pretty good idea of how historians and amateur geneologists are going to use it. I don't know what sort of applications people might develop on top of our data, and I think that's where opening up museum collections gets really interesting. If people want more intelligent searches - 'show me manuscripts written by Captain Cook' - then rel-tag seems like the natural tool for marking up names. Suppose I want to know what Captain Cook drank; and that your manuscript includes a letter from Cook to a friend back home, saying "I don't miss much of home, but I could murder a pint of Mrs Hecklethump's famous beer" ...and the text referencing Cook within the letter, or article, is "James Cook" or "the captain of the Endeavour" or simply "James" but not "Captain Cook". So I need to be able to specify that I only want pages which refer to a person called "Captain Cook" - in other words, who has an hCard whose "honorary-prefix" is "Captain" and whose "given-name" is "Cook". [One day, I might also be able to search for "hBeverage" or some such (perhaps a subset of "hRecipe") instead of "beer", too.] Or, better, you want a search which finds all text tagged as referring to a person whose canonical name is "Captain James Cook." That way, you don't have to worry that your search term needs to exactly match the text, only the tag. In fact, a clever enough search could probably find all tags which are names of people and are close matches to your search term, then find all the documents tagged with those tags. Something like this search I put together for our prints collection: http://www.nmm.ac.uk/collections/prints/browseHeadings.cfm? filter=subjects&node=663 Tagging can handle this if there's a mechanism in place to put some context on the tag - indicate that it refers to a person, a place, a business or whatever. That's how using hCard adds re-usable semantics to a person's name, even if that's the only "vcard" data you publish about them. Yes, but aren't you assuming that Cook's name, including rank, will be present in the text, which won't be the case. Cook didn't sign his letters "Captain Cook". He may well have signed personal letters simply as "James". I don't see a use case for getting the contact details of Captain Cook. hCard does a specific job very, very well - it enhances social networking. I'm struggling to see, though, how it generalises to marking up the names of all people, living and dead. As explained previously, hCard is not /just/ for contact details; it's "for representing people, companies, organizations, and places". That's quoted directly from its spec. And that's how it's already being used, "in the wild". Are there any examples where it's being used for something other than social networking? For instance, adding a tag doesn't tell a future search engine that your text is about a person. I think the answer to this is the rel-tag microformat coupled with sensible URLs to give much more intelligent tags. Imagine if the Maritime Museum archives used tags like: William Hamilton's wife the Victory Captain Cook There's enough info in the HTML there to allow for some quite intelligent searching. Only if you can get everyone to use the same URL structure, and to make all the subjects in their content into links. Yes, that's why I'm interested in a lightweight, flexible solution that could be applied to archives in general, not just the holdings of the National Maritime Museum. Classes distinguishing between the different types of tag could be added to the links too. Indeed - and the appropriate class, in the latter case, would be "vcard", with "fn, "honorary-prefix" and "given name" around the content as per the hCard spec. Why would you want to invent a new set of classes? I don't, if hcard will do the job. But I also have to be able to mark up the phrase 'William Hamilton's wife' with the name 'Emma Hamilton', using the same set of classes, to indicate that she's also a person. hcard applies to one very specific subset of reference strings, those which are the exact names of people, but not to reference
Re: [uf-discuss] hCard to represent simple entities
On 5 Jan 2008, at 20:07, Andy Mabbett wrote: I don't, if hcard will do the job. But I also have to be able to mark up the phrase 'William Hamilton's wife' with the name 'Emma Hamilton', using the same set of classes, to indicate that she's also a person. If her name is elsewhere on the page,; use the "include-pattern". Hmmm, there are accessibility standards that museum sites have to achieve, which makes me nervous about using empty links without a very good reason. This is also the reason why I'm against having the pattern on our sites at work. Pepys Diary is a good example of what I have in mind for online versions of historical manuscripts: http://www.pepysdiary.com/ Wherever the original author makes a reference in their text to another person, we've got the option of linking that reference to a unique tag for that person, which could then present more info and an index of all documents tagged with that tag. With a large enough data set, we could cross reference tags to infer relationships between people, places, vessels and whatever else we represent with tags. That's something that's been at the back of my mind to do with the existing keywords in the Maritime Museum's prints & drawings archive. The more I think about this, the more it seems like rel-tag, with some additional contextual info, is the most elegant solution to handling the problem of how to handle the TEI tag in HTML. If not, you're introducing "hidden metadata". I don't think so - that's covered in the rel-tag spec, so I'm fine with using tags in this manner. See: http://microformats.org/wiki/rel-tag#Tags_Are_Visible_Metadata Cheers Jim Jim O'Donnell [EMAIL PROTECTED] http://eatyourgreens.org.uk http://flickr.com/photos/eatyourgreens ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] That pesky abbrevation tag (yet again)
On 5 Jan 2008, at 19:10, Sarven Capadisli wrote: As far as I know, the examples are focused more on the "type"s that are being used instead of semantic markup. Indeed, but people will take the code examples on the wiki as examples of best practice and copy them. The w3c added and the title attribute on all elements as accessibility enhancements to HTML. I think that one has to bear that in mind when giving examples of how to use them in real world markup. See http://www.w3.org/TR/html4/intro/intro.html#h-2.3.2 Is it feasible to change the hCard parsing rules so that the content of title is used, if present, for class="type", no matter which element the class is present on? Jim Jim O'Donnell [EMAIL PROTECTED] http://eatyourgreens.org.uk http://flickr.com/photos/eatyourgreens ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCard: url and tel
On 6 Jan 2008, at 04:20, ryan wrote: eg. Phone Q2. Would it be possible to do something like this, instead? Phone @title is only used for abbr for many reasons. I think we have an FAQ for it somewhere, but can't seem to find it right now. There's one near the bottom of http://microformats.org/wiki/faq but it only mentions dates and times. Types don't work as abbreviations because you can't replace the word 'shipments' with 'parcel', or 'US' with 'dom'. Jim Jim O'Donnell [EMAIL PROTECTED] http://eatyourgreens.org.uk http://flickr.com/photos/eatyourgreens ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] That pesky abbrevation tag (yet again)
On 6 Jan 2008, at 03:39, Paul Wilkins wrote: Is it feasible to change the hCard parsing rules so that the content of title is used, if present, for class="type", no matter which element the class is present on? It was decided to not go that way. Authors commonly have other title attributes in microformat sections that are not supposed to be interpreted as machine data. Authors would have to retrofit their existing code and remove existing titles from all affected microformat sections. So what's the way forward? Shrug our shoulders and accept for types as a kind of 'spacer-gif' for microformats? Surely there's a way to solve this without encouraging authors to misuse HTML. Jim Jim O'Donnell [EMAIL PROTECTED] http://eatyourgreens.org.uk http://flickr.com/photos/eatyourgreens ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Hcard - marking up sms short codes
On 8 Jan 2008, at 19:13, Philip Tellis wrote: On 08/01/2008, Andy Mabbett <[EMAIL PROTECTED]> wrote: Good point. The nearest at the moment is "type=cell", but since such numbers usually cannot be dialled for voice calls, that's not really I don't understand this. Why can't type=cell be dialled for voice calls? I think the problem is that they can, but SMS short numbers can't. Jim Jim O'Donnell [EMAIL PROTECTED] http://eatyourgreens.org.uk http://flickr.com/photos/eatyourgreens ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] xfn and biographies
Hello, At work, I'm kicking around microformats as a method for adding additional semantic information to archives - letters, diary entries, log books and so on. I blogged a little about this already - using rel-tag to tie together related materials: http://eatyourgreens.org.uk/archives/2008/01/microformats_an_1.html Does anyone have any thoughts on using xfn (or some variant thereof) to add machine-readable relationships to published biographies? Or in general, to express the relationships that exist within the network of people associated with an archive of published writing? A specific example is the link from http://www.nmm.ac.uk/flinders/ListPeople.cfm?ID=41 to http://www.nmm.ac.uk/flinders/ListPeople.cfm?ID=96 (near the end of the biography) where I could potentially mark that Ann is the daughter of Matthew. If xfn is embedded inside a hcard, does it refer to the person referenced by the hcard as the source of the relationship? Would I also need to somehow markup "Flinders, Matthew" with a URL so it's explicit, to a parser, which Matthew Flinders we're talking about? Also, the rel attribute on links seems handy for expressing relationships between letters and their authors, or letters and their recipients, or even letters in a series of correspondence. Does anyone know if there are any examples of this out there already? I'll try to mock up some prototype pages next month, but thought I'd get comments from people with practical experience of using microformats before I start. Thanks Jim Jim O'Donnell [EMAIL PROTECTED] http://eatyourgreens.org.uk http://flickr.com/photos/eatyourgreens ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Re: xfn and biographies
On 23 Jan 2008, at 20:44, Toby A Inkster wrote: Jim O'Donnell wrote: Also, the rel attribute on links seems handy for expressing relationships between letters and their authors, or letters and their recipients, or even letters in a series of correspondence. Does anyone know if there are any examples of this out there already? rel/rev="made" is in common usage. You could use rel="made" when linking from author to letter, and rev="made" for the reverse relationship. letter-to-author is the relationship I'm really interested in, in the sense of 'show me all letters by the same author' or 'show me all correspondence in this series'. Rev seems a bit of a dead-end, but I had thought of maybe using rel="author" on a link to the author. Or I could go for consistency with Dublin Core, since that's commonly used in archives, and use rel="creator". Has anyone done any work on simple microformat class names based on the Dublin Core element set? To link letters in a series of correspondence there is of course rel="next" and rel="prev". Also rel="first" and rel="last" may prove easy, and rel="contents" to get back to the full listing of letters. Yeah, that's what I'd thought of doing but I hadn't considered the fact that each letter is several pages in itself. So there's next and prev in terms of navigating within a letter, and then next and prev in the context of moving between letters in a series. I don't think there'll be one definitive table of contents. I'm not decided on this yet, but at the moment I envisage several methods of listing the contents - indexed by author, by time, by recipient or by places and vessels referenced within the text. Not sure about linking recipients to letters. You may need to define your own rel/rev="recipient". That would make sense. Looking at the texts, I've realised that the recipient is not always the person that the letter is addressed to. Eg. he addresses a letter to Rev. Tyler but it's intended for his wife. I think I may have to publish author and recipient alongside each letter, rather than marking them up directly in his text. Cheers Jim Jim O'Donnell [EMAIL PROTECTED] http://eatyourgreens.org.uk http://flickr.com/photos/eatyourgreens ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Possible alternative methods for "include"
Is the include pattern really necessary, for hResume at least? Given that each hCard describing a previous position is enclosed inside a hResume, and given that the resume itself has a card with contact details, including an fn for a person, can't a parser allow the enclosed hCards to inherit the fn from that top-level hCard? Alternatively, following on from the discussions here about cards for places and organisations, couldn't an author mark up the organisation in a previous position with class="fn org", thus obviating the need for a separate fn in the first place? Jim Jim O'Donnell [EMAIL PROTECTED] http://eatyourgreens.org.uk http://flickr.com/photos/eatyourgreens ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Re: xfn and biographies
On 26 Jan 2008, at 19:07, Andy Mabbett wrote: In message <0F667B0C-8A0D-4345-AF3B- [EMAIL PROTECTED]>, Jim O'Donnell <[EMAIL PROTECTED]> writes letter-to-author is the relationship I'm really interested in That sounds like a situation where you would use the putative "citation" microformat which will hopefully include an "author" or "creator" property, utilising hCard. I'm thinking, at the moment, of avoiding hCard completely in the letters themselves, basically to avoid all the horrible issues of ambiguity and irregularity of names. For example, where Flinders signs this letter 'Matt'w Flinders' http://www.nmm.ac.uk/flinders/DisplayDocument.cfm? ID=110&CurrentPage=1&CurrentXMLPage=3 I'll just mark that link up using rel="tag", where the tag URL points to the biography currently at http://www.nmm.ac.uk/flinders/ListPeople.cfm?ID=41 then use hCard to mark up Flinders as a person on that page. I think what I'm saying is have one hCard per person on the site, which is the biography page, then link to those hCards as tags within the letters. That seems a lot easier than faffing around with citations and different types of hCard. In turn, such hCards could then use the proposed "definitive hCard", "more-detailed hCard" or "parent hCard" property (perhaps rel="expansion") to indicate the page 0or page-fragment, using an ID) on which your definitive biography of the author resides. Thinking out loud here - I'm not hugely concerned about a definitive biography, as long as the relationships between documents at different URLs are clearly defined. For instance, suppose I have a biography, and hCard, for Flinders at /tags/people/Matthew_Flinders. I could have a link from that page to http://en.wikipedia.org/wiki/ Matthew_Flinders and mark it rel="me" to indicate that the two URLs describe the same person. If my biography links to a letter, and that link says rel="creator", then I think it's reasonable for a parser to infer, from the rel="me" link, that http://en.wikipedia.org/wiki/Matthew_Flinders also describes the creator of the letter. I don't think I need to state that my hCard is definitive, only that it's equivalent to the one at wikipedia. I suppose it would be interesting to have a mechanism to mark up equivalence in general, not just for people. For example, to link the description of Boston http://www.nmm.ac.uk/flinders/ListPlaces.cfm?ID=6 to the wikipedia page for Boston http://en.wikipedia.org/wiki/Boston%2C_Lincolnshire using whatever the equivalent of rel="me" would be for places. Ditto for pages describing vessels, if the vessel has a wikipedia page. Then, a letter tagged with a link to the short description of Boston would, indirectly, also be tagged with the wikipedia description, as well as being linked back to all references to that place in the archive. Jim Jim Jim O'Donnell [EMAIL PROTECTED] http://eatyourgreens.org.uk http://flickr.com/photos/eatyourgreens ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Fwd: [uf-discuss] Re: xfn and biographies
Begin forwarded message: If my biography links to a letter, and that link says rel="creator", then I think it's reasonable for a parser to infer, from the rel="me" link, that http://en.wikipedia.org/wiki/ Matthew_Flinders also describes the creator of the letter. I don't think I need to state that my hCard is definitive, only that it's equivalent to the one at wikipedia. Oops, that was the wrong way around. I meant that if a letter links to the NMM biography, with rel="creator" on that link, and the NMM bio then links to wikipedia, with rel="me", then a microformats spider should be able to infer that the wikipedia page describes the author of the letter by following the chain of links and looking at the rel attributes. Jim Jim O'Donnell [EMAIL PROTECTED] http://eatyourgreens.org.uk http://flickr.com/photos/eatyourgreens ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Re: xfn and biographies
I'm thinking, at the moment, of avoiding hCard completely in the letters themselves, Why? It adds good, semantic mark-up. Practical reasons, really. The names in the letters aren't marked up specifically as names, or regularised in any way. The HTML is generated, not manually authored. The underlying XML looks something like Matt'w Flinders but, equally, the text inside the tag could refer to Flinders as Captain Flinders, or use some other text to refer to him. So I can't write an XSL transform to generate specific markup for particular cases, such as wrapping "Matt'w" in . I think this is one point that will come out of this project - to what level of granularity is it useful for the people transcribing a document to mark up the semantics of the contents. These particular papers have been marked up with references, but nothing more specific than that. Also, should we expect the people doing the transcribing, who are not web designers or developers, to have a knowledge of microformats, or should we provide tools to do the hard work for them. I'll just mark that link up using rel="tag", where the tag URL points to the biography currently at http://www.nmm.ac.uk/flinders/ListPeople.cfm?ID=41 then use hCard to mark up Flinders as a person on that page. I think what I'm saying is have one hCard per person on the site, which is the biography page, then link to those hCards as tags within the letters. That seems a lot easier than faffing around with citations and different types of hCard. It may be easier, but is it better? I don't think it's worse. We don't know, from the markup, that the string 'Matt'w Flinders' is a name but we do know that it's a reference to a hCard, and that hCard in turn can give us a name and URL (or URLs) for Flinders. Plus we have a network of documents that reference the same hCard, which is more useful, as a library tool, than a set of hCards which might be harder to link together. Jim Jim O'Donnell [EMAIL PROTECTED] http://eatyourgreens.org.uk http://flickr.com/photos/eatyourgreens ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Unjust banning of Andy Mabbett
On 8 Mar 2008, at 21:45, Manu Sporny wrote: I just got back from vacation, otherwise this would have gone out sooner. It has come to my attention that Andy Mabbett has been banned by the admins for 18 months[1]. This is an unjust punishment, especially considering that he is one of the largest contributors to our community. Rather than make sweeping assertions and accusations, I'm going to back this post up with hard data. Here are the statements that will be addressed: I agree completely. An 18 month ban is completely unjustified. Jim Jim O'Donnell [EMAIL PROTECTED] http://eatyourgreens.org.uk http://flickr.com/photos/eatyourgreens ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Unjust banning of Andy Mabbett
On 8 Mar 2008, at 21:45, Manu Sporny wrote: Andy was tried as guilty, without complete documentation There is still no documentation as to what Andy has done in the past to warrant this type of ban. In the admin's post to the list, the following was mentioned: As time permits, the admins will both hyperlink each of those annotations to the specific email in the archives or edit in the wiki history that caused it, as well as annotate any remaining rules with their causes as well. We believe this will help provide better transparency and accountability. The time to generate transparency and accountability is BEFORE a ban, not after. This is why people are tried as innocent in most parts of the world - you may discover that what you think to be evidence against Andy falls down upon closer examination. This sends a dubious message indeed - "The admins can ban you and then, ex post facto, document the reasons why they banned you". This is backwards. I think Manu raises an important point here - unlike Wikipedia, there's no clear dispute resolution process for microformats.org. Decisions appear to be made in camera, and released to the group after the fact. That itself could also dissuade people from becoming involved with microformats. If I may ask, how many admins voted to ban Andy, and what was the count on that vote? Also, would it not have been polite, at the very least, for someone to warn Andy that this ban was under consideration, and inform him that he had been banned after it was put in place. Jim Jim O'Donnell [EMAIL PROTECTED] http://eatyourgreens.org.uk http://flickr.com/photos/eatyourgreens ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Operator 0.9.1
I can confirm this - Operator finds the address regardless, but only finds the name 'Andrew Jaswa' if 'show hidden microformats' is ticked. Jim On 21 Mar 2008, at 13:29, Andrew Jaswa wrote: Once I find out some more I'll share. Alright so here is what I found out: Op. 0.9.1 does not find the hCard when the nested divs are floated. I've also noticed that when the "Show hidden Microformats" is checked Op will find the hCard. My sample file is found at: http://gotkicked.net/research/uf/ opbug.html Can someone else please confirm this? Andrew Jim O'Donnell [EMAIL PROTECTED] http://eatyourgreens.org.uk http://flickr.com/photos/eatyourgreens ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Re: One more shot at accessible hCalendar
On 17 May 2008, at 23:14, Adam Craven - Four Shapes wrote: I'm wondering, can you also configure screen readers to expand out titles on any elements? Not as far as I'm aware. Titles may be read out for links, images, form elements and abbreviations and that's about it. I definitely remember Steve Faulkner saying that he's not aware of any AT that will read title on a span. Jim Jim O'Donnell [EMAIL PROTECTED] http://eatyourgreens.org.uk http://flickr.com/photos/eatyourgreens ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] hoard.it
Hello, This might be of interest to members of this group, as it deals with extracting data from semantic HTML. Prior to this year's Mashed Museum event at the University of Leicester, Dan Zambonini put together a prototype which aggregates data by spidering online museum catalogues: http://hoardit.pbwiki.com/ It's a pretty fantastic demo of how information can be extracted from well-structured HTML, even before you think of putting microformats etc. on top. In particular, it does a pretty good job of figuring out when an object was made: http://feeds.boxuk.com/museums/object_100yrs.php The date parser is based on some code Dan & I knocked together at Mashed Museum 2007, which looks at strings like 'late Victorian', 'early 20th Century', '4th January 1853' and so on, and converts them to machine-readable ISO dates. Our original idea, which we never got round to actually implementing, was that this would be useful as a web service - you give it a string, it gives you a machine-parsable representation of that string. The recent discussion here about dates has made me wonder if such a web service woud be useful for microformats parsers. What do others think? Cheers Jim Jim O'Donnell [EMAIL PROTECTED] http://eatyourgreens.org.uk http://flickr.com/photos/eatyourgreens ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hoard.it
Thanks. I don't know what Dan did for hoard.it, but our original script treated 'about' or 'circa' as the date plus/minus five years. So 'circa 1800' would be returned as '1795/1805'. For 'before' or 'after', you could return a pair of dates with either the first or second blank, accordingly. This is assuming we encode time periods as per the guidelines in the PNDS application profile: http://www.ukoln.ac.uk/metadata/pns/pndsdcap/ #DctermsTemporalDctermsPeriod Jim On 8 Jul 2008, at 06:02, Bob Jonkman wrote: Sounds great! How does it deal with dates commonly found in genealogy, such as "ABT 7 July 1950" or "AFT 25 Dec 2000" or "BEF Jan 1925"? or even "ABT 2000 ? --Bob. Jim O'Donnell [EMAIL PROTECTED] http://eatyourgreens.org.uk http://flickr.com/photos/eatyourgreens ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hoard.it
On 8 Jul 2008, at 06:45, Guillaume Lebleu wrote: Jim O'Donnell wrote: The recent discussion here about dates has made me wonder if such a web service woud be useful for microformats parsers. What do others think? It seems to me that this type of date extraction might present risks if used by uf parsers to extract date/time from published content (and lead to the "people showing up on the wrong date" error mentioned in earlier posts). I don't think it's so risky. The inspiration for this particular work was Dan's experience on the 20th century London site: http://www. 20thcenturylondon.org.uk/ which involved parsing and normalising text dates across four different collections. Granted it's tedious to analyse all the different patterns that have been used, but it isn't impossible to extract accurate ISO dates. The fact that archive was created from those four collections is a testament to that. Museum catalogue records always have some sort of absolute date, though, which makes things easier for me. If people are marking up phrases like 'this Saturday' or '25th June' then I can see that extracting a date would be tricky - the parser would need the context within which to place the date, in order to get the year or month. That said, I don't how often people use hcalendar to mark up phrases like 'next weekend' vs, say, 'Saturday 19th July 2008'. If we had some idea of how microformats are being used to mark up dates in real, online text, then we could make some meaningful statements about how risky, or even impossible, it might be to extract ISO dates automatically. On the other hand, it might be great at the time content is authored, to convert ambiguous natural language dates into unambiguous microformats, as a way to reduce the pain of micro- formatting content (especially it can detect dates in plain text rather than parsing something it knows is a date). Authors could confirm the generated microformats before publishing in a way similar to how Yahoo! shortcuts Wordpress plugin works [1] Decent authoring tools would be brilliant. Not just for dates but locations and possibly other types of microformatted text. For instance, I can link a UK street address to Google maps and get back a precise point on a map of the UK. So do I really need to manually write a lat/long into the HTML to tell a microformats tool how to place the address on a map? The text contains all the necessary information to perform this operation already. I think microformats should be relatively easy for a non-technical author to add to their text. Decent tools that generate the machine- readable data would be an enormous aid here. Jim Jim O'Donnell [EMAIL PROTECTED] http://eatyourgreens.org.uk http://flickr.com/photos/eatyourgreens ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hcard: additional additional names
Hi MIchael, Unfortunately the data I'm working with would have O'Connor as one field and the sort letter would be 0. So you'd appear on ../o I fear But even if you were indexed as D and appeared under ../d you'd appear there as: O'Donnell, Jim That's fine - that's exactly how it should be written. The surname is written O'Donnell (not Donnell) but is indexed/sorted under D. And not: Donnell, Jim O' Whereas beethoven has van as a separate field and an index letter of B. So he appear under ../b as: Beethoven, Ludwig van Talking to colleagues with more library background than me the attachment/detachment does appear to be subject to enormous cultural variation particularly with van and vons I had a quick look through some of our Dutch items at work. The way names are displayed varies between catalogues. Sometimes the surname is listed without the 'Van': http://www.nmm.ac.uk/collections/search/listResults.cfm?Maker=Keulen% 2C%20Johannes%20van&SortBy=maker Sometimes with http://www.nmm.ac.uk/collections/prints/listPrints.cfm? filter=makers&node=8767 and sometimes the name is simply written out as it would be spoken: http://www.nmm.ac.uk/collections/explore/people.cfm/id/22357 I don't know if that helps, or just makes the whole situation more confusing. I imagine Spanish names, with the matrimonial surname, must be fun to deal with too :) Jim Jim O'Donnell [EMAIL PROTECTED] http://eatyourgreens.org.uk http://flickr.com/photos/eatyourgreens ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hcard: born and died and flourished
Hi Michael, On 21 Aug 2008, at 13:28, Michael Smethurst wrote: Where either date is circa I've included ca. in the span with bday, dday, flourished-start or flourished-end: ca. 1575-ca. 1614 You could represent fuzzy dates as two timestamps seperated by a slash, as per http://www.ukoln.ac.uk/metadata/pns/pndsdcap/ #DctermsTemporalPndstermsISO8601Per eg. ca. 1575 could be written as 1570-01-01/1580-12-31 or you might be able to just get away wth 1570/1580. I'm not quite sure how you'd represent that in HTML, but it is a standard for representing periods of time. Oh, and I suppose with dates that far back there'll be calendar issues with Julian vs. Gregorian and what day does the year begin if you get into days and months and comparing dates from different parts of Europe. I have to admit I generally ignore those since the uncertainty in dates for works of art and the like is usually much bigger than any difference introduced by different calendars. Jim Jim O'Donnell [EMAIL PROTECTED] http://eatyourgreens.org.uk http://flickr.com/photos/eatyourgreens ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] OpenCalais automates microformatting of content
I'm afraid I've got no direct experience of opencalais mself, but the Powerhouse Museum in Sydney have been using it to tag their catalogue records with people, places and so on. Seb Chan blogged about it in March: http://tinyurl.com/semantictagging I'm not sure if they carried on with this experiment, but the initial examples on Seb's blog seemed impressive. At this year's Mashed Museum in Leicester, Steve Pope from Eduserve also did some interesting stuff running text from online museum catalogues through opencalais, which gets a bit of a mention here: http://electronicmuseum.org.uk/2008/06/27/mashed-museum-2008/ Jim On 8 Sep 2008, at 18:59, Chris Messina wrote: I actually stumbled upon this from a Google AdSense link, but there's some interesting stuff going on at http://opencalais.com/. This project was mentioned back in February and at the time, was primarily dedicated to adding RDFa output to blog posts. Well, I guess they saw the light and now have an API that will add microformats to your blog posts, based on semantic analysis: http://opencalais.com/about It's being powered/sponsored by Reuters, so you can imagine why they're interested in this (basically being able to remine all the content they have in all their many news archives and databases). If you want to get into the good stuff, visit their tools page: http://opencalais.com/tools The most interesting projects are: Calais Marmoset - http://opencalais.com/Crawler Tagaroo - http://tagaroo.opencalais.com/ (Alex King's CrowdFavorite contributed to this project) Gnosis - http://opencalais.com/Gnosis Now, I haven't really played with the API, and I'm a little wary of their actual microformats output, but you can get a sense for what they're doing on this page: http://opencalais.com/Microformats If anything, I think there's some real promise to this approach and love the idea of being able to automatically microformat content as it's published to a blog or output from a CMS. Can anyone take a look at this and give us a sense for how good these tools are? Chris -- Chris Messina Citizen-Participant & Open Source Advocate-at-Large factoryjoe.com # diso-project.org citizenagency.com # vidoop.com This email is: [X] bloggable [ ] ask first [ ] private Jim O'Donnell [EMAIL PROTECTED] http://eatyourgreens.org.uk http://flickr.com/photos/eatyourgreens ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
