Re: [uf-new] [hAudio] fn _or_ album
div class=haudio span class=fnIn Rainbows/span /div No, that’d be a track. That would be an audio recording. It may be a track, or an album, or something else entirely, but there's not enough information in the markup to determine anything more than it's an audio recording. Oops, sorry. But why could it be an album, wouldn’t it need to be ‘fn album’ then? ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] [hAudio] fn _or_ album
Good Morning Julian On Sun, 2007-11-04 at 09:28 +, Julian Stahnke wrote: div class=haudio span class=fnIn Rainbows/span /div No, that’d be a track. That would be an audio recording. It may be a track, or an album, or something else entirely, but there's not enough information in the markup to determine anything more than it's an audio recording. Oops, sorry. But why could it be an album, wouldn’t it need to be ‘fn album’ then? This is whats confusing about the whole fn album proposal fn album, means album album, means album fn means the name of the haudio object... which could be and album? three ways of saying the SAME thing, looks like bashing it with a hammer and making it fit to me... not very microformaty at all! Thanks Martin ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] [hAudio] fn _or_ album
On Nov 4, 2007, at 2:28 AM, Julian Stahnke wrote: div class=haudio span class=fnIn Rainbows/span /div No, that’d be a track. That would be an audio recording. It may be a track, or an album, or something else entirely, but there's not enough information in the markup to determine anything more than it's an audio recording. Oops, sorry. But why could it be an album, wouldn’t it need to be ‘fn album’ then? It would, but the lack of that doesn't make it not an album; it just makes it ambiguous. On Nov 4, 2007, at 3:16 AM, Martin McEvoy wrote: This is whats confusing about the whole fn album proposal fn album, means album album, means album fn means the name of the haudio object... which could be and album? Trying thinking of it like this: 1) class=album means name of album 2) class=fn means name of audio 3) If name of album and name of audio are same, audio is album. The third factor is not a re-definition of the property names when combined (there is no such thing in HTML); it's a consequence of two distinct properties having the same value (whether or not they're in the same element). -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hTurtle: A GRDDL-Compatible Microformat for Turtle-in-HTML
On 11/4/07, Scott Reynen [EMAIL PROTECTED] wrote: This may seem pedantic, but given your interest in semantics, I'm sure you can appreciate our interest in keeping the term microformat meaningful, not just another buzz word. I prefer to use the term semantic data format for microformats that have not gone through The Process for this reason. -- Tom Morris http://tommorris.org/ ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hTurtle not a microformat nor even POSH
On 11/4/07 7:16 AM, Tom Morris [EMAIL PROTECTED] wrote: On 11/4/07, Scott Reynen [EMAIL PROTECTED] wrote: This may seem pedantic, but given your interest in semantics, I'm sure you can appreciate our interest in keeping the term microformat meaningful, not just another buzz word. I prefer to use the term semantic data format for microformats that have not gone through The Process for this reason. It's actually one of the reasons we came up with POSH - Plain Old Semantic HTML, for semantic HTML conventions which have not gone through the process. In the case of hTurtle however, there are several principles being violated: 1. Invisible data. The data in comments is invisible. 2. Comment hack. Comments and their contents aren't markup. Putting data into comments isn't using markup, it's abusing the syntax of markup. 3. Violating DRY. In the example the information is duplicated in the h1 and in the comment. 4. Premature naming. DO NOT start with even labeling your effort hXYZ. This is a very common mistake. http://microformats.org/wiki/process#Naming_considerations So as Scott said, hTurtle is not a microformat, but worse than that, it is also not even POSH. Tantek ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
[uf-new] Re: hTurtle: A GRDDL-Compatible Microformat for Turtle-in-HTML
Tantek Çelik [EMAIL PROTECTED] wrote: 1. Invisible data. The data in comments is invisible. Oh dear. You should tell that to whoever wrote this section: http://www.w3.org/TR/html401/interact/scripts.html#h-18.3.2 It's not invisible to the XML Infoset, or the DOM, or SAX parsers, or XSLT, or regular expressions, or so on, which is how hTurtle is able to meet its requirements. hTurtle's requirements mightn't align with those stated in The Process, of course. See my message to Scott for more about that. (I've been told that data is a plural, incidentally!) 2. Comment hack. Comments and their contents aren't markup. What about QNames in attribute values? If I'd been using an SGML NOTATION section or something then I'd understand your concern—or The Process's concern. Masahide Kanzaki has one of my favourite examples of exploiting the joy of comments: http://www.kanzaki.com/parts/xsltdoc.xsl I agree that it's a crap way to do it in HTML, but then that's grafting arms onto the HTML hamburger for you. 3. Violating DRY. Okay, this is a point that I utterly concede. It's absolutely stupid to have to repeat the information, and that's a poor demonstration of hTurtle. I couldn't think of anything else that was as simple and yet shows clearly what it does. In actual use one might be providing a machine readable form of say prose describing the model of an RDF Schema. Of course you can go from the RDF to the HTML rather than embedding the RDF in the HTML, but I'm not saying that hTurtle is an especially good idea as a format. It does, speaking from an engineering point of view, work, however. You get triples from it. 4. Premature naming. DO NOT start with even labeling your effort hXYZ. This is a very common mistake. I think I addressed this in my reply to Scott. Please let me know if I didn't. When someone pointed out that I'd got replies on microformats-new, they did it by saying you've awoken the Tantek!, which I think is coded speak for you've elicited a rare reply from a supreme honcho. I still owe you a big one for your forgiveness after I tore the design of your weblog a new ass when in fact you were just adapting common designs to be standards compliant. So now I owe you two big ones. -- Sean B. Palmer, http://inamidst.com/sbp/ ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Re: hTurtle: A GRDDL-Compatible Microformat for Turtle-in-HTML
On Nov 4, 2007, at 2:41 PM, Sean B. Palmer wrote: 1. Invisible data. The data in comments is invisible. It's not invisible to the XML Infoset, or the DOM, or SAX parsers, or XSLT, or regular expressions, or so on, which is how hTurtle is able to meet its requirements. No, it's invisible to people, and focusing on data that's *visible* to people is a (maybe *the*) distinguishing characteristic of microformats. That's what people in this community mean when we say microformat, so coming here and using that term meaning something completely different is like going to China and speaking to everyone in English. There's little to be gained from this, and much to be lost. -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] [hAudio] fn _or_ album
On Nov 4, 2007, at 9:14 AM, Martin McEvoy wrote: 3) If name of album and name of audio are same, audio is album. fn album is being used to set a fn type of album No, it indicates the type of audio, not the type of name. There is no joint fn album property; that's two completely separate properties that happen to be classifying the same element. In HTML, one class name has no effect on the meaning of another. FN in HAUDIO *always* means name of audio. Imagine in real life someone asks you if you've heard Unicorns are Awesome. From that, you know Unicorns are Awesome is the name of some audio. Now imagine two weeks later someone asks you if you've seen the new album they bought, and you ask them what it's called, and they say Unicorns are Awesome. Now you know Unicorns are Awesome is the name of an album. You can put those two independent pieces of information together to infer a third piece of information: the album and the piece of audio are very likely the same thing because they have the same name. That third piece of information comes from the previous two pieces of information, but it doesn't change them at all. The name of the audio is still the name of the audio, and the name of the album is still the name of the album. Similarly, an hCard analogy: if you asked me who I work for, I might tell you John Deere, and give you the contact information for my employer (though that's not actually who I work for). Without any more information, you'd probably assume John Deere is a person, my boss. But then if someone told you there's an organization named John Deere, you'd probably put that together and realize my employer is actually an organization, because an organization and my employer have the same name. hAudio and hCard parsing is just requiring parsers to make this same sort of deduction from existing information. Now can you see why I am concerned about this proposal? I believe you're confused about the proposal and objecting to something that isn't actually proposed. I completely agree we shouldn't redefine FN, but because we're not talking about doing that, that's not really an objection to the hAudio proposal. -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Re: hTurtle: A GRDDL-Compatible Microformat for Turtle-in-HTML
André Luís wrote: From what Sean is describing, if people wanted to display the information in the turtle/rdf format to normal users, they would have to write it twice in different languages. POSH and then hTurtle. See? Just there, I wasn't able to put hturtle and POSH in the same sack... Now, I don't mean to say there's no point in hTurtle. There is, I'm just not sure it fits in the microformats group. Can't we have something in between ufs and pure rdf? There already is something between uFs and pure RDF: RDFa http://www.w3.org/TR/xhtml-rdfa-primer/ Although, marking up Turtle using RDFa is a bit pedantic... :) Just curious... why didn't you use RDFa to do this, Sean? Scott and the rest on this thread are correct - what you have isn't a microformat as this community understands the term, it's something else... for what that's worth. What exactly is the use case behind hTurtle? What are you attempting to accomplish? There are so few in this world that understand the concept of N3, triples and RDF that I wonder how many people have the need for hTurtle? curiously, -- manu ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
