Re: [uf-new] SERP proposal
On 07/09/2010 13:50, Dan Brickley dan...@danbri.org wrote: On Tue, Sep 7, 2010 at 2:40 PM, Emanuele Minotto minottoemanu...@gmail.com wrote: I propose a model for representing search results pages (SERP), analyzing the results of a sample of search engines you may notice that many elements have the same goal but nobody is represented equally. As a sample I took a SERP of the following search engines: Google, Bing, Cuil, Yahoo, Ask, Baidu, Wikipedia. (Where possible, in English) The general elements of a search page are: - Number of results : 100% of the sample - Page : 100% - Number of first result on the page, last result on the page number : 100% - Link to advanced search : 100% - Seek time : 28% While the elements of a single snippet are: - Title : 100% - Description : 100% - Address : 85% - Copy into the cache : 57% Having said that I'd know what you think to identify a results page with microformats. Perhaps it might be worth distinguishing between the big, global search engines and smaller eg. per-site-search pages. The big sites (i) have massive load, and change their markup very carefully; (ii) are careful about exposing APIs and scraping. These are the ones with 'cache' links. Smaller search sites - I think these are much more likely to deploy a microformat. I image much could be handled via http://microformats.org/wiki/hatom with some of the extras you indicate above. Did you see http://www.opensearch.org/Home ? seems quite close... Slighty off topic but glancing thru: http://www.opensearch.org/Specifications/OpenSearch/1.1 And seeing count, start index, start page etc made me wonder if pagination helpers in general might be a useful pattern for microformats / posh? OpenSearch is a collection of simple formats for the sharing of search results. ... The OpenSearch response elements can be used to extend existing syndication formats, such as RSS and Atom, with the extra metadata needed to return search results. http://www.opensearch.org/Documentation/Recommendations/OpenSearch_and_microfo rmats is probably the best starting point... cheers, Dan ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new http://www.bbc.co.uk/ This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Microformats for hidden data
On 26/11/2009 17:33, Fiann O'Hagan fia...@jshub.org wrote: Hi Fiann Hi Toby Have you considered using RDFa? This is a set of XHTML attributes which brings the RDF data model to XHTML. (Many parsers also support tag soup HTML too.) My understanding of RDFa is that it's not possible to include in valid XHTML 1.0 If you want to serve rdfa you'll need to use an rdfa doctype: !DOCTYPE html PUBLIC -//W3C//DTD XHTML+RDFa 1.0//EN http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd; It's the only change you need to make and is fully supported by w3c validators and that in any case there are problems with serving pages with an XML mimetype rather than text/html. There are all kinds of problems serving pages as xml but it's not required for rdfa - just keep serving as text/html Do you have any real-world examples of RDFa being published? The canonical example is the london gazette: http://www.london-gazette.co.uk/ We're also using a very small dash of rdfa on bbc.co.uk: http://www.bbc.co.uk/music/reviews/66gb ...with plans to add much more to bbc.co.uk/programmes in the near future I can see you have created a parser, but I am not aware of many examples outside of the W3 site. I'm interested in RDFa but I do find the arguments in Tantek's mail from this list quite compelling http://microformats.org/discuss/mail/microformats-discuss/2006-May/004144.html I'd be interested to know if anything has changed in the last 3 years. Fiann ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new http://www.bbc.co.uk/ This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Re: hAudio issue: position
I suspect I've thrown a red herring into the mix with the mention of classical music... apologies My point was really that when a track from an album is played in isolation from that album (so on a radio episode tracklist or in a personal playlist) the track position on the album is still important data. Which means encoding this data as a property of the list ordering wouldn't work here. So I'd vote to keep position as a separate attribute I threw classical into the mix cos sometimes multiple tracks on an album can have the same title (dependent on how the record company has segmented the audio). In this case the track number is necessary to disambiguate which track was played The same is also true of audio books which often have multiple tracks per chapter all having the same chapter title. Somewhat embarrassingly my ipod currently contains Alan Bennett reading The Wind in the Willows were: Track 1 = The River Bank Track 2 = The River Bank Track 3 = The Open Road Track 4 = The Open Road Etc In terms of marking up acts and scenes and movements and works and etc I'd encourage hAudio to steer well clear. It's a hideous minefield and I suspect hAudio can solve 80% of the problem by avoiding this stuff. For an idea of the complexity I'd point semweb minded people at the fine work of Yves Raimond on the music ontology (which incidentally it would be nice to see used in the rdf-a hAudio spec): http://musicontology.com/ On 14/1/08 17:43, Andy Mabbett [EMAIL PROTECTED] wrote: On Mon, January 14, 2008 17:19, Michael Smethurst wrote: In the case of classical music identifying the track played by ordinality on the release is extremely useful. So a way to markup ordinality other than as a list would be preferable In the following, for piece read piece, sequence or some other term: foo class=item start-piecePiece 1, part 1/foo foo class=itemPiece 1, part 2/foo foo class=itemPiece 1, part 3/foo foo class=item end-piecePiece 1, part 4/foo foo class=item start-piecePiece 2, part 1/foo foo class=itemPiece 2, part 2/foo foo class=itemPiece 2, part 3/foo foo class=item end-piecePiece 2, part 4/foo or: foo class=piece foo class=itemPiece 1, part 1/foo foo class=itemPiece 1, part 2/foo foo class=itemPiece 1, part 3/foo foo class=itemPiece 1, part 4/foo /foo foo class=piece foo class=itemPiece 2, part 1/foo foo class=itemPiece 2, part 2/foo foo class=itemPiece 2, part 3/foo foo class=itemPiece 2, part 4/foo /foo though the latter again causes problems in tables (unless a TBODY is used for each piece; which is arguably good practice). Item is an absolutely awful (and semantically-barren) name; it might be best to use piece and subpiece or something like that, assuming that the piece's name is shown (unlike the above examples). Perhaps you have some real examples in mind? How any levels of sub-division are there? I have recently posted links to others' efforts to solve the problem of codifying the structure of disparate types of music: http://tinyurl.com/2uval5 on the wiki. In particular, see: http://oakroadsystems.com/genl/itunes.htm http://www.bbc.co.uk/ This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Re: hAudio issue: position
On 15/1/08 16:18, Manu Sporny [EMAIL PROTECTED] wrote: Michael Smethurst wrote: In terms of marking up acts and scenes and movements and works and etc I'd encourage hAudio to steer well clear. It's a hideous minefield and I suspect hAudio can solve 80% of the problem by avoiding this stuff. Hmmm... Perhaps I'm missing something, but hAudio can already mark up operatic pieces: http://microformats.org/wiki/haudio#Opera_Example POSITION is a loose descriptor of where the piece fits in if it is part of a collection of some kind. It is most useful when the other pieces are not listed on the same page. Position can be: 1. The position of the track on a CD. 2. Podcast # of the recording. 3. The position on a top-10 list. 4. The physical position on a CD set of an Operatic piece. 5. The side and track # of an LP (ie: A1, B2) 6. Specified in TABLE elements. 7. Can be specified out-of-sequence. I don't think we avoided the problem when putting position in there... it takes on the challenges of positional identifiers for audio recordings. If we take position out of the hAudio spec, we lose support for all of the use cases listed above. Again I apologise. I didn't mean that hAudio doesn't handle positioning in these groups. It does and again I vote to retain position as is Just meant that in general haudio doesn't model works vs performances vs recordings etc. And again I don't think it should attempt to touch this complexity Which I think means we're in agreement?!? For an idea of the complexity I'd point semweb minded people at the fine work of Yves Raimond on the music ontology (which incidentally it would be nice to see used in the rdf-a hAudio spec): http://musicontology.com/ There will probably be multiple OWL mappings from hAudio RDF to MusicOntology RDF... for example: owl:Class rdf:ID=Recording owl:equivalentClass rdf:resource=http://purl.org/ontology/mo/Recording/ /owl:Class cool I've been thinking about heavy re-use of MusicOntology (which is great, if you need to do more than just markup albums/tracks). The big mistake I think the MO folks made was putting properties in there that should have been just plain URIs: http://musicontology.com/#term_myspace http://musicontology.com/#term_amazon_asin http://musicontology.com/#term_musicmoz I'll let yves fight his own corner here ;-) It's so incredibly heavyweight that it makes most people's heads spin when attempting to just simply mark up a song. That being said, there will still be mappings from one to the other (or re-use of some of the MO vocabulary in the hAudio RDF. Smashing! -- manu ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new http://www.bbc.co.uk/ This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Re: hAudio issue: position
On 12/1/08 20:48, Andy Mabbett [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED], Martin McEvoy [EMAIL PROTECTED] writes Hello Andy On Fri, 2008-01-11 at 20:27 +, Andy Mabbett wrote: I think that providing an alternative to OL in that manner, not to mention encouraging people to use it by having it as an example in the spec, is no better then p class=heading I am not going to argue with you on that point I agree in principle, but unlucky for us the real world is much different to the world we are trying to create, you know as well as I that a lot of designers still use tables for layouts, most are not interested in validating their documents, or understand semantics beyond web3.0(yuck) or twine(lol), I really don't think we should accord such bad behaviour credit by catering for it at the expense of good practise. , in order to be adopted, this is why the compromise, allow authors to publish hAudio in tables (If they so wish) and so making hAudio easier to adopt. hAudio in tables is a separate issue to bad mark-up, Tables may well be valid, semantically-correct and the best way to mark up a page about number of audio recordings. The use of microformats in tables is itself an issue in need of further thought. For example (this is an illustrative question, not a proposal), should: th class=fn scope=rowName/fn indicate that each cell in that column is to be treated as an FN if there is, say, a vCard across that cell's row? If not, how else might that be achieved? Marking up audio in tables makes perfect sense in many cases Given a tracklist for a radio programme it's a tuple of artist, track name, release title, label, possibly track position on release. Which looks like a table to me. Even if marked up as an ordered list the implied ordinality would be that of the track in the programme episode, not that of the track on the release In the case of classical music identifying the track played by ordinality on the release is extremely useful. So a way to markup ordinality other than as a list would be preferable http://www.bbc.co.uk/ This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio ITEM debate proposal #3
On 29/10/07 12:46, Manu Sporny [EMAIL PROTECTED] wrote: Julian Stahnke wrote: I like it! So, to clarify, would a single track be marked up like this? span class=haudio span class=fnTwo Sleepy People/span span class=contributorSilje Nergaard/span /span And a track from the album At First Light¹: span class=haudio span class=fnTwo Sleepy People/span span class=contributorSilje Nergaard/span span class=albumAt First Light/span /span Yes, that would be the proper markup based on the current proposal. Again not wanting to muddy any waters but it seems like we're trying to capture 2 forms of containment here: - using nesting + item to indicate containment of - using album to indicate containment by Is there any mileage in pushing for class=hasPart and class=isPartOf? It would bring things into line with dublin core but my be a little triple-y for these parts -- manu ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new http://www.bbc.co.uk/ This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio proposal: ITEM/TRACK
3 quick questions: 1. how would this work for a tracklist for a radio/tv programme. Like this?: span class=haudio span class=fnNagasaki Nightmare/span span class=albumBest Before 1984/span span class=contributorCrass/span /span span class=haudio span class=fnThe Classical/span span class=albumHex Enduction Hour/span span class=contributorThe Fall/span /span Or should the whole thing be wrapped in an haudio with haudio items? 2. how would it work for a live performance by a single artist span class=haudio span class=contributorThe Fall/span span class=itemThe Classical/span span class=itemFrenz/span span class=itemContainer Drivers/span /span In which case should album be mandatory for a top level haudio with items? 3. can you have infinite nesting of item/haudios to handle the modelling of classical music? Again no mandatory album On 14/10/07 21:01, Manu Sporny [EMAIL PROTECTED] wrote: The problem: We need some sort of container to hold track/song information in an hAudio album. The contents of this container will be another hAudio chunk or text (which will be the FN of an hAudio object). There are two proposals that are on the table right now. The end result and semantics for hAudio are the same, the only thing that we are discussing is the name of that container. TRACK or ITEM Using TRACK means creating a new Microformat property that, while specific, is not re-using ITEM. There is also contention over whether this accurately describes a part of an album. Using ITEM means that we will be changing the current definition of ITEM: --- item - hReview - The item that the object exists for. For example, a review about Coca-Cola would list Coca-Cola as the item.[1] item info:: This required field MUST have at a minimum the name (fn - the formatted text corresponding to the name, except for an event item which MUST have the summary property inside the respective hCalendar vevent) of the item (an hReview describes only one item), SHOULD provide at least one URI (url) for the item, and MAY provide at least one URL to a photo or depiction (photo) of the item. For items of type person or business, the item info (fn, url, photo) MUST be encapsulated in an hCard. For items of type event, the item info SHOULD be encapsulated in an hCalendar vevent. Non-URL unique item IDs (e.g. ISBNs, UPCs) MAY be represented as a URN (url) for the item. Encapsulated microformats (e.g. hCard and hCalendar events for now) may be set on the item itself (e.g. class=item vcard). However, when using item info subproperties (fn, url, photo), they MUST be nested inside the item element.[2] item info:: This required field MUST have at a minimum the name (fn - the formatted text corresponding to the name) of the item , SHOULD provide at least one URI (url) for the item, and MAY provide at least one URL to a photo or depiction (photo) of the item. For items of type person or business, the item info (fn, url, photo) SHOULD be encapsulated in an hCard. Unique item IDs (e.g. ISBNs, UPCs) MAY be represented as a URN (url) for the item.[3] --- However, it seems that there is support from a number of people to re-use ITEM because it achieves two things (moves hAudio forward AND simultaneously creates a generic bag/hset/container concept for Microformats... something that we've been attempting to do for over a year. We don't want to break backwards compatability, so we have to work with the current definitions of item for hReview and hListing by defining ITEM as the following, which can be used across all Microformats: --- ITEM - A generic method that Microformats use for unordered containment of other Microformat properties or objects. This property MUST have, at a minimum, the name of the item. The name of the item can be specified using either: a) plain-text, if the property contains only the name of the item. b) fn, if the property contains multiple Microformat properties. ITEM MAY contain other properties/Microformats, but anything other than FN must be defined by the Microformat that is using ITEM. --- The above definition doesn't require hReview or hListing to change at all. It also means that we can use it like so in hAudio: Single track, with known album (same as putting text in the album¹ field of an ID3 tag): span class=haudio span class=fnNagasaki Nightmare/span span class=albumBest Before 1984/span span class=contributorCrass/span /span Single track, album unknown: span class=haudio span class=fnNagasaki Nightmare/span span class=contributorCrass/span /span Album: span class=haudio span class=fn albumBest
Re: [uf-new] item property (was: hAudio: audio-title/album-title vs. recording/album)
On 14/10/07 20:01, Manu Sporny [EMAIL PROTECTED] wrote: Martin McEvoy wrote: album-title is NOT mandatory. It is only mandatory when you're listing one or more TRACKs. Tracks can be grouped by more than just albums. I'd say album-title should never be mandatory -- manu ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new http://www.bbc.co.uk/ This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] item property (was: hAudio: audio-title/album-title vs. recording/album)
On 14/10/07 23:47, Andy Mabbett [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED], Martin McEvoy [EMAIL PROTECTED] writes On Sun, 2007-10-14 at 22:44 +0100, Andy Mabbett wrote: good point! however, people also refer to items as songs, Some tracks are songs, others are not. All songs, though, are tracks. You may find that all songs are NOT Tracks... a busker may sing a song for you on a street corner YOU may sing a song to yourself in the shower. Indeed; read my comment as all recorded songs. Or are you planning to mark up your local busker? Well I wouldn't want to mark up my local busker but marking up live performances would be kinda handy. In my case I need to mark up performance/set lists for Glastonbury, the Proms etc In these cases track would be plain wrong Also nested items/haudios would allow you to mark up classical works/opera (as opposed to perfomances/recordings). In the case of an opera: Haudio - opera haudio - act haudio - scene haudio - aria Or is this too much of a corner case? http://www.bbc.co.uk/ This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] item property (was: hAudio: audio-title/album-title vs. recording/album)
But it may never be recorded let alone released I might want to mark up a set list for a gig I enjoyed On 15/10/07 10:55, Andy Mabbett [EMAIL PROTECTED] wrote: On Mon, October 15, 2007 10:11, Michael Smethurst wrote: Some tracks are songs, others are not. All songs, though, are tracks. Again in the case of live performance no If the live performance is presented as single MP3 (say), perhaps not. But if it's sub-divided, each sub-division is a track. http://www.bbc.co.uk/ This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] item property (was: hAudio: audio-title/album-title vs. recording/album)
On 15/10/07 10:50, Andy Mabbett [EMAIL PROTECTED] wrote: On Mon, October 15, 2007 10:28, Michael Smethurst wrote: Tracks can be grouped by more than just albums. Examples, please. Playlists [1], tracklists [2], set lists [3], works [4]: [1] http://www.bbc.co.uk/radio1/playlist/ [2] http://www.bbc.co.uk/radio1/petetong/ [3] http://www.efestivals.co.uk/forums/lofiversion/index.php/t60883.html [4] http://en.wikipedia.org/wiki/Symphony_No._5_(Beethoven)#First_movement http://www.bbc.co.uk/ This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio proposal: ITEM/TRACK
Not wanting to add to the confusion but would it not be possible to have infinitely nested haudios with neither item or track and use mfo when the markup enforces containment that you don't want to be reflected in the model? On 15/10/07 14:11, Scott Reynen [EMAIL PROTECTED] wrote: On Oct 14, 2007, at 9:20 PM, Manu Sporny wrote: Scott, Andy - do each of you have further thoughts on approach #1 (assuming we can change the definition for ITEM)? Would it be acceptable to either of you? I don't have strong feelings either way on item vs. track. -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new http://www.bbc.co.uk/ This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio proposal: ITEM/TRACK
On 15/10/07 15:51, Scott Reynen [EMAIL PROTECTED] wrote: On Oct 15, 2007, at 7:28 AM, Michael Smethurst wrote: Not wanting to add to the confusion but would it not be possible to have infinitely nested haudios with neither item or track and use mfo when the markup enforces containment that you don't want to be reflected in the model? As much as I'd like to move forward a general MFO technique, that isn't necessary here as the hAudio proposal specifically makes all contained hAudio (currently called track) opaque [1]. The current proposal appears to only support two levels of nesting, but that may change. Examples of several levels of audio published on the web today would help support such a change. Multiple levels would also allow you to mark up multi-disc box sets: Haudio - hex enduction hour haudio - disc 1 haudio - The Classical Sorry for lack of examples - I'm short on time today [1] http://microformats.org/wiki/audio-info-proposal#Track -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new http://www.bbc.co.uk/ This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
