Re: [uf-new] Extensible and open-ended microformats?
On Fri, Jul 15, 2011 at 12:34 PM, Yuriy Guskov yura2...@yahoo.com wrote: For example, let's take hCard and hCalendar as examples: span class=vevent span class=summaryThe microformats.org site was launched/span on span class=dtstart2005-06-20/span at the Supernova Conference in span class=locationSan Francisco, CA, USA/span. /span 1. You cannot add more formatted details, unless it is provided by format. No state for CA. --- it is possible to use the ADR microformat inside the location of hCard in span class=location adrspan class=localitySan Francisco/span, span class=regionCA/span, span class=country-nameUSA/span/span. This will be transparent when converting hCard to vCard, but still give the additional semantic meaning to the parts of an address which could be extracted by other parsers. I hope this helps. -brian -- brian suda http://suda.co.uk Subscribe to the new (optional.is) mailing list http://eepurl.com/dLs3-/ ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Microformats for hidden data
On Fri, Nov 27, 2009 at 9:19 AM, Fiann O'Hagan fia...@jshub.org wrote: I was thinking about this last night, and realised that this is critical. What precisely do you mean by visible in the context of microformats? --- the way I always think about it is, out of sight, out of mind. Files that you may link to, but are not visible in the browser on a daily basis tend to get crufty and the data drifts from reality. I used to have flat vCard files on my server, because i was not staring at them every day through the browser window i forgot to update my address, and the data was incorrect. (How many people actively are keeping their FoaF files current via a text editor? All these files are fine, but the originating source should be very visible to people for editing) The same applies to meta elements or hidden data in HTML. If you are not visibly looking at it every day, there is a potential for the information to be wrong. We´re not talking about if it is visible when you view source, you don't browse sites by viewing source after following a link. Microformats have always tried to promote that the data being encoded is visible, as in rendered in the browser normally so people can see it (with many eyes all bugs are shallow) and if there is a problem, it gets fixed quicker due to this high visibility. It's the final case which is most closely related to what I am proposing here. They have information which is part of the page but it is neither hidden metadata, nor is it rendered in a default view. It is intended to be visible to a different audience than the casual end user browsing the site. --- i would say that it is best to avoid display:none on your content. Yahoo! has chosen to do so, I personally wouldn't recommend it, but their audience is very different than mine. Had they shown GEO coordinates it might confuse their customers. They made a choice to hide it and take the risks of data drift. It is their call to do so. The microformats still work, but they are not promoted to be used in this way. Everything SHOULD be visible by default. I want to do the same thing, which is to add information to the page, in such a way that it is accessible to humans looking at the source of the page, and to people with the right parser in their browser, but is not part of the view generally presented to end users. --- this is where microformats are designed to work in the opposite direction. ALWAYS visible by default. You are asking for hidden by default, which is a recipe for crufty data. Microformats were always designed with people in mind first, this seems to be designing for scrapers first but accessible to people. If what Yahoo Local are doing is not an acceptable use of microformats, then I accept that it's not the right approach for us either. --- I wouldn't advocate the hiding of the data, but they have their reasons and take the risk. But in the world of mashups, scraping, screen readers and all manner of different ways of consuming HTML, it seems like a very artificial restriction. --- well, we can look at it in a different way. Would you trust a smaller set of data that has a higher probability of being accurate, or loads of hidden data that has a higher probability of being inaccurate? Search engines took the first approach. None that i know of still utilize the meta keyword element. It was hidden data, it drifted from reality, and wasn´t reliable (but it was everywhere). Instead they look at rel-tag and visible data (who knows their algorithms might even punish or ignore display:none) and use the more trustworthy data instead. Microformats have been shown to work in the real world already with consuming applications and mash-ups. I don´t think this very artificial restriction has been as big of a problem as you might think. I hope this explains abit more about visible and hidden. -brian -- brian suda http://suda.co.uk ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] New microformat proposal: hPage
2009/8/13 Luís Nóbrega nobrega.l...@gmail.com: I have an idea to a new microformat, that I call hPage. --- I´d have a look at hAtom http://microformats.org/wiki/hatom It seems that there is alot of overlap. First you should try existing formats and then we can address any shortcomings. If you need help, or have a specific example, please let us know. -brian -- brian suda http://suda.co.uk ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] New proposal: Elemental microformat for content boundaries
On Tue, Apr 28, 2009 at 11:38 AM, Jeremy Keith jer...@adactio.com wrote: The weakest parts of hAtom right now are the required element issues. True. Not every piece of arbitrary content may have date, author and title. Content may just have text. I concur. But I think that rather than looking at creating a new format, we'd be better off relaxing the required content rules for hAtom. --- There is some discussion about an 'item' container, http://microformats.org/wiki/item that would allow for arbitrary data to be grouped together. It is another option to explore. -brian -- brian suda http://suda.co.uk ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] DCMF - Dublin Core metadata and Microformats
On Tue, Apr 21, 2009 at 1:08 PM, Ganesh YN yngy...@gmail.com wrote: There would be a terrific potential usage by the Library community as thay can benefit from this microformat if it gets formalized here as well. I would like to seek feedback suggestions from the group. --- Hello, You should have a look at http://microformats.org/wiki/cite there was an effort to map the dublin core as well as other citation formats to class values as a microformat. Hopefully this will give you more information about where things stand and where they can move forward. -brian -- brian suda http://suda.co.uk ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Re: Exposing place names whose property type (street-adr, locality...) is unknown
On 2/2/09, JMesserly swarm...@gmail.com wrote: Then in the case of Bailie's Bar, is it permissible to use the generality of locality in this way? eg: div class=adr span class=localityBailie's Bar/span, span class=localityChristchurch/span span class=country-nameNew Zealand/span /div --- i would use extended-address for something like Bailie's Bar it is not the street-address, and it is not the locality, but it is useful. Infact, i probably would work in ORG and FN if this were an hCard. Red alert? case two: div class=adr span class=localityTeal street/span, span class=localityHonolulu/span /div (real case- see http://commons.wikimedia.org/wiki/File:Pearl_harbor_attack_Japanese_recon_photo_of_battleship_row_80G30552.jpg) --- I am not sure what Teal street is, is it a street name without an address? If so, then you should use street-address, if it is not (it is some colloquial name), then you should probably use extended-address. It gets worse. In some cases there are real addresses with street numbers. --- If they are real addresses, with real street numbers, what is wrong with 'street-address'? If you have the precision to the street and house number, then what is the dissonance with the ADR structure? -brian -- brian suda http://suda.co.uk ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Microformats support for pagination
On 1/14/09, André Luís andr3...@gmail.com wrote: Hmmm.. can't we use emails? if two hcards have the same email, aren't they the same entity? --- yes, but you also have the situation where you have two different email addresses and it is the same entity. I don't think that that's quite André's point. A lot of blogs have tag clouds - long lists of perhaps a hundred tags, in various sized fonts which act as jumping off points to other parts of the site. They are not tags in the rel=tag sense of the word in that they do not describe the content of the current page, but of the site as a whole. People should not be marking them with rel=tag, but nonetheless some people do. And it means that essentially every single page on their site has the same massive set of tags - rel=tag becomes useless on the whole site. Exactly. I agree that this is not the purpose of rel-tags but I only brought it up because out of a very small sample, quite a few examples popped out. The only way out of this mess that I can think of, is to create a microformat for tagclouds, like a root element with class=tagcloud (the actual name could be based on the most used term) and that would give parsers the mechanism to either exclude all rel-tags inside .tagcloud or to grab the rel-tags inside of the .tagcloud and bail out... --- OK, now this makes more sense. Yes, there are several ways to get around this. One would be to ignore it in the results if it was part of a tag cloud. Also, if they are publishing hAtom, you could do the inverse and only look at the rel-tags inside an hEntry. Finally, you might be able to apple some sort of normalizing algorthim to the data set. If every page had the same 15 tags, plus X more, you could drop the 15 from every entry thus removing the influence of the tag cloud on each page. This brings me to yet another point that I considered when I gave that talk... if there was a semantic way of attaching a site-wide weight to a rel-tag, that would be *awesome* for these cases. :) But we've seen that embedding machine-data into microformats is a dangerous path... ;) --- well, one way to proposed to show weight was multiple em elements around a rel-tag. This gives literally, more emphasis to it. There has been discussions in the past if this is an abuse of semantics or not. But the bigger issue is that you might have weighted it with 2 em on a blog post two years ago, but now you are much more interested so you weight it with 6 em. Are you going to go back and change other values? If the weight is site-wide then you probably need to have some sort of internal consistency. We should capture more of these ideas on the wiki so future mailing list questions can be pointed there rather than over several email threads. -brian -- brian suda http://suda.co.uk ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
[uf-new] Microformats support for pagination
On 1/14/09, Jamie Rumbelow ja...@jamierumbelow.net wrote: See, comments like that lead me on to think that we need some form of pagination system for microformats - pagination is much more popular among sites these days and a rel=paginate might come in handy. --- There are several features built right into HTML itself to handle this. There is rel=prev and rel=next if you have pagination links with those values a good parser should know to continue along those paths for more information. This is a good question, can you add it to the FAQ so we can refer to it in the future? Thanks, -brian -- brian suda http://suda.co.uk ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Microformats support for pagination
On 1/14/09, André Luís andr3...@gmail.com wrote: Do you have any suggestions on how to deal with repetitions? I've tried parsing several pages of several websites and some of them used rel-tags on tagclouds... these would be present on every page (sidebar of blog) thus rendering the data kinda useless. --- do you have a real world example of where this would be a problem? The old technorati kitchen crawled the web and allowed you to search it. Having repetitions actually allowed for a nice merging of the data. Should/can we create guidelines for producers AND parsers alike on how to deal with this? Like adding site-wide unique id's to the root elements? Or is this out of the scope of microformats altogether? --- again, this would depend on the format in question. The existance of multiple events with the same timestamp and name could be used to merge data, UIDs and URLs could be as well, but everything could be gamed. But this isn´t unique to microformats, other semantic technologies would have this issue as well. There was talk of a rel-canonical awhile ago, but it wasn't big enough a problem to pursue. If you have an example we could work through it. -brian -- brian suda http://suda.co.uk ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
[uf-new] Microformats support for pagination
On 1/14/09, André Luís andreluis...@gmail.com wrote: I coded a script that looks at a given page and grabs the rel-tags in that page. It then counts the occurrences and orders them in descending order. the script is at http://workshop.andr3.net/tageater/ this was meant to infer the user's attention profile from the rel-tags... the problem starts if I follow the rel-* links. For example the website macacos.com marks-up the tagcloud with rel-tags on every page, So, how to detect repetition in these cases? --- wouldn't you just keep a list of the pages you have already crawled? So if you find a tagcloud on page /item1.html and it links to /tags/tag1 then on page item2.htm you re-find the tag cloud which links to /tags/tag1 you don't follow it again? So what you're saying is that this falls out of the spec's scope, right? It should be the parsers adapting their behaviour depending on their goal? --- probably out of side of the spec, but certainly a best-practices should cover these sorts of issues. You're right. Do you have a link where I can read more about that discussion? Thanks. There was discussion about canonical hCards 2 years ago http://microformats.org/discuss/mail/microformats-discuss/2007-January/008265.html I am not sure how helpful any of that discussion was/is to this problem. -brian -- brian suda http://suda.co.uk ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio Issue Duration
2008/8/4, Martin McEvoy [EMAIL PROTECTED]: A possible resolution is Duration can only be expressed in Minutes and Seconds or just Minutes eg: --- i think what is being discussed is an optimization rather than an encoding. Much like our FN nickname, FN == ORG optimizations, we are documenting short-cuts. This does not impact the actual encoding which stands true for all possibilities. -brian -- brian suda http://suda.co.uk ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Microformats on YouTube
2008/7/29, Greg Schechter [EMAIL PROTECTED]: Hi All, I'm an engineer at YouTube and we would like to add microformats to our site. I was wondering if I could get some suggestions on the best way to go about adding microformats to our site. I'm very new to the idea of microformats, so any suggestions on what we should be putting into the site would be very helpful. --- Microformats are about adding more semantic meaning into the mark-up. Before microformats there is POSH (plain-old semantic HTML). POSH does not have any sort of specs for specific formats, but instead champions the use of the basic HTML elements that already exist. Such as using a p when you have paragraph text rather than a div or other elements. Along with using semantic elements, you can just choose semantic class values to further extend meaning, such as adding a class=favorite to the favorite button, etc. Having a quick peek under the hood at the youtube HTML, there are lots of possibilities for both POSH and microformats. It would add meaning to the HTML and possibly shave-off a few KB from all the nested tables and divs If you have any questions, feel free to post them to this discussion list and as a community we can help you move things forward. Thanks, -brian -- brian suda http://suda.co.uk ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Recipe proposal
On 6/10/08, Benjamin Hawkes-Lewis [EMAIL PROTECTED] wrote: Thomas Yde wrote: But maybe the note property could be useful when searching a database, i.e. you could search for [item:] pistachios and then narrow it down to [note:] unsalted [item:] pistachios. Opinions? --- google base actually has alot of recipes and a schema which do not seem to be mention on the recipe-brainstorming page. It might be worth looking into how the model some of these more edge-case items (or even if they bothered) http://base.google.com/base/s2?a_n0=recipesa_y0=9hl=engl=us -- brian suda http://suda.co.uk ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] PROPOSAL: Replace hAudio FN with TITLE
2008/2/13, Martin McEvoy [EMAIL PROTECTED]: If we are referring to objects not people they do not have job-titles so we must be referring to the functional title of of the object eg: --- I don´t think we can say MUST be referring too. We do not know the intent of the vCard authors. hcard does not need to change, we are not RE Defining anything title is used correctly as a job title --- yes we would be effecting the definition TITLE in hCard. When there is an hCard with a title nested inside and hAudio as a contributor or other, TITLE now has two different meaning. Which MEANING of TITLE should i use? Is this instance of TITLE meant for the hCard or for the hAudio? In haudio we are proposing that title means audio title again perfectly valid when referring to the object not a person. Title hCard Job title or functional position of the object. would change to.. Title hCard Job title or functional position. hAudio Audio title. Generally the title of the object There is nothing earth shattering about that is there? HOW exacly would that *break* the definition of hcard? Now you have two DIFFERENT meaning for the same term. When you have overlapping microformats, there is no way to know which MEANING to use. Terms that have the SAME meaning are not effected because the property used can overlap and not have any disambiguation. I am sorry if i am misunderstanding anything, Please take the time to explain to me anything that is incorrect or wrong?. --- this does seem to be coming up more and more, so i began to look around the wiki to see if there was already a page. i did find this: http://microformats.org/wiki/naming-principles There is a section for anti-patterns but it is blank. Rather than start a new page, i think this might be the best place to document why giving a property two different meanings is a bad idea, just like giving two different properties the same meaning. We could also start a separate page, and probably should separate discussion thread about this topic. This is and will be a common problem. For instance, hAudio makes use of the term TRACK. One argument about TITLE is that it is not the Common English definition therefore we should change it. The meaning of TRACK in hAudio is the 14th most common definition in the English language[1]. Now it would be silly to stop hAudio from using that. In the future, if hWine or hModelTrainEnthusist ever surfaces, they will have this same argument. TRACK doesn't mean what it should mean - just like we have TITLE does not mean what it should mean! I would say that hAudio was here first, they used the term TRACK and defined its meaning for microformats, just as TITLE has been defined by vCard. Trying to point to the ever-changing English language as a reference point, is probably not a good idea. To have TRACK and TITLE and XYZ have multiple meaning at the same time, causes all sorts of semantic problems when you begin to overlap the trees. How do you know which meaning to choose? This inability to determine the exact meaning is the core of the problem. I will try to get some information up on the wiki, if someone wants to create stubs or FAQs, i (or someone else) will help document and answer them. The mailing list is not the best place to reference our answers when these questions come-up again. -brian [1] - http://dictionary.reference.com/browse/track -- brian suda http://suda.co.uk ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] PROPOSAL: Replace hAudio FN with TITLE
2008/2/12, Martin McEvoy [EMAIL PROTECTED]: On Tue, 2008-02-12 at 07:33 +, Brian Suda wrote: --- WOW, after 6 days we have made a community wide change effecting 3 years of effort with only 4 people weighing in! I am sorry i haven't been timely enough to offer my thoughts. --- i volunteer with the community and have not have much time in the last 6 days to properly give it the thought and discussions it deserves. I would rather send a single email, then several continual ones. Everyone benefits from a long hard thing rather than shooting from the hip sorts of emails. as usual in this community If someone sees something they DON'T like they just ignore it and hope it will go away. --- i would disagree. There are several reasons people do not answer. Maybe it was covered by someone else, maybe they are busy, maybe they personally are not interested. Only when things change do people jump up and down and say how wrong it is! usually without offering any reasons why or any alternatives. --- this is certainly not the first time this discussion has come-up. I know i have personally had a long phone call with Manu about hAudio and several aspects of it. I would and do not jump up and down for every change, only ones which i feel are bad choices. People are pretty fatigued from having this debate over and over again without gaining any ground. The alternatives which have been discussed before are, do nothing and use FN or use something like audio-title. Neither of which break existing formats. Why TITLE was propose and (i feel) rushed through with 4 +1´s is what i am not happy about - that is not community. I would kindly ask that you rollback your changes until this can be discussed further 4 people in a community is not consensus. How would YOU address this issue, haudio needs a title 94% of our use case examples say so, what is the point of the process if you cant work to it? --- i believe it was solved with FN. My biggest concern is that fact that by usurping the term TITLE you are breaking all the previous hCards. I´m not saying we don´t NEED a term to represent the title of a work, just don´t re-define terms that already have meaning. A little guidance would be nice, instead of just saying this is wrong please offer a resolution, some guidance even? --- i am very close to the original hCard work, so i was not trying to involve myself early in this discussion and sway the thought process. I purposely (what i thought was the impartial thing to do) let some discussion move forward without my interference. That discussion was a few +1s and and an re-explanation of the original question. That isn't a discussion. The original logic in the question is flawed. The first portion is correct FN in hCard means the formatted name of a person or orgainzation. FN in hAudio currently means the formatted name of an audio recording. It is the next portion which is misleading and wrong: TITLE in hCard means job title TITLE in hAudio means audio recording title It should be TITLE in hCard means the Job Title of the person or organization TITLE in hAudio means the Job Title of the audio recording The correct logic is completely fine, but that is not what the proposal is trying to do. It is attempting to undo the definition of TITLE across all microformats, which has been discussed before and rejected in such formats as the citation. Due to lack of any sort of discussion, decent or any massive support, i was not expecting to see such an important edit to the wiki page. i´m not against haudio or having some sort of title property for the format, what i do not like is attempting to break any format with any property that has already been defined. I believe this issue is already solved with FN, (IMHO) there is no need for this proposal to use TITLE. So now you have my -1. -brian -- brian suda http://suda.co.uk ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] PROPOSAL: Replace hAudio FN with TITLE
2008/2/12, Manu Sporny [EMAIL PROTECTED]: After a week, there have been 4 supporting e-mails for the hAudio TITLE instead of FN proposal, and 0 opposing e-mails, I have updated the hAudio specification to note the use of TITLE instead of FN: http://microformats.org/wiki/haudio --- WOW, after 6 days we have made a community wide change effecting 3 years of effort with only 4 people weighing in! I am sorry i haven't been timely enough to offer my thoughts. Just because no one publicly disagrees doesn't mean that everyone agrees to the proposal and that it is acceptable to move forward. I would kindly ask that you rollback your changes until this can be discussed further 4 people in a community is not consensus. -brian -- brian suda http://suda.co.uk ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Dublin Core (was: hAudio FN or Title)
2008/2/4, Ottevanger, Jeremy [EMAIL PROTECTED]: Hi. Coming out of lurk mode, --- welcome to the list, and thanks for your thoughts. I recognise that The Process wisely advocates that formats should where possible build upon those that exist already, and that a DC microformat might tread on some toes in this respect by creating classes that overlap with existing classes in hCalendar, hCard and so on. I hope this needn't interfere unnecessarily, there's simply too much to be gained from making this suggestion happen. --- the process also states: There must be a problem to be solved (i.e. a real world use case). No problem, no microformat. The idea is NOT to make a generic Dublin Core microformats, but to address a specific problem. People, Places, Events, Music, Books, etc. If there is something specific, then we can get a use-case and develop a format from that. Just making mapping the DC Ontology to class names, doesn´t get us much. We still need a data format to apply it too. There is a ton of content out there that could readily be put into a DC microformat. --- then we shouldn't look at DC, we should look at that content and model that, either using existing microformats, or find common attributes across the examples in the wild, then move through the process that way. Jumping straight to making a generic OBJECT DC format is not the best approach. Microformats are designed to address very specific common problems. That is not to say that the resulting format can not reuse DC properties, but to jump straight to a conclusion does not help model commonly published behaviours. To me, now, it makes a lot of sense to pull DC out as a microformat of its own and then think about building more specific applications based on it. --- this would be backwards to microformats. First we find the specific real-world commonly published content and give structure to them. ... There are also a large number of! people out there already that understand DC, that know its role and benefits and the correct way to use the elements (well, sort of), and that would not need to be sold it in the way that they may need to be sold other microformats. Seems sensible to me to tap into that. --- it certainly does, but it should be in the context of a problem that needs to be solved, not just picking a format and mapping to it. Properties in other RDF languages map to DC without using the DC namespace. Foaf maps properties in it's namespace to Dublin Core. Microformat can easily do the same thing, there is no prohibition against this, as long as the meaning is the same. Just because it is called fn or creator or something else, doesn´t mean it can't become Dublin Core properties. If you or others have a specific idea for a format, then the process is the best way to move forward. If there is no specific problem that needs to be solved, then we shouldn't spend the time making a global solution to non-issues. Ultimately, microformats are meant to be a simple solution to common problems. Microformats were not designed to solve every last possible problem and that is OK. Making a generic DC microformat is attempting to do this, instead of addressing specific problems. If the issue can not be solved with existing microformats, then there are a few options. 1) break it into smaller pieces and see if a format exists? 2) gather data for a new microformat 3) mark-up what you can, and use POSH in other places 4) use something else, like RDFa, eRDF, GRDDL or others. -brian -- brian suda http://suda.co.uk ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Namespace anti-pattern and hAudio TITLE (was: hAudio FN or Title)
2008/2/4, Manu Sporny [EMAIL PROTECTED]: Here are more examples of Microformats using emulated namespaces: country-name (hCard) organization-name (hCard) organization-unit (hCard) --- i do not consider these namespaces. In the vCard RFC the value is called Country Name, Organization Name and Organization Unit with spaces. Since we could not use spaces in a class attribute we had two choices, CamelCase or hypens. We chose Hypes. There was no attempt to do any sorts of emulated namespace, more simply just concatenating space-separated-terms so they could be used in the class attribute. -brian -- brian suda http://suda.co.uk ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio FN or Title
2008/1/31, Manu Sporny [EMAIL PROTECTED]: The thought about porting the Dublin Core names over to Microformats was mentioned on the uf-discuss list. Having a Dublin Core Microformat, may be a solution that works for everybody. --- we just have to be careful of creating a solution to a non-issue. Microformats model established publishing practices and solve simple problems. The main disagreement seemed to be in DC's choice of class names... This approach has two benefits: * It uses Microformat-like names. --- it might be microformat-like, and that is fine, but it doesn't need to be a microformat. It can be POSH or RDFa or eRDF, or others. Having a pseudo namespace DC-foobar has been discouraged before. * It re-uses a vocabulary that is largely accepted in the web semantics community. --- this is good we want to re-use not re-invent, but we also don't want to re-use whole-sale when possible, simply coping all of dublin core seems to be a solution to a non-problem. As new formats are created, we can look to existing formats like dublin core, we have done that with hAudio and attempted to reuse terms such as CONTRIBUTER, IMHO this is the proper way to proceed. Not a new dc-kitchen-sink-and-more approach. -brian -- brian suda http://suda.co.uk ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio ITEM/TRACK debate resolution
On 10/21/07, Manu Sporny [EMAIL PROTECTED] wrote: - Naming those properties (specifically, tracks in audio albums) - The structure of hAudio as a container. Specifically, we are talking about tracks in albums, and what should denote the track container in hAudio. --- i agree with these two points, but what i disagree with this the design of this container so far i have heard it called a container about tracks and albums and i have heard it called track by default. From the descriptions i am hearing, the property haudio is 2 different thing. IMHO it should only be 1, a generic container for audio. Brian Suda wrote: If that is so, then FN is NOT needed. FN is needed because the examples show that both album and song name are listed on a page next to each other. Such as when a blogger talks about a song that is a part of an album. --- (we have lost the original HTML example in all the replies) If we are using a unique property for the string that is the ALBUM name class=album then it is redundany to have BOTH class=fn album, FN should be used for 1 or the other for the name of the string, be it the string for the album name, or the string for the track name. Since tracks seems to me more common, class=fn for track names... and class=albums for album names, not class=fn for tracks and class=fn album for album names. The reason you think you NEED class=fn album is because of your short-cuts. If you have ONLY one way to represent the hAudio structure (which you don't there are several) then you do not need class=album //haudio/fn == album name //haudio/item/fn == track name But instead haudio is attempting //haudio == track name //haudio/fn == track name //haudio/item/fn == track name //haudio/album+fn == album name (i don't understand this, it could just be //haudio//album) But for now, if we impose a SINGLE structure to mark-up haudio (which i think is best, it helps adoption, examples and explaining) then we don't even need ALBUM. I personally don't like ALBUM, because then we get an enumerated list of people's pet projects, PODCAST, ALBUM, COLLECTION, etc, but that is another discussion. We have too many examples to ignore ALBUM. We also have too many examples to ignore FN. --- i think that might have been a mis-communication. I disliked the property name ALBUM, i am not debating the merit of its existance. We are already at later - we have solved the atomic recording problem for hAudio. We are now attempting to solve the recording with multiple parts problem for hAudio. --- then this is two different things. With hAtom we solved the atom ENTRY, then put it in a FEED. If we have solved the atomic RECORDING, then we are putting it into a COLLECTION (or ALBUM) this is a level above hAudio. The original examples where making (what i think is a poor use) of class=item haudio in a class=haudio, but i see what you are attempting. Why is attempting to do something that no other microformat does a bad thing? --- it isn't, but the concept of NESTING isn't new, hAtom does this. What is new and bad is nesting the same property inside itself. Which is what this whole class='item haudio is doing. It is true that no other Microformat does sections/collections/parts. --- i think you proved your point right there, you have 3 distinct levels. But in your mark-up you are saying haudio/item+haudio (that is NOT three distinct things) It might help if we use examples of what we are talking about: !-- This is a TRACK and ONLY a track -- div class=haudio span class=fnTrack 123/span /div The above could also be written like so: span class=haudioTrack 123/span --- i disagree with this idea. Firstly, it is a premature optimization. Secondly, haudio is no longer a generic container, it is now a TRACK. Which goes against what you said at the begining of your email. First, let me state that hAudio is about audio recordings, of which tracks and albums are a subset. There is no SUBSET here, it is ONLY hAudio. A subset would be //haudio/SUBSET HERE (item in all the examples)/value !-- if haudio is TRACK by default, then there is no need to have item here, right?-- div class=haudio span class=fnTrack 123/span abbr class=duration title=PT3M24S3:24/abbr /div Correct... nobody said that ITEM was required for a single audio recording. --- fine, but if this is the ATOMIC structure for a Audio Object, then we need a class ABOVE haudio to contain multiple hAudios, much the same way hEntry is contained within an hFeed. OR always have ITEM so haudio stays the generic container and contains SUBSETS of multiple other things (namely tracks) !-- what is this? an album with a duration, or an un-named track in an album with a track duration? -- div class=haudio span class=item span class=albumAlbum 123/span abbr class=duration title=PT30M24S30:24/abbr /span /div That is incorrect markup. The parser would identify that as an album
Re: [uf-new] hAudio ITEM/TRACK debate resolution
We are replying to alot at once, so lets break it up, and get down to only the sticking points. On 10/21/07, Manu Sporny [EMAIL PROTECTED] wrote: That is the definition of hAudio, it is not any more specific than that. What gives hAudio its specificity is the attributes that go inside hAudio. --- ok, i can agree with this as an idea, and i think we can move to a better way to mark this up. Below looks more like what i had in mind. For example, if nothing goes inside hAudio other than FN, it is the name of the audio recording: div class=haudio span class=fnA Sound Recording/span /div If somebody wants to be more specific and mark up an album, they can do the following (leaving out FN - using your proposal, Brian): div class=haudio span class=albumAn Audio Album/span /div --- so far i agree. I think part of the issue was that //haudio/fn is JUST a string to represent the string not a track title. I can agree with that. I think the two examples above make sense to me. I would also press for requiring ATLEAST an FN or ALBUM, not span class=haudioA string/span. We can discuss this in a later itteration as an optimization. If somebody wants to be even more specific and mark up an audio recording that is a part of an album, they can do this: div class=haudio span class=fnA Sound Recording/span found in span class=albumAn Audio Album/span /div --- yes, that is fine. FN could be your display-name in something like Operator, but Album is the name of the title of the album. If you WANTED these could be the same class=fn album, but to me that doesn't make any semantic compound. Just that the display name happens to be the same string as the album. All three examples above are audio recordings. An album can have sections, but played from beginning to end, it is still an audio recording. It should also be noted that we are required to provide at least the functionality shown above - the examples are very clear on this. --- i agree with the previous. I don't think there is much arguments there. The tricky (IMHO) things happens when we start nesting. In addition to the above, we are also required to be able to list albums and tracks. I think the following markup is what you would prefer, right Brian? div class=haudio span class=fnA Sound Recording/span found in span class=albumAn Audio Album/span div class=item span class=fnTrack 1/span abbr class=duration title=PT2M32S2:32/abbr /div div class=item span class=fnTrack 2/span abbr class=duration title=PT3M11S3:11/abbr /div /div --- correct. To me this makes the most sense. Each track has individual metadata bound by class=item, things outside of that are assumed to be part of the audio object in general. So far this isn't really nesting. If we look at hAtom, you can have rel-tag inside a entry but also a feed, that really isn't nesting, just the ability to have properies inside and outside of the item. But as i understand, the ITEM could recursively be more audio-objects. But instead haudio is attempting //haudio == track name We should probably stop using track name - it seems to be causing confusion. Use audio recording instead. We aren't as specific as a track using that markup all we know is that it is an audio recording... we don't know if it is an album and we don't know if it is a track, nor do we know if it is a podcast. We don't know anything other than it is an audio recording. --- i agree, i have been under the assumption that it would have been a TRACK name, but you are right it should be re-defined as just a string that describes the audio object, which is optional. //haudio/fn == track name We still only know the name of the audio recording, nothing else. It is definitely not a track at this point. --- ok, i can agree with this. So we do NOT know this is a TRACK, just an audio object with a title of some sorts? Once we all get on the same page here, we can discuss the rest of the message. -brian -- brian suda http://suda.co.uk ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio ITEM/TRACK debate resolution
On 10/21/07, Manu Sporny [EMAIL PROTECTED] wrote: FN is the formatted name of the audio recording. --- thats fine. I agree. Here are the rules we defined earlier this month, which have been updated to match the discussions over the past two weeks: ... # If ALBUM and one or more ITEMs are specified, the hAudio is an album containing tracks. Each track is assumed to be an hAudio, unless specified otherwise. None of the track properties should implicitly be added to the containing hAudio. In other words, the parser shouldn't parse the contents of the ITEM hAudio into the higher-level, non-track hAudio object. --- this is fine. I know why we have stated this. It is to prevent something like //haudio/item/duration being applied to just the //haudio/duration or //haudio/item/fn mixing with //haudio/fn I agree with this, no issues here. But as i understand, the ITEM could recursively be more audio-objects. Yes, in the item haudio proposal it can. It is assumed that item can contain anything that hAudio can contain, including more items. --- ok, this is i think were i need to go back and read some things. I don't disagree here, but think that there must be a better way to represent this rather than infinite nesting of haudios. Then you could re-declare the album to be different with each instance. Like i said, i'll try to go back and see why this is. If you don't disagree with any of the statements above, please explain why you believe nesting to be a bad design choice. It seems like that is the big disagreement, here. --- i don't disagree with anything but the infinite nesting of haudio items. There have been alot of different people answering the same questions differently. Thanks for your patience. Things are much clearer and now that we agree on the basics and aren't talking past each other, we can try to work out what is left. -brian -- brian suda http://suda.co.uk ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio ITEM/TRACK debate resolution
On 10/20/07, Manu Sporny [EMAIL PROTECTED] wrote: PROPOSAL: 1. HAUDIO can contain plain text to specify the FN property: span class=haudioSong Name/span --- i'm not against this, but lets not put this in right now. This is an optimization. As Donald Knuth said Premature optimization is the root of all evil. Lets keep the span class=fn for now, try it for a few iterations, then we can discuss optimizations later. hCard is not span class=vcardbrian suda/span, it is still div class=vcardspan class=fnbrian suda/span/div optimization have been discussed, but there hasn't beed a NEED for this yet, so lets not complicate hAudio with optimization YET. We might paint ourselves into corners with premature optimizations, so i'd rather have something working in the wild with implementations, then we can discuss this further based on evidence rather than assumptions. 2. HAUDIO parts are denoted by ITEM+HAUDIO: span class=item haudioTrack Name/span --- i don't think the haudio in your class list is needed. With haudio, item and fn, that nesting can tell you everything you need. Let me edit your examples below to illustrate EXAMPLES: Album with two tracks, simple example: span class=haudio span class=fn albumBest Before 1984/span span class=contributorCrass/span span class=item haudioHokkaido Dream/span span class=item haudioTokyo Groove/span /span The previous would need to be changed to: span class=haudio span class=fn albumBest Before 1984/span span class=contributorCrass/span span class=item span class=fnHokkaido Dream/span /span span class=item span class=fnTokyo Groove/span /span /span (this is just expanding the optimization of FN in an item and removing the un-needed haudio) Album with two tracks, more detailed: span class=haudio span class=fn albumBest Before 1984/span span class=contributorCrass/span span class=item haudio span class=fnHokkaido Dream/span abbr class=duration title=PT3M24S3:24/abbr /span span class=item haudio span class=fnTokyo Groove/span abbr class=duration title=PT4M46S4:46/abbr /span /span --- this looks fine, except you don't need the class=item haudio, it just needs to be class=item * We are creating a number of short-hand markup approaches will allow publishers to write hAudio in a much easier way. --- i think at the moment we should avoid premature optimizations, we can re-examine them at a later date. These are the drawbacks that have been identified for the following approach: * ITEM HAUDIO isn't as specific as TRACK. --- this is a good thing, it is just an ITEM. We can reuse all the semantics of hReview. For things like iTunes buy this album and get a video too now you can still use ITEM to represent a nested VIDEO or PDF or other formats, not just AUDIO. Using the class=type you could specific what it is, track, video, pdf, etc. If there is no TYPE it is assumed to be an audio track. I don't think we need to make the connection of item haudio to cast the item as an audio element. So if you want to talk about JUST a track you can do this: span class=haudio span class=item span class=fnHokkaido Dream/span /span /span it might be slightly more verbose that you want, but we can always discuss optimization later once we have real data to work with. Lets not throw the baby out with the bathwater. First get a working format, then iterate for optimizations. That would be my suggestion -brian -- brian suda http://suda.co.uk ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio ITEM/TRACK debate resolution
On 10/20/07, David Janes [EMAIL PROTECTED] wrote: The idea -- based on previous discussions, feedback, etc. -- was that for hItem to be compatible with hreview (and others [1]) it would defined as follows: - if not paired with an appropriate semantic class, the hItem refers to the top level uF -- this is how hReview and hListing use it --- right, so in the examples, since there was only one top-level uF the class=item haudio would not need the extra haudio because we know which we are talking about - if paired with an appropriate semantic class -- e.g. haudio or track -- then the hItem refers to that particular sub-element of the uF --- i don't perticularly like sectioning off of microformated data. Firstly, we are venturing into theoretical territory with what if an haudio was in an hreview, but this is a solvable problem with the tools and rules we already have. div class=hreview span class=haudio span class=fn albumBest Before 1984/span span class=contributorCrass/span span class=item span class=fnHokkaido Dream/span /span span class=item span class=fnTokyo Groove/span /span /span /div In this case the FN of the hReview would be THE FIRST fn it finds in an item object, so it would be Hokkaido Dream. To fix this, simply add am item property into the span class=haudio. div class=hreview span class=haudio span class=fnBest Before 1984/span ... Then the first FN that is found inside an ITEM inside an HREVIEW is now Best Before 1984 the other items are ignored in the context of hreview but NOT for haudio. It solves both problems without extra mark-up. As for hItem, if it went by the same first only rules, then it would find 3 items, with 3 corresponding FNs without the need for any sectioning off of data. I think that solves the issues nicely. The type casing of what an item is optional. We do it with hResume, and somewhat with hCard's ADR. The ADR should be an hCard, just like the class=contributor SHOULD be an hCard, but isn't a MUST. We should examine this more on a case-by-case basis if issues arrise rather than protect against something that might not even exist. -brian -- brian suda http://suda.co.uk ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio ITEM/TRACK debate resolution
want to talk about a single hAudio object, then we can model it after hCard where it is 1 track or 1 album at a time. -brian -- brian suda http://suda.co.uk ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio: audio-title/album-title vs. recording/album
On 10/12/07, Manu Sporny [EMAIL PROTECTED] wrote: Martin McEvoy wrote: So we leave album-title and audio-title as it is? Or are we going to talk about it? I was giving others at least a week to weigh in on the issue if they wanted to... didn't want to front-load the discussion. :) --- i was under the impression this was still an open issue that is already solved with FN. I was unaware this was still a discussion point. -brian -- brian suda http://suda.co.uk ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Pattern: Presence of Property
On 10/9/07, Ben Ward [EMAIL PROTECTED] wrote: From a parsing POV, we're only interested in whether 'optional' is present or not. If it's absent, we'd be assuming 'required'. We'd be using a pattern whereby the property value is determined from presence or absence of the element, not by the value of it. Now of course this application is early days and we may yet find further requirements or different ways of doing it, but I like the idea of the pattern as it's language agnostic. Also, I think 'Presence of Property' is a pretty snappy name. What would people think about this sort of parsing rule being added to the microformats cannon? --- i don´t think a binary true/false should be used as a class attribute. This brings us back to SHOULD, MUST, MAY, you MAY use this or you MAY NOT. Optional might not be a binary relationship. Your example could become: spanspan class=ingredient optional3 Strawberries/span (optional)/span And we are back to hiding data. using the TYPE we can make an enumerated list of OPTIONAL, REQUIRED, MAY, RECOMMENDED, REPLACABLE, SUBSTITUDE, etc. -brian -- brian suda http://suda.co.uk ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio ISSUE #1: image-summary is redundant
On 8/8/07, Manu Sporny [EMAIL PROTECTED] wrote: So far, there are 3 votes for PHOTO (Brian, myself, and I'm counting you Scott, as you didn't seem opposed to the idea of PHOTO), 1 opposed. It would help if others would weight in on this so we can put the issue to rest. --- firstly, the original message was sent 2 days ago. The fact that others have not given their opinion on this topic probably has to do with a few factors. 1) 2 days from the original message till now is not enough time for readers to weed through the volume of emails and do the background reading needed. 2) people don't have an opinion 3) people simply don't care and an audio media format is not a interest to them. This could be why there are so many OTHER formats that haven't been worked in months. Someone brought-up the idea. It was floated around, never gained traction and it was filed away until it could be used later. At this time, the discussion on this topic has been conducted by a small sub-set of the community. This is certainly not the best way to gather input or opinions - we have 100% support to use PHOTO, based on 2 people´s yes's and and an assumed yes. Does anyone else think that is anemic at best? (i doubt i'll even get much or a response) maybe it is time to take a breath and let people digest some of the issues, ideas, uses, mark-up and all the background reading for awhile. Otherwise it will be the same 3-4 people talking to each other about other issues and we won't really go anywhere. -brian -- brian suda http://suda.co.uk ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio ISSUE #1: image-summary is redundant
On 8/6/07, Martin McEvoy [EMAIL PROTECTED] wrote: On Sun, 2007-08-05 at 22:39 -0400, Manu Sporny wrote: The full issue description can be found on the audio-info-issues page: http://microformats.org/wiki/audio-info-issues#image-summary_Property hAudio ISSUE #1: image-summary - This is a small graphic image that summarizes the audio piece. There are several other formats that already use the PHOTO property, including hCard and hReview. This has potential to collapse and remove image-summary. Possible Solutions 1. Use PHOTO instead. I think we should go with Brian's suggestion and use PHOTO instead of image-summary. If you are involved in hAudio (or want to be), please give the list an AGREE/+1 or disagree with a line of reasoning. -- manu Disagree Photo or Logo is not a correct description of what may be potentially a work of art eg, --- i think this is splitting hairs, at the end of the day, this is a representation of the actual Art, Photo, Painting, etc. Applications are called PhotoShop. iPhoto, etc. even though they are not always indexing or editing JUST photos. Re-using PHOTO keeps us from inventing more and more terms. Also, the current spec says that this MUST use an img, i would say this should be changed to SHOULD, not MUST. There could be cases were you might want to simply give the URL to the image or use an AREA or OBJECT element. Or possibly use other elements in RSS. We should avoid mandating how/where to encoding specific microformat properties. -brian -- brian suda http://suda.co.uk ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio ISSUE #1: image-summary is redundant
On 8/7/07, Scott Reynen [EMAIL PROTECTED] wrote: On Aug 7, 2007, at 11:44 AM, Martin McEvoy wrote: Do you think the use of PHOTO may interfere with the hCard that is already part of the hAudio proposal, Suppose I wanted to mark up my hAudio hcard's with Photos of the band members? isn't that breaking the don't repeat yourself rule? --- like scott was saying, when developing the format, you can also define the parsing rules. If you look at hReview, it uses hCards and PHOTO. To disambinguate the two it is a matter of PHOTO inside an hCard and PHOTO not inside an hCard. This is already something that hReview deals with and that has been working pretty well so far. hReview is a good example, because it can use an hCard to be the thing reviewed, and an hCard for the reviewer. So you have multiple FNs, PHOTOs, all over the place and it manages to get sorted out just fine, it is just a matter of parsing rules. -brian -- brian suda http://suda.co.uk ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
[uf-new] Standards bodies (was RFC: hAudio RDFa specification)
, as long as they do so a good member of this bottom-up community. BarCamp is another attempt at the flip of FOO camp. Simply by avoiding the time, cost, and red-tap of standards bodies, we have manage to accomplish a heck of a lot in the last 2 years completely with volunteers. -brian -- brian suda http://suda.co.uk ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
[uf-new] Reusing classes names in multiple formats
On 6/8/07, Scott Reynen [EMAIL PROTECTED] wrote: This is the same problem with re-using any class name in multiple microformats. As mentioned earlier, if we re-use summary in haudio (which I'm not arguing for nor against here), what if we want to embed haudio inside hreview? SUMMARY is defined as: A short summary or subject for the object. http://microformats.org/wiki/classes It is currently used in: vevent , hreview, hresume How do we keep the haudio summary from becoming the hreview summary? --- this is true, but sometime you want it to be both! Microformats are purposefully simple and MICRO, we are quickly getting to WHAT IF... the original intent of microformats is NOT to boil the oceans and have hundreds of formats! each time a few format is proposed it does have to interact with all the others, and this is exponential growth... some things will never be microformats, that is a fact of life, we are MICRO by design. There is now a nice sliding scale of technologies, from POSH, to microformats, to RDFa to GRDDL all which do things slightly differently with different output and results. Microformats do NOT need to cater to every theoretical eventuality. More generally, I think we should be defining parsing rules based on the semantics, rather than vice versa. --- this is difficult because the semantics are meant to be the same, it is context that you want to look at, and sometimes you WANT it to be in both contexts at the same time. IF we start to propose that every term be prefixed with hcard-title so it doesn't collide with media-title then we are no better off than RDFa and namespacing. Microformats were designed with intent to avoid this. In doing so we have set limitations on ourselves which we readily acknowledge, we are NOT attempting to solve every problem, we are after low hanging fruit, at some point we will have exhausted those resources and things will no longer be 'easy'. We should avoid constantly inventing new terms which mean the same thing, just so we can avoid collisions - the only reason we would go down that road is so that we CAN attempt to solve every problem and boil the oceans, which is NOT one of the goals of microformats - that is solved by other technologies NOT microformats. firstly we should look at all the available properties[1] regardless of where they are used. if we don't fine on that meets our needs, is there existing formats or prior-art that is using properties, otherwise we create new ones. If there are properties that already exists, then we should do our best to use them. If we can't then we should go back and look into creating new properties. [1] - http://microformats.org/wiki/classes -brian -- brian suda http://suda.co.uk ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Third attempt at hAudio
On 6/7/07, Martin McEvoy [EMAIL PROTECTED] wrote: I also think that in any future evolution of hAudio for example hAlbum, hCast etc, may rely on a title attribute of some kind for its meaning. --- it is best to not to think about theoretical issues before we even have any sort of audio format. Much like hAtom, this can be easily solved at the schema level. hAtom for instance uses rel-tag for individual entries, but also for hFeed itself. Because we control the semantics of hFeed it is easy to simply say find all rel-tags that are children that are NOT in an entry, if/when we create a container such as album, we can do the same thing and say use the class=summary|foobar that is NOT inside track data. We can resuse properties easily without confusion because we control the schema of the data. -brian -- brian suda http://suda.co.uk ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] title vs. summary (was: Third attempt at hAudio)
On 6/7/07, Manu Sporny [EMAIL PROTECTED] wrote: 1. How did TITLE come about? --- TITLE is part of the vCard spec, and is now part of the hCard spec. 2. Who created it and how many people signed off on it? --- it came along with hCard. I'm not sure what you are implying about signed-off on it. What you are implying is that there is an overall gold stamp, which there is not with microformats. 3. Did it originate in hCard? --- it originated with vCard and was taken onboard with hCard. 4. How many Microformats existed when TITLE was created? --- none, hCard was developed before Microformats.org existed. It was developed along with hCalendar. 5. Is there anybody else on the list that thinks that TITLE has a bad semantic definition? --- The definition of TITLE has been assigned, it is not incorrect. This is life, as audio moves along i'm sure people will suggest TRACK as a property, but all the hWine folks might cringe because they might want TRACK to mean a track of land. This is a fact of life that many english words have multiple meanings. TITLE could mean a job title, a title or deed to a house, or an honorary title, or book title. Everyone will fight for it to mean different things. Whether TITLE was a good or bad choice is not really up for debate, by changing the semantics we potentially break every page that has an hCard. This is an expensive practice to deprecate a property, let alone re-assign it to a new value! There are much simpler ways, which has been to use a different semantic element which means what you intend, hence FN or SUMMARY. I realize that this is a can of worms that most on here don't want to open up - but what do we do when semantics are hijacked by previous Microformats? --- they are not 'hijacked' they are simply different semantics that you WANT. There is nothing incorrect about the current semantics of TITLE. It seems to me that the proper semantic name for Job title or functional position should be something like 'position', or 'job-title', or 'function'. --- this might be true, but TITLE is semantically correct as well. When it comes to other properties such as length of a video, do we choose 'duration' or 'frames' or 'run-time' or something else... no matter what you choose it will never please everyone. So, because VCARD defined what TITLE was a long time ago, all Microformats must follow that definition from now on because of a simple copy-paste? The first Microformat to use a term gets to define what it means in all other Microformats... forever? --- there are no namespace in microformats, so when we define a term it is set for life. This is why we need to take the time to select the correct terms. Microformats are an on-going process. This is also why we want to keep things MICRO and not introduce hundreds of new formats. I realize that what I am proposing is revising hCard and re-naming 'title' to 'function'... in return, we can use 'title' to mean what it is defined as in most dictionaries: what you left out in your dictionary references, is that they also contain the definition of TITLE as we currently defined it, along with several others. The dictionary.com reference has 9 results with around 12 definitions for each, you posted 2. http://dictionary.reference.com/browse/title You will find that most of the enteries do have the current definition of TITLE among them. Do you see the point I am trying to make? --- i do, but i don't see why? what you call FN or SUMMARY or TITLE is important, but we have assigned semantic values to terms already, this process is expensive to go back on. Then if you wanted to redefine TITLE in your manner what is the point of FN or SUMMARY? we now have duplicate properties which we want to avoid. Much of the very early work of microformats happened BEFORE microformats.org existed. Since then we have learned more and more with each step. Choosing the semantics we did for TITLE might not please everyone, but this is done now. I don't see the need to change it since it already works just fine and we have viable alternatives. I really want to keep this discussion civalized, but to do so we need to avoid leading questions, use of terms like hijack which evoke an incorrect emotional response which is in no way true, if there is a comment or question, lets ask it specifically so we can avoid any confusion. You can always email me offlist and we can discuss it further, there is also the IRC channel which discussions happen more real-time. -brian -- brian suda http://suda.co.uk ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio - audio-album and audio-podcast
On 5/31/07, Manu Sporny [EMAIL PROTECTED] wrote: What ever happened to working on the media-format? The media-format was far too broad of a problem - that's why it hasn't moved forward in two years even though there are a great number of examples of marking up media on the web. It is far easier to break the problem up into audio, video and images and tackle those individually: --- i would disagree, the Dublin Core group spent many many years and narrowed down the base Metadata to 14 (i think) values. When people propose these new microformats each one wants their little pet-project portion of metadata to get into the new format. In the most basic sense all the media has a creator and some additional metadata. They might be different types of formats, but the metadata is the pretty much the same. I just think there was either, no interest in developing the format, or too many what if we add this happened and it never moved forward. Those are different problems - we aren't addressing those problems with this Microformat. We have a very specific problem statement for audio-info: The problem statement reads: It is difficult for a browser to extract semantic information about an audio recording described on a web page. Metadata such as speaker, musician, publisher, label, title of the work, release date, acquisition link, related image artwork and tags provide relevant context for the audio recording. with the exception of audio recording the could apply to any media format. I don't feel it is that specific for audio. We should stick to the small problem and solve that - not make it bigger and more complicated (boiling the oceans). --- correct, but this doesn't have to mean what formats it encompasses, but the scope of the problem. It shouldn't attempt to have every possible metadata property possible - i agree that is boiling the ocean, but if the same 4-5 metadata properties can apply to multiple formats we should keep that in mind, and i think we have done a good job to keep the scope focused on just the minimal amount of metadata properities needed. I just feel these same properties can simultaniously apply to multiple things. Could you expand on this idea please? I want to make sure I understand you correctly. I'm fine with the concept of non-hyphenated names, are you suggesting something along the lines of: album description haudio track haudio track haudio --- You could have some overarching container, lets call that something like media. That has meta data, much like hfeed. media tags, decription, contributer, ... then, nested in that media is individual items, much like hentry in an hfeed. media tags, description, contributer, ... track track track chapter each of those items (track, chapter, ...) contain additional metadata about themselves. media tags, description, contributer, ... track duration, title, author, price, ... chapter duration, title, author, price, type, ... Last i remember the hAudio proposal basically broke down to just an hReview with a price and a running time. The semantics of audio-info are very different from the semantics of a review. The following are required for audio info (based on the analysis and brainstorming done by this list): fn, contributor, published-date, rel-sample (samples), rel-enclosure (full versions), rel-payment (purchase option), image-summary, category, duration, and price - hardly any of those overlap with hReview. hm, hreview has fn, so does this proposal, it has published-date just like this proposal, it has an image just like this proposal, it has tags just like this proposal's category, hreview has URL which could be used as the download links... like i originally said, it basically broken down to many of the same values in hReview, with the addition of price and duration. The only value required for an hReview is the FN. Then we got all side-tracked with a grouping issue. One of the first steps in proposing a microformat is to see if an existing microformat could fit. After spending along time on the mailing list, simply suggesting things, the whole conversation bascially was pulled back to hReview. Has anyone attempted to simply mark-up their data using hReview with a price and duration (which is already a solved problem in hCalendar)? Lets try to keep this MICRO and not go wild attempting to layer more and more data into hAudio/Media-format. -brian -- brian suda http://suda.co.uk ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] An argument against 'fn' in hAudio (was: Second attempt at hAudio proposal)
On 5/8/07, Manu Sporny [EMAIL PROTECTED] wrote: Manu Sporny wrote: - The use of 'fn' instead of 'work-title'. It has been proposed that 'fn' or 'n' be used instead of 'work-title', or 'title'. What follows is an argument against using 'fn' and 'n' for hAudio. Assumptions: - It is important that we choose the generic names that span all microformats carefully. - Our goal is to lower the cognitive load of website designers using Microformats by re-using terms that are semantically equivalent. Argument: fn is far too heavyweight for hAudio --- a disagree, FN is the lightest weight most flexible property. fn is short for 'full-name' and is grounded in the VCARD/hCard format. The sub-properties of 'fn' and 'n' are: family-name, given-name, additional-name, honorific-prefix, honorific-suffix [1]. These are all related to 'proper names' - none of them have any meaning when applied to hAudio. --- N should NOT be considered, it has nothing to do with this conversation. hReview also uses FN for the FORMATTED NAME. FN is NOT full-name. FN was taken from VCARD, but the semantics are defined as: The name of the object.[1] which has nothing to do with VCARD and can easily be reused in other formats. The optimization rules for interpreting 'fn' are quite complex [2], for example: If 'FN' and 'ORG' are not the same (see previous section), and the value of the 'FN' property is exactly two words (separated by whitespace), and there is no explicit 'N' property, then the 'N' property is inferred from the 'FN' property. For 'FN's with either one word see below, and for three or more, the author MUST explicitly markup the 'N', except for the organization contact info case, see above (http://microformats.org/wiki/hcard#Organization_Contact_Info) for that. --- since you are NOT dealing with N and ORG, you can completely ignore all of this with no issues. None of this applies to hAudio - and we don't want Microformat implementors confusing how to use 'fn' in hAudio and how to use 'fn' in hCard. --- these are two very different things. This is a non-issue. hCard parsers do onething, and you can defined Media parsers to do something completely different. FN is just a semantic value not defining parsing instructions, that is up to the format. Unless a solid argument is presented for using 'fn' instead of 'work-title', the proposal will stay with 'work-title'. --- i would say just the opposite. FN works, you need a strong argument on WHY we need to create YET ANOTHER property called 'work-title'? -brian [1] - http://microformats.org/wiki/classes -- brian suda http://suda.co.uk ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] First draft of hAudio proposal
On 5/2/07, Manu Sporny [EMAIL PROTECTED] wrote: I'm not opposed to using a different separator. Although, I don't think the separator is what most are concerned about on the list. Most of the concern is coming from the following two camps: * Are sparse groups really a problem?! [1] * Names spaces are pure evil! Hang anybody that proposes anything that looks like a name space! :) [2] --- i get the feeling that this thread is disolving into personal ideas about what SHOULD be in an hAudio format and grouping? i can't help but think, is this a problem that NEEDS solving? have you attempted to mark-up audio formats with hListing or hReview? both of those formats cover just about everything except the download links... if that is the case we should think MICRO and look into creating specific rel-values that any format could use. From what is seems from your schema is that you have metadata about the downloadable file. hReview has almost all the same metadata fields except price and length. hListing has price. Can this problem be solved without inventing a new format? Can this be solved by extending an existing format? Can this be solved by creating small building block formats that can be reused in other formats? Can this be solved only be creating a new hAudio format? One of my other conserns is that hAudio is specific to audio, but the fields being used could easily apply to media in general. Is the research for this format not better suited for the more general media-info[1]? -brian [1] - http://microformats.org/wiki/media-info -- brian suda http://suda.co.uk ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Namespacing in hAudio (Was: First draft of hAudio proposal)
On 5/1/07, James Craig [EMAIL PROTECTED] wrote: I'm curious why class namespacing is vehemently opposed in other Microformats, but proposed in hAudio. --- it should be here as well. -brian -- brian suda http://suda.co.uk ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Legal implications of using Microformats
i suggest that if this is not a discussion about a specific new microformat that we move this thread to the 'discuss-list' where other people might be able to give their thoughts. -brian On 4/27/07, Guy Fraser [EMAIL PROTECTED] wrote: Hiya, Manu Sporny wrote: Would the mandatory placement of all examples, formats, brainstorming, proposals, and drafts under a Creative Commons Attribution-Share Alike 3.0 License go towards solving that problem? * It would allow for the commercial and non-commercial use of the format. * It would ensure that people could contribute without worrying about copyright assertions from other authors. Uhm, not really. 1. Share alike is still a problem for some corporates. This is the whole reason why a growing number of organisations now run screaming when they see LGPL, GPL, cc-* 2. Um, possibly. But again, why not just release under New BSD or similar certified open source license. New BSD still requires attribution which everyone is fine with IMHO. Having each uF under a New BSD license and having a contributors page should make everything crystal clear and very tempting for adoption by big companies. That coupled with a patent statement on the Microformat stating that full disclosure has been performed by all authors and contributors to a Microformat. Authors are not allowed to contribute to Microformats if their organization holds any sort of patent covering their proposals. a) Who would own the patent? b) What's to stop them from changing the licensing of the patent? (the patent in itself is not a licensing scheme, it's a mechanism to prevent others from using the work without license) c) Why would I contribute to someone else's patent, especially when I don't see the point of the patent in the first place? The Microformats community could even put up a terms of use asserting that anybody that is going to author a Microformat must agree to the previous two requirements before contributing. Again, if things were released under New BSD or similar certified open source license, there would be no problem. Everything you put on this site will be released under New BSD license - if you don't like that, don't do it. I'm still waiting for someone to properly address these 2 key issues: 1. Why not just release the existing uF stuff as certified open source? Completely remove licensing issues from the mix? 2. Why not just remove the patent statement - if it's certified open source is there any need to patent it? The *only* reasons I'm aware of for patenting something are a) stop other people working in that field and b) make money from licensing. If the uF community is wanting to have their work mass adopted and are not looking for financial gain, why not address these two fundamental issues above? *puts flack jacket on and hides behind a tree* Guy ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new -- brian suda http://suda.co.uk ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
