RE: [uf-discuss] Visible Data...a Microformat requirement?
Because it hasn't gone through the (fairly rigorous) demands of the uF process -- the process page on the wiki[1] outlines this. But what I'm hearing is that if it's not visible it cannot go through that process... -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Colin Barrett Sent: Thursday, October 26, 2006 1:38 PM To: Microformats Discuss Subject: Re: [uf-discuss] Visible Data...a Microformat requirement? On Oct 26, 2006, at 7:28 AM, Andy Mabbett wrote: In message [EMAIL PROTECTED], Dr. Ernie Prabhakar [EMAIL PROTECTED] writes As long as you don't call it a microformat, feel free to experiment. :-) Why shouldn't he call it a microformat? Because it hasn't gone through the (fairly rigorous) demands of the uF process -- the process page on the wiki[1] outlines this. -Colin [1] http://microformats.org/wiki/process ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Visible Data...a Microformat requirement?
Yes I was joking, but in the sense of Many a truth said in jest. In my 20+ years in the tech industry I don't think I've a group of people who can be more religious than those discussing technical matters, excepting fundamentalists in any real religion. :) And because religions tend to promote absolutes, they create lots of problems and impede the forward progress of pragmatists. Thus I was trying to make a point without being too pointed. ;) -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andy Mabbett Sent: Thursday, October 26, 2006 1:28 PM To: Microformats Discuss Subject: Re: [uf-discuss] Visible Data...a Microformat requirement? In message [EMAIL PROTECTED], Mike Schinkel [EMAIL PROTECTED] writes cardinal sin Is this a pragmatic group that I'm working with, or a bunch of religious zealots that I've managed to get entangle with? [assuming you're not joking] cardinal in this sense means: essential; of foremost importance; paramount and cardinal sin is a common idiom. See, for example: http://www.answers.com/cardinalr=67 -- Andy Mabbett Say NO! to compulsory ID Cards: http://www.no2id.net/ Free Our Data: http://www.freeourdata.org.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Visible Data...a Microformat requirement?
that is *only* for machine consumption Conversely, if he's unsure whether the metadata *has* to be invisible, then perhaps this is still a worthwhile discussion. For clarity, there is nothing that says that the metadata I was proposing and am additionally envisioning couldn't be visible. It might even become a best practice to make it visible. But in current practice today the data typically isn't visible (if it is there, which is unlikely) and some people might not want to make it visible (probably because they have a pre-Web 2.0 mentality, IMO.) However, if the end result is *outside* the scope of how we as a community understand microformats, don't expect to get a lot of official support Without support, it make little sense to do it, which IMO means creating a parallel initiative which is duplicated effort, will confuse the public, and is just not a good idea all round. But if I can't convince the group that it makes sense, I certainly can't berate the group into doing it. So if I get a consistent no then that's that (kinda funny how in the early days of the web everyone wanted to splinter. :) In particular, it would be confusing for him to call his proposal a microformat if it did not go through the documented microformat process Agreed. -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dr. Ernie Prabhakar Sent: Thursday, October 26, 2006 1:38 PM To: Microformats Discuss Subject: Re: [uf-discuss] Visible Data...a Microformat requirement? Hi Andy, On Oct 26, 2006, at 10:28 AM, Andy Mabbett wrote: In message [EMAIL PROTECTED], Dr. Ernie Prabhakar [EMAIL PROTECTED] writes As long as you don't call it a microformat, feel free to experiment. :-) Why shouldn't he call it a microformat? Sorry, I may have conflated too many issues. The point I wanted to make (which I communicated poorly) is: a) If he's committed to marking up *invisible* metadata that is *only* for machine consumption, then [IMHO] that's beyond the scope of what this group was constituted to do. b) Conversely, if he's unsure whether the metadata *has* to be invisible, then perhaps this is still a worthwhile discussion. c) Either way, he's welcome to experiment with microformat-derived ideas d) However, if the end result is *outside* the scope of how we as a community understand microformats, don't expect to get a lot of official support e) In particular, it would be confusing for him to call his proposal a microformat if it did not go through the documented microformat process http://microformats.org/wiki/process I apologize if that came across as needlessly confrontational. Best, -- Ernie P. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Visible Data...a Microformat requirement?
My suggestion to use invisible data formats was prefaced with the scenario that your data is invisible, based on the subject of this thread. The above criteria seem to contradict the subject of this thread. If that is the case, I apologize. I envision several different needs although not all of them are fleshed out yet. And these are not needs I just think people might have, they are needs that I've envision I will need in order to optimize some projects I have planned. Is the data published on the web today or not? If it is, you should start collecting it and analyzing to see if it's suitable for a microformat. It is possible. I'm doing tons of research right now (killing many trees printing off documents at the W3.org and elsewhere). But maybe not. If it's not published, we can't research the publishing, so we'd be creating a microformat based on assumptions. The example I gave is straightforward, and respectfully I don't think there would be a lot of assumptions. Let me give another example for this use-case (although I'm learning there may be existing things in HTML to resolve this one specific use case.) Consider these three URLs: http://www.foo.com/toyota/4runner/1999/ http://www.foo.com/toyota/1999/4runner/ http://www.foo.com/1999/toyota/4runner/ Assuming they point to the same basic content but have different breadcrumbs: Home Toyota 4Runner 1999 Home Toyota 1999 4Runner Home 1999 Toyota 4Runner However, there really are the same page and I'd like to be able to say that one of them is the primary or authoritative one (the website owner would decide which one) and in the two that are not primary or authoritative they would point to the one that is. It's possible that you could have the following visible on the page: This page is a duplicate of a href=http://www.foo.com/toyota/4runner/1999/; rel=primarywww.foo.com/toyota/4runner/1999//a. As I said, this is but one example of data that helps describe a page that I can envision I will need and that I believe could benefit the web in general if it exists. I wish I had fleshed out my other examples at this point but I haven't yet, and I certainly don't want to get the shot down because I present them prematurely prepared. -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Reynen Sent: Thursday, October 26, 2006 1:46 PM To: Microformats Discuss Subject: Re: [uf-discuss] Visible Data...a Microformat requirement? On Oct 26, 2006, at 3:07 AM, Mike Schinkel wrote: I'm still not convinced. I've only heard generalities and no specifics on anything I've heard regarding my use-case. RDF is far to complicated for the average person creating HTML; one reason why I don't think it will ever fly. I still know of nothing else besides Microformats that can fill this role; can you give me some specifics that: * Is very simple to add * Doesn't require access to head * Can be done today My suggestion to use invisible data formats was prefaced with the scenario that your data is invisible, based on the subject of this thread. The above criteria seem to contradict the subject of this thread. Is the data published on the web today or not? If it is, you should start collecting it and analyzing to see if it's suitable for a microformat. If it's not published, we can't research the publishing, so we'd be creating a microformat based on assumptions. Such an assumption-based process doesn't meet the standards we've been applying to the word microformat. We're not changing that standard because we, as a community, believe that basing formats on existing behavior is an important practice. There are other formats that are based on assumptions, and the complication you don't like is largely a result of that practice. Pick your poison. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Visible Data...a Microformat requirement?
Your always welcome to use HTML class name semantics or other microformat-inspired technologies in your private applications. However, that is a different thing that calling it a microformat and engaging this whole group in vetting and supporting it. If you think this could be a great solution to an existing problem, I encourage to just go ahead and implement it. As long as you don't call it a microformat, feel free to experiment. :-) Well, why I'd prefer not to go it alone is for the very fact of not having the whole group in vet and support it... -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dr. Ernie Prabhakar Sent: Wednesday, October 25, 2006 6:44 PM To: Microformats Discuss Subject: Re: [uf-discuss] Visible Data...a Microformat requirement? Hi Mike, Your always welcome to use HTML class name semantics or other microformat-inspired technologies in your private applications. However, that is a different thing that calling it a microformat and engaging this whole group in vetting and supporting it. If you think this could be a great solution to an existing problem, I encourage to just go ahead and implement it. As long as you don't call it a microformat, feel free to experiment. :-) - Ernie P. On Oct 25, 2006, at 3:15 PM, Mike Schinkel wrote: Thanks Charles. However I still have no idea why these things apply to specifying which page among of group of equivalent pages is authoritative and why Microformats do not. The latter seem a perfect fit to me, and what you listed either don't apply to general web pages, are years off and can't be used today, are not related, or don't provide the features needed. The microformat concept would work perfectly for this (and similar problems.) -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Charles Iliya Krempeaux Sent: Wednesday, October 25, 2006 5:58 PM To: Microformats Discuss Subject: Re: [uf-discuss] Visible Data...a Microformat requirement? Hello Mike, XML, Semantic HTML, and RDF are closely related to what is being done here. But there's alot of other technologies for specific areas. Like with multimedia type thigns we have SMIL, XSPF, etc etc. For databases like things we have CSV, TSV, HTML tables, etc etc. (Obviously I'm not going to try to enumerate every area and every technology... but hopefully this will give you an idea.) ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Visible Data...a Microformat requirement?
Scott: I'm still not convinced. I've only heard generalities and no specifics on anything I've heard regarding my use-case. RDF is far to complicated for the average person creating HTML; one reason why I don't think it will ever fly. I still know of nothing else besides Microformats that can fill this role; can you give me some specifics that: * Is very simple to add * Doesn't require access to head * Can be done today -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Reynen Sent: Wednesday, October 25, 2006 7:31 PM To: Microformats Discuss Subject: Re: [uf-discuss] Visible Data...a Microformat requirement? On Oct 25, 2006, at 5:15 PM, Mike Schinkel wrote: Thanks Charles. However I still have no idea why these things apply to specifying which page among of group of equivalent pages is authoritative and why Microformats do not. The latter seem a perfect fit to me, and what you listed either don't apply to general web pages, are years off and can't be used today, are not related, or don't provide the features needed. The microformat concept would work perfectly for this (and similar problems.) I think the key difference is the subject of this thread. Microformats are good for visible data. Other formats are good for invisible data. Most of what Charles listed is in wide use today. You just don't see it because it's not on the visible web. If the data you want to describe is also not on the visible web, it's probably more appropriate for one of these invisible data formats. Consider reuse of the data. Microformats have less invisible reuse potential because they don't fit a general schema like RDF or XSD. But microformats have more visible reuse potential because, well, the data is visible. If your data is invisible and you tried to format it with microformats, you'd be losing both invisible reuse potential and visible reuse potential. You can pound that nail with a screwdriver, but why would you? Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Visible Data...a Microformat requirement?
On 10/26/06, Mike Schinkel [EMAIL PROTECTED] wrote: Thanks. That maybe solves this use case. Can you do the same using link in the head in case you don't want the hyperlink visible? Or what about on a div within body? And do you know if the search engines pay any attention to this? @rel=bookmark is scoped to the current page, I think. It can be applied to an A or a LINK. -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Visible Data...a Microformat requirement?
In message [EMAIL PROTECTED], Ciaran McNulty [EMAIL PROTECTED] writes @rel=bookmark I've seen several people refer to such things with an opening @ - what does it mean? -- Andy Mabbett Say NO! to compulsory ID Cards: http://www.no2id.net/ Free Our Data: http://www.freeourdata.org.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Visible Data...a Microformat requirement?
In message [EMAIL PROTECTED], Dr. Ernie Prabhakar [EMAIL PROTECTED] writes As long as you don't call it a microformat, feel free to experiment. :-) Why shouldn't he call it a microformat? -- Andy Mabbett Say NO! to compulsory ID Cards: http://www.no2id.net/ Free Our Data: http://www.freeourdata.org.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Visible Data...a Microformat requirement?
On Oct 26, 2006, at 7:25 AM, Andy Mabbett wrote: In message [EMAIL PROTECTED], Ciaran McNulty [EMAIL PROTECTED] writes @rel=bookmark I've seen several people refer to such things with an opening @ - what does it mean? I'm not sure on the etymology, but they're referring to attributes on (X)HTML tags. -Colin ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Visible Data...a Microformat requirement?
On Oct 26, 2006, at 7:28 AM, Andy Mabbett wrote: In message [EMAIL PROTECTED], Dr. Ernie Prabhakar [EMAIL PROTECTED] writes As long as you don't call it a microformat, feel free to experiment. :-) Why shouldn't he call it a microformat? Because it hasn't gone through the (fairly rigorous) demands of the uF process -- the process page on the wiki[1] outlines this. -Colin [1] http://microformats.org/wiki/process ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Visible Data...a Microformat requirement?
On Oct 26, 2006, at 3:07 AM, Mike Schinkel wrote: I'm still not convinced. I've only heard generalities and no specifics on anything I've heard regarding my use-case. RDF is far to complicated for the average person creating HTML; one reason why I don't think it will ever fly. I still know of nothing else besides Microformats that can fill this role; can you give me some specifics that: * Is very simple to add * Doesn't require access to head * Can be done today My suggestion to use invisible data formats was prefaced with the scenario that your data is invisible, based on the subject of this thread. The above criteria seem to contradict the subject of this thread. Is the data published on the web today or not? If it is, you should start collecting it and analyzing to see if it's suitable for a microformat. If it's not published, we can't research the publishing, so we'd be creating a microformat based on assumptions. Such an assumption-based process doesn't meet the standards we've been applying to the word microformat. We're not changing that standard because we, as a community, believe that basing formats on existing behavior is an important practice. There are other formats that are based on assumptions, and the complication you don't like is largely a result of that practice. Pick your poison. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Visible Data...a Microformat requirement?
On 26 Oct 2006, at 18:35, Colin Barrett wrote: On Oct 26, 2006, at 7:25 AM, Andy Mabbett wrote: In message [EMAIL PROTECTED], Ciaran McNulty [EMAIL PROTECTED] writes @rel=bookmark I've seen several people refer to such things with an opening @ - what does it mean? I'm not sure on the etymology, but they're referring to attributes on (X)HTML tags. It's a lazy XPath-ish syntax that a has slipped into the geek vocabulary (much as CSS selectors are sometimes used to quickly describe a structure of elements). @ represents an attribute, so @rel=tag means @rel tag with the value ‘tag’. The most advanced I've seen it get in general discussion is of the form [EMAIL PROTECTED], which means ‘element named foo with an attribute bar with value ‘sheep’. If people object, it's probably unreasonable to ask us not to use such abbreviation, or preferably (for me at least, who likes to abbreviate like that) perhaps we should document the shorthand on the Wiki? Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Visible Data...a Microformat requirement?
On Oct 26, 2006, at 8:04 AM, Ben Ward wrote: On 26 Oct 2006, at 18:35, Colin Barrett wrote: On Oct 26, 2006, at 7:25 AM, Andy Mabbett wrote: In message [EMAIL PROTECTED], Ciaran McNulty [EMAIL PROTECTED] writes @rel=bookmark I've seen several people refer to such things with an opening @ - what does it mean? I'm not sure on the etymology, but they're referring to attributes on (X)HTML tags. It's a lazy XPath-ish syntax that a has slipped into the geek vocabulary (much as CSS selectors are sometimes used to quickly describe a structure of elements). Ah, XPath. My guess was CSS selectors, but the syntax there is a bit different. @ represents an attribute, so @rel=tag means @rel tag with the value ‘tag’. The most advanced I've seen it get in general discussion is of the form [EMAIL PROTECTED], which means ‘element named foo with an attribute bar with value ‘sheep’. Technically, in CSS, that would be written as foo[bar=sheep]. :P If people object, it's probably unreasonable to ask us not to use such abbreviation, or preferably (for me at least, who likes to abbreviate like that) perhaps we should document the shorthand on the Wiki? It's a handy abbreviation, and it should definitely be documented on the wiki (Perhaps on the mailinglist page? Unless it is used on the wiki as well...). -Colin___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Visible Data...a Microformat requirement?
On 27 Oct 2006, at 00:58, Colin Barrett wrote: @ represents an attribute, so @rel=tag means @rel tag with the value ‘tag’. The most advanced I've seen it get in general discussion is of the form [EMAIL PROTECTED], which means ‘element named foo with an attribute bar with value ‘sheep’. Technically, in CSS, that would be written as foo[bar=sheep]. :P Indeed, although in XPath [EMAIL PROTECTED] is correct. Actually, you raise a good example since CSS allows you to say foo[bar~=sheep], (note the tilda), which is correct for matching the substring contents of string separated list attributes like class and rel. I will be happy to chip in on documenting this in the Wiki, but my todo list is really busy so I might not get round to writing something of any quality for too long. If someone else is able to start it I'll try and chip in. Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Visible Data...a Microformat requirement?
Hello Mike, XML, Semantic HTML, and RDF are closely related to what is being done here. But there's alot of other technologies for specific areas. Like with multimedia type thigns we have SMIL, XSPF, etc etc. For databases like things we have CSV, TSV, HTML tables, etc etc. (Obviously I'm not going to try to enumerate every area and every technology... but hopefully this will give you an idea.) See ya On 10/25/06, Mike Schinkel [EMAIL PROTECTED] wrote: Yes, there are other tools better suited to solving problems outside the scope of microformats, Can you please point me to those tools? I'm not aware of any that are available. Alternately, do I need to start a MicroDirectives initiative? :-) -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Reynen Sent: Tuesday, October 24, 2006 8:25 AM To: Microformats Discuss Subject: Re: [uf-discuss] Visible Data...a Microformat requirement? On Oct 24, 2006, at 3:41 AM, Mike Schinkel wrote: Is there a clear and definitive objective statement that explains the class of problems that microformats are intended to solve? I've not sure the context of this question, but I think the closest we have is from the about page [1]: Designed for humans first and machines second, microformats are a set of simple, open data formats built upon existing and widely adopted standards. Instead of throwing away what works today, microformats intend to solve simpler problems first by adapting to current behaviors and usage patterns (e.g. XHTML, blogging). Further, if there is such a statement, is there a reason to limit Microformats to only be used to solve that class of problems when they otherwise can solve additional problems? Yes, there are other tools better suited to solving problems outside the scope of microformats, and trying to duplicate these efforts is a waste of time that could be otherwise spent solving previously unsolved problems. See the microformats are not section on the about page [1]. For an example that that answers the question in the subject of this email, RDF is a well-established standard for publishing invisible data. [1] http://microformats.org/about/ Peace, Scott -- Charles Iliya Krempeaux, B.Sc. charles @ reptile.ca supercanadian @ gmail.com developer weblog: http://ChangeLog.ca/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Visible Data...a Microformat requirement?
Thanks Charles. However I still have no idea why these things apply to specifying which page among of group of equivalent pages is authoritative and why Microformats do not. The latter seem a perfect fit to me, and what you listed either don't apply to general web pages, are years off and can't be used today, are not related, or don't provide the features needed. The microformat concept would work perfectly for this (and similar problems.) -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Charles Iliya Krempeaux Sent: Wednesday, October 25, 2006 5:58 PM To: Microformats Discuss Subject: Re: [uf-discuss] Visible Data...a Microformat requirement? Hello Mike, XML, Semantic HTML, and RDF are closely related to what is being done here. But there's alot of other technologies for specific areas. Like with multimedia type thigns we have SMIL, XSPF, etc etc. For databases like things we have CSV, TSV, HTML tables, etc etc. (Obviously I'm not going to try to enumerate every area and every technology... but hopefully this will give you an idea.) ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Visible Data...a Microformat requirement?
Hi Mike, Your always welcome to use HTML class name semantics or other microformat-inspired technologies in your private applications. However, that is a different thing that calling it a microformat and engaging this whole group in vetting and supporting it. If you think this could be a great solution to an existing problem, I encourage to just go ahead and implement it. As long as you don't call it a microformat, feel free to experiment. :-) - Ernie P. On Oct 25, 2006, at 3:15 PM, Mike Schinkel wrote: Thanks Charles. However I still have no idea why these things apply to specifying which page among of group of equivalent pages is authoritative and why Microformats do not. The latter seem a perfect fit to me, and what you listed either don't apply to general web pages, are years off and can't be used today, are not related, or don't provide the features needed. The microformat concept would work perfectly for this (and similar problems.) -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Charles Iliya Krempeaux Sent: Wednesday, October 25, 2006 5:58 PM To: Microformats Discuss Subject: Re: [uf-discuss] Visible Data...a Microformat requirement? Hello Mike, XML, Semantic HTML, and RDF are closely related to what is being done here. But there's alot of other technologies for specific areas. Like with multimedia type thigns we have SMIL, XSPF, etc etc. For databases like things we have CSV, TSV, HTML tables, etc etc. (Obviously I'm not going to try to enumerate every area and every technology... but hopefully this will give you an idea.) ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Visible Data...a Microformat requirement?
On Oct 25, 2006, at 5:15 PM, Mike Schinkel wrote: Thanks Charles. However I still have no idea why these things apply to specifying which page among of group of equivalent pages is authoritative and why Microformats do not. The latter seem a perfect fit to me, and what you listed either don't apply to general web pages, are years off and can't be used today, are not related, or don't provide the features needed. The microformat concept would work perfectly for this (and similar problems.) I think the key difference is the subject of this thread. Microformats are good for visible data. Other formats are good for invisible data. Most of what Charles listed is in wide use today. You just don't see it because it's not on the visible web. If the data you want to describe is also not on the visible web, it's probably more appropriate for one of these invisible data formats. Consider reuse of the data. Microformats have less invisible reuse potential because they don't fit a general schema like RDF or XSD. But microformats have more visible reuse potential because, well, the data is visible. If your data is invisible and you tried to format it with microformats, you'd be losing both invisible reuse potential and visible reuse potential. You can pound that nail with a screwdriver, but why would you? Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Visible Data...a Microformat requirement?
Search engines make use of shingles to identify pages and their aliases. What's a shingle? As far as I can tell, this isn't in the same class of problems that microformats solve. Is there a clear and definitive objective statement that explains the class of problems that microformats are intended to solve? Further, if there is such a statement, is there a reason to limit Microformats to only be used to solve that class of problems when they otherwise can solve additional problems? This probably best resolved by agreeing what we mean by metadata, Because of judicious editing required by forum policy, I've lost the prior of the discussion so I'm not sure the context in which I mentioned metadata. -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Benjamin West Sent: Monday, October 23, 2006 2:01 PM To: Microformats Discuss Subject: Re: [uf-discuss] Visible Data...a Microformat requirement? So, what if your take on this problem and use-case? Search engines make use of shingles to identify pages and their aliases. Some search engines employ teams of editors and solicit feedback from the web community to ensure their aliasing techniques are correct. As far as I can tell, this isn't in the same class of problems that microformats solve. This probably best resolved by agreeing what we mean by metadata, as the scope of definition and contents of that term seem to be somewhat disputed and/or misunderstood as well as the scope of the problem space of microformats. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Visible Data...a Microformat requirement?
It'd take a lot to convince me that HEAD isn't the place for meta-data, for a start ;-) I agree with you in concept, but the problem is that (I'm guessing) 99% of wiki, cms, and forum users will have no access to adding information into the HEAD so you are leaving all of them out in the cold. And I'll bet that the comprise the vast majority of content creators on the web. You could potentially use that in your markup, but using it with an 'empty' link wouldn't be something that I'd find appealing, I agree. I think a div encapsulting the user's content should do just fine, no? The microformats list and/or IRC channel are, I've found, a great place to discuss semantic XHTML in general. I'd encourage you to publish your data using whatever sensible scheme you deem appropriate, maybe after some discussion here and elsewhere. I'll be happy to do that, assuming I don't get shot down for posting discussions on the list for topics the group has decided not to support. :) -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ciaran McNulty Sent: Monday, October 23, 2006 6:08 AM To: Microformats Discuss Subject: Re: [uf-discuss] Visible Data...a Microformat requirement? On 10/23/06, Mike Schinkel [EMAIL PROTECTED] wrote: I'd suggest could be solved using an appropriate new [EMAIL PROTECTED], and then convicing the search engines to pay attention to it ;-) Do you mean in head? Did you see my earlier comments about wikis, CMS, and forums, where the user often may not have control of putting things in head? I did, I'm not sure what to think about it. It'd take a lot to convince me that HEAD isn't the place for meta-data, for a start ;-) The similarities between this and [EMAIL PROTECTED]alternate are particularly striking, and so that's the solution that would immediately suggest itself to me. [EMAIL PROTECTED]bookmark [1] encapsulates some of the semantics of being an 'authoritative version' of an item (for instance in hAtom[2]). You could potentially use that in your markup, but using it with an 'empty' link wouldn't be something that I'd find appealing, YMMV. I can do two things; implement it and probably get it wrong because I'd not have the benefit of feedback from the so many skilled people involved in Microformats, or include in the Microformats process and get the feedback to make it (and others) the best they can be. The microformats list and/or IRC channel are, I've found, a great place to discuss semantic XHTML in general. I'd encourage you to publish your data using whatever sensible scheme you deem appropriate, maybe after some discussion here and elsewhere. -Ciaran McNulty [1] http://microformats.org/wiki/rel-bookmark#rel.3D.22bookmark.22 [2] http://microformats.org/wiki/hatom#Entry_Permalink ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Visible Data...a Microformat requirement?
On Oct 24, 2006, at 3:41 AM, Mike Schinkel wrote: Is there a clear and definitive objective statement that explains the class of problems that microformats are intended to solve? I've not sure the context of this question, but I think the closest we have is from the about page [1]: Designed for humans first and machines second, microformats are a set of simple, open data formats built upon existing and widely adopted standards. Instead of throwing away what works today, microformats intend to solve simpler problems first by adapting to current behaviors and usage patterns (e.g. XHTML, blogging). Further, if there is such a statement, is there a reason to limit Microformats to only be used to solve that class of problems when they otherwise can solve additional problems? Yes, there are other tools better suited to solving problems outside the scope of microformats, and trying to duplicate these efforts is a waste of time that could be otherwise spent solving previously unsolved problems. See the microformats are not section on the about page [1]. For an example that that answers the question in the subject of this email, RDF is a well-established standard for publishing invisible data. [1] http://microformats.org/about/ Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Visible Data...a Microformat requirement?
On 10/22/06 11:10 PM, Mike Schinkel [EMAIL PROTECTED] wrote: Brian Suda recently said: the problem with using Meta elements is that they are out-side of human-readable realm. One of the key factors in microformats is to keep the data visible, it keeps it fresh, prevents many of the abuses that have befallen meta-keywords, and also allows for microformats to be fully emebedded in other formats like Atom, RSS, etc. My question is this: What about when what you have is really metadata and not anything (currently, at least) stored on the HTML page? Rarely is metadata actually metadata. It is most often simply properties of the information which are still relevant to the user and thus should be visible. If it is not worth or appropriate to make the information visible, then it is not worth trusting the information and certainly not worth the time to make a microformat for it. Note that in addition to visible text, visibility can be in the form of a the interactivity of a hyperlink (its URL), or in the CSS used to style something with a particular attribute (e.g. XFN), or in the tooltip shown for title attributes. (I'm asking because several things I want to propose will fit into that category...) Have you tried using as many existing microformats as you can on your current sites? Tantek ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Visible Data...a Microformat requirement?
It is most often simply properties of the information which are still relevant to the user and thus should be visible. Okay, I think I can probably agree while still holding out the potential to uncover needs in the future that do not fit that pattern. If it is not worth or appropriate to make the information visible, then it is not worth trusting the information and certainly not worth the time to make a microformat for it. But what if the website publisher (or graphic designer) does not want that information to be visible on the page? Some may, but other's may not. I'm trying to follow the principle that Microformats should not require the user to really change anything beyond adding Microformat functionality. If they don't currently display this metadata, are you saying that a Microformat should force them to do so? Have you tried using as many existing microformats as you can on your current sites? O Yeah! I've been combing through even Microformat you have listed and reading each in-depth. Sad to say, but I've probaby got more than twice as many in mind as you currently have listed... But I don't want to propose anything until I've got time to flesh them out otherwise I'll be in a bloodbath of trying to justify them before I've done all the required research. That said, what if I have a need for a microformat but have no idea what the best name for it would be? Ideally I'd like to present the concept and get help with naming. But currently the process seems to be to give is a name on a wiki page and document it? How can I do that w/o a name (I know I'm being pedantic, but I'm actually trying to call the question of how to consistantly go about using the community to help find a name for a potential uF.) -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tantek Ç elik Sent: Monday, October 23, 2006 2:16 AM To: microformats-discuss Subject: Re: [uf-discuss] Visible Data...a Microformat requirement? On 10/22/06 11:10 PM, Mike Schinkel [EMAIL PROTECTED] wrote: Brian Suda recently said: the problem with using Meta elements is that they are out-side of human-readable realm. One of the key factors in microformats is to keep the data visible, it keeps it fresh, prevents many of the abuses that have befallen meta-keywords, and also allows for microformats to be fully emebedded in other formats like Atom, RSS, etc. My question is this: What about when what you have is really metadata and not anything (currently, at least) stored on the HTML page? Rarely is metadata actually metadata. It is most often simply properties of the information which are still relevant to the user and thus should be visible. If it is not worth or appropriate to make the information visible, then it is not worth trusting the information and certainly not worth the time to make a microformat for it. Note that in addition to visible text, visibility can be in the form of a the interactivity of a hyperlink (its URL), or in the CSS used to style something with a particular attribute (e.g. XFN), or in the tooltip shown for title attributes. (I'm asking because several things I want to propose will fit into that category...) Have you tried using as many existing microformats as you can on your current sites? Tantek ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Visible Data...a Microformat requirement?
On 10/23/06 12:11 AM, Mike Schinkel [EMAIL PROTECTED] wrote: If it is not worth or appropriate to make the information visible, then it is not worth trusting the information and certainly not worth the time to make a microformat for it. But what if the website publisher (or graphic designer) does not want that information to be visible on the page? Then it is not worth trusting the information nor worth the time making a microformat for it. Some may, but other's may not. I'm trying to follow the principle that Microformats should not require the user to really change anything beyond adding Microformat functionality. That's right. If they don't currently display this metadata, are you saying that a Microformat should force them to do so? No, I am saying that the microformat shouldn't bother representing it. Keep microformats as simple and as minimal as possible. That means invisible data and properties are left out of microformats. Have you tried using as many existing microformats as you can on your current sites? O Yeah! I've been combing through even Microformat you have listed and reading each in-depth. Sad to say, but I've probaby got more than twice as many in mind as you currently have listed... It doesn't matter how many you may have in mind. The question remains - have you tried using *just* the existing microformats to at least add some more semantics to your pages? But I don't want to propose anything until I've got time to flesh them out otherwise I'll be in a bloodbath of trying to justify them before I've done all the required research. By using existing microformats first, you will better understand what may need to be created. Postpone proposing any microformats until you have first made use of existing ones. Thanks, Tantek ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Visible Data...a Microformat requirement?
In message [EMAIL PROTECTED], Tantek Çelik [EMAIL PROTECTED] writes Rarely is metadata actually metadata. It is most often simply properties of the information which are still relevant to the user and thus should be visible. If it is not worth or appropriate to make the information visible, then it is not worth trusting the information and certainly not worth the time to make a microformat for it. Those are interesting opinions, but you appear to believe that people should treat them as irrefutable facts. Note that in addition to visible text, visibility can be in [...] in the CSS used to style something with a particular attribute (e.g. XFN) CSS is not meant to provide information, just presentation. The information should not be lost to the user, just because CSS are not available to them. -- Andy Mabbett Say NO! to compulsory ID Cards: http://www.no2id.net/ Free Our Data: http://www.freeourdata.org.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Visible Data...a Microformat requirement?
In message [EMAIL PROTECTED], Tantek Çelik [EMAIL PROTECTED] writes But what if the website publisher (or graphic designer) does not want that information to be visible on the page? Then it is not worth trusting the information nor worth the time making a microformat for it. Again, interesting opinions, but not hard facts. If they don't currently display this metadata, are you saying that a Microformat should force them to do so? No, I am saying that the microformat shouldn't bother representing it. That means invisible data and properties are left out of microformats. Consider a page of events, with variable start times; and an introductory paragraph which says all events last for two hours. You're saying that the microformat should not include a dtend with the end time, for each event, because that end time is not separately and explicitly displayed to the user? -- Andy Mabbett Say NO! to compulsory ID Cards: http://www.no2id.net/ Free Our Data: http://www.freeourdata.org.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Visible Data...a Microformat requirement?
Hello Andy, On 10/23/06, Andy Mabbett [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED], Tantek Çelik [EMAIL PROTECTED] writes Rarely is metadata actually metadata. It is most often simply properties of the information which are still relevant to the user and thus should be visible. If it is not worth or appropriate to make the information visible, then it is not worth trusting the information and certainly not worth the time to make a microformat for it. Those are interesting opinions, but you appear to believe that people should treat them as irrefutable facts. You are of course free to create any Semantic HTML you want. But Microformats are a special kind of Semantic HTML. And one of the things about them is that they are visible. That doesn't means invisible metadata is bad. But that's not what Microformats are about. Also, Microformats aren't the end all and be all. Fell free to explore and create your own Semantic HTML. Even Semantic HTML with invisible metadata. Perhaps other will even use it if they find it useful. [...] See ya -- Charles Iliya Krempeaux, B.Sc. charles @ reptile.ca supercanadian @ gmail.com developer weblog: http://ChangeLog.ca/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Visible Data...a Microformat requirement?
On 10/23/06, Andy Mabbett [EMAIL PROTECTED] wrote: Consider a page of events, with variable start times; and an introductory paragraph which says all events last for two hours. You're saying that the microformat should not include a dtend with the end time, for each event, because that end time is not separately and explicitly displayed to the user? In that example there isn't any invisible data, the duration is clearly present on the page. When we talk about 'hidden data' we mean things like, if the author didn't want to mention the duration anywhere on the page but still have all the events being 2 hours wrong. The general use-case of microformats is in marking up existing data in a way that makes it more semantic and therefore machine-readable. If something's considered important enough to tell a parser about, it should probably be important enough to tell a human about. For the specific example you mention, the '2 hours' declaration could probably be used as the DURATION (probably with an ABBR) and then transcluded into each VEVENT using the include-pattern. -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Visible Data...a Microformat requirement?
Then it is not worth trusting the information nor worth the time making a microformat for it. Respectfully, I disagree. I'm also a bit allergic to statements asserting the absoluteness of a concept especially when it is *harder* to prove there is not a needle in a haystack than it is to find one in the haystack if it is known to be there; itself a very difficult task. There can be drivers that can encourage people to maintain information even if not the content is not visible; to achieve a higher search engine ranking could be a good example. I've been very attracted to Microformats because them as being able to solve many problems I've identified. Just a point of note but if I can't use Microformat for them, then that just means the need for another initiative that can solve those problems. I hope that won't be required. BTW, I'm not saying there would not be value in making such information visible, I just didn't want to assume it would be a requirement. Let me go ahead and give you a hypothetical example (I have had the exact problem in the past, so it is a real problem, it's just that explain in hypotheical requires less background explanation): http://www.wiki-info.org/platforms/linux/php/ http://www.software-info.org/wikis/platforms/linux/php/ Both those URLs are different and have different bread crumbs but otherwise the same content. Search engines do not *know* they are the same, but may determine they are similar enough that it will only include one of the URLs in it's index (Google frequently did this to us at VBxtras Xtras.Net back when there were two sites.) However, the search engines may choose to include the page from software-info.org when I'd rather have him include the page from wiki-info.org or vice-versa. So, I would like to be able to define in the software-info.org page that the wiki-info.org page is content-duplicate and authoritative over the existing page. Microformats seem perfect for this, but I can see where website owners may not want to make this type of information visible. So, what if your take on this problem and use-case? It doesn't matter how many you may have in mind. The question remains - have you tried using *just* the existing microformats to at least add some more semantics to your pages? I'm confused. I have numerous use-cases where have a microformat would either solve problems or create infrastructure to empower solutions that currently cannot exist. How does my using existing microformat for use-cases I don't currently have specific need for have any relevence? Respectfully speaking, that is like asking the guy who comes to you needing a wrench if he has tried using a screwdriver yet for other needs (which he may not currently have.) -Mike P.S. I'm coming to this working group with a entire series of problems that I experienced trying to run Xtras.Net as well as things I wanted to implement but couldn't because the infrastructure didn't exist. When I ran Xtras.Net I often tried to use technology to solve business problems. That's the perspective with which I come to this, not being just a technologist and thinking wouldn't if be cool if...? but instead a technically-saavy business person envisioning things that could empower solutions with a keen eye towards what will actually be used (because if it won't be used, it won't be beneficial.) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tantek Ç elik Sent: Monday, October 23, 2006 3:25 AM To: microformats-discuss Subject: Re: [uf-discuss] Visible Data...a Microformat requirement? On 10/23/06 12:11 AM, Mike Schinkel [EMAIL PROTECTED] wrote: If it is not worth or appropriate to make the information visible, then it is not worth trusting the information and certainly not worth the time to make a microformat for it. But what if the website publisher (or graphic designer) does not want that information to be visible on the page? Then it is not worth trusting the information nor worth the time making a microformat for it. Some may, but other's may not. I'm trying to follow the principle that Microformats should not require the user to really change anything beyond adding Microformat functionality. That's right. If they don't currently display this metadata, are you saying that a Microformat should force them to do so? No, I am saying that the microformat shouldn't bother representing it. Keep microformats as simple and as minimal as possible. That means invisible data and properties are left out of microformats. Have you tried using as many existing microformats as you can on your current sites? O Yeah! I've been combing through even Microformat you have listed and reading each in-depth. Sad to say, but I've probaby got more than twice as many in mind as you currently have listed... It doesn't matter how many you may have in mind. The question remains - have you tried using *just
RE: [uf-discuss] Visible Data...a Microformat requirement?
I'm not Tantek, but you're use-case seems eminently reasonable, and Thanks! I'd suggest could be solved using an appropriate new [EMAIL PROTECTED], and then convicing the search engines to pay attention to it ;-) Do you mean in head? Did you see my earlier comments about wikis, CMS, and forums, where the user often may not have control of putting things in head? It's very hard to follow the Microformats principle of 'pave the cowpaths' if the information you're trying to enrich isn't currently present in the documents, which means hidden data is fairly heavily discouraged. I understand. Personally, I have need for it in a project I'm planning and will use it in my project. Although I really don't want to say this because it sounds so un-humble, but if my project achieves my vision which I think it can, it will be significant enough by itself to drive interest in the conventions it uses. I can do two things; implement it and probably get it wrong because I'd not have the benefit of feedback from the so many skilled people involved in Microformats, or include in the Microformats process and get the feedback to make it (and others) the best they can be. However, it doesn't really fit in with the aims of Microformats with a big 'M', which are Designed for humans first and machines second Here's just a question: Is it possible to interpret that to mean When there is a conflict, design for humans trumps design for machines? If so, that doesn't *preclude* designing for machines where there isn't a conflict with humans, right? Just another way to look at it...? Again, that's not to say it's not a good idea, it's something I'd be quite interested in too. And there are several more where that one came from. :) Maybe if Tantek vetos you can help me go create yet another initiative for hidden Microformat-like metadata? :-) -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ciaran McNulty Sent: Monday, October 23, 2006 4:26 AM To: Microformats Discuss Subject: Re: [uf-discuss] Visible Data...a Microformat requirement? On 10/23/06, Mike Schinkel [EMAIL PROTECTED] wrote: So, what if your take on this problem and use-case? I'm not Tantek, but you're use-case seems eminently reasonable, and I'd suggest could be solved using an appropriate new [EMAIL PROTECTED], and then convicing the search engines to pay attention to it ;-) However, it doesn't really fit in with the aims of Microformats with a big 'M', which are Designed for humans first and machines second [1]. The scope of what's considered a Microformat is deliberately narrow, and is primarily aimed at adding extra semantics to data that's already present in documents. XFN, for instance, defines a set of @rel values to enrich the semantics of linking to other people's sites/blogs/etc., but it's unlikely that XFN would have been proposed if there wasn't already a huge precendent of people linking to each other's sites, and a percieved need for that extra information to be added to the existing links. It's very hard to follow the Microformats principle of 'pave the cowpaths' if the information you're trying to enrich isn't currently present in the documents, which means hidden data is fairly heavily discouraged. Again, that's not to say it's not a good idea, it's something I'd be quite interested in too. -Ciaran McNulty [1] http://microformats.org/about/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Visible Data...a Microformat requirement?
For the specific example you mention, the '2 hours' declaration could probably be used as the DURATION (probably with an ABBR) and then transcluded into each VEVENT using the include-pattern. do many parsers out there support include-pattern yet? ... whereas any older or very simple hCalendar parser would probably be able to see dtend! ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Visible Data...a Microformat requirement?
On 10/23/06, Michael MD [EMAIL PROTECTED] wrote: For the specific example you mention, the '2 hours' declaration could probably be used as the DURATION (probably with an ABBR) and then transcluded into each VEVENT using the include-pattern. do many parsers out there support include-pattern yet? Not many, but they probably should* ... whereas any older or very simple hCalendar parser would probably be able to see dtend! Well you can put a DTEND in and hide it with CSS if you really must. It's not best practice by any means, but if you're going to aim at existing parsers there's not really another option, sure. -Ciaran McNulty * It's very easy to volunteer other people's time like this, I appreciate ;-) ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Visible Data...a Microformat requirement?
On 10/23/06, Mike Schinkel [EMAIL PROTECTED] wrote: I'd suggest could be solved using an appropriate new [EMAIL PROTECTED], and then convicing the search engines to pay attention to it ;-) Do you mean in head? Did you see my earlier comments about wikis, CMS, and forums, where the user often may not have control of putting things in head? I did, I'm not sure what to think about it. It'd take a lot to convince me that HEAD isn't the place for meta-data, for a start ;-) The similarities between this and [EMAIL PROTECTED]alternate are particularly striking, and so that's the solution that would immediately suggest itself to me. [EMAIL PROTECTED]bookmark [1] encapsulates some of the semantics of being an 'authoritative version' of an item (for instance in hAtom[2]). You could potentially use that in your markup, but using it with an 'empty' link wouldn't be something that I'd find appealing, YMMV. I can do two things; implement it and probably get it wrong because I'd not have the benefit of feedback from the so many skilled people involved in Microformats, or include in the Microformats process and get the feedback to make it (and others) the best they can be. The microformats list and/or IRC channel are, I've found, a great place to discuss semantic XHTML in general. I'd encourage you to publish your data using whatever sensible scheme you deem appropriate, maybe after some discussion here and elsewhere. -Ciaran McNulty [1] http://microformats.org/wiki/rel-bookmark#rel.3D.22bookmark.22 [2] http://microformats.org/wiki/hatom#Entry_Permalink ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Visible Data...a Microformat requirement?
So, what if your take on this problem and use-case? Search engines make use of shingles to identify pages and their aliases. Some search engines employ teams of editors and solicit feedback from the web community to ensure their aliasing techniques are correct. As far as I can tell, this isn't in the same class of problems that microformats solve. This probably best resolved by agreeing what we mean by metadata, as the scope of definition and contents of that term seem to be somewhat disputed and/or misunderstood as well as the scope of the problem space of microformats. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
