Re: [uf-discuss] Regarding Profile URIs and Disambiguation (was Comments from IBM/Lotus rep about Microformats)
On 12/12/06, Scott Reynen [EMAIL PROTECTED] wrote: On Dec 12, 2006, at 4:52 PM, Mike Schinkel wrote: div class=region-data vcard div class=region street title=child-of-city div class=street-address665 3rd St./div div class=extended-addressSuite 207/div /div span class=region city locality title=child-of-stateSan Francisco/span, span class=region state region title=child-of-countryCA/span span class=post-code postal-code94107/span div class=region country country-name title=child-of-continentU.S.A./div /div How to disambiguate with Profile URI? (Please make the assumption that the developer of region-data knew nothing of vcard when region-data was published.) As I've said before, I don't think this kind of same name, same document, different meaning conflict is solved by profile URIs (because they don't have namespaces). But I also think it's both a rare and a bad practice to use one symbol to communicate two different ideas in a single context. Nonetheless, in the interest of ending this discussion, here's what you can do to solve this problem whenever you encounter it: 1) add profiles for both vcard and region-data, e.g.: head profile=http://www.w3.org/2006/03/hcard http://yourdomain.com/ region-data-profile 2) add prefixes to all your region-data tags when you decide to add the conflicting hCard names, e.g.: span class=my-prefix-region my-prefix-city locality title=child-of-stateSan 3) designate that prefix in a meta tag, e.g.: meta name=profile-prefixes content=* my-prefix- / (where * indicates no prefix for hcard) 4) convince developers of region-data parsers to look for prefixes Very good suggestions Scott and similar to eRDF. Note this won't require any changes to hCard. Now you can go crazy with your double entendre markup and this list can move on with developing microformats to solve specific problems. Sound good? 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
[uf-discuss] Regarding Profile URIs and Disambiguation (was Comments from IBM/Lotus rep about Microformats)
brian suda wrote: It is possible for me to start creating a CSS style called 'vcard', but a parser would know that this is a style and not semantics because of the lack of a profile URI. Eventually, as microformats become more popular, the profile URI is used to disambiguate random styles with intended semantic values. Thanks for the reply. Someone previously mentioned to me on this list that Profile URIs were a solution. Yet when I asked about them I interpreted the answer that I got back to indicate they allowed a specific microformat to be identified, but not to have two or more to be explicitly disambiguated. Since I apparently misunderstood how Profile URIs work, can you please mark up my example, repeated below [1], to indicate how a Profile URI might be used to disambiguate my example? I would definitely appreciate it. So far this isn't a problem, and to save time and effort we are focusing on the more important things. I do appreciate the need to prioritize; I can really empathize with that. However, please understand that I am working on a project where disambiguation IS a problem (a major problem, actually.) microformats are not squatting on terms. Forgive me if I used a term that came across as distasteful; that was not my intention. Nonetheless microformats do make use of a scare resource, that being the HTML class attribute and a few other attributes. Hence there is an inherent likelihood of name clashes that can render an HTML content author unable to use two conflicting microformats in the same document unless of course Profile URI resolves those ambiguities. I do look forward to your clarification on Profile URIs. -- -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ [1] Looking at ADR, here is an example: div class=adr div class=street-address665 3rd St./div div class=extended-addressSuite 207/div span class=localitySan Francisco/span, span class=regionCA/span span class=postal-code94107/span div class=country-nameU.S.A./div /div Now let's say I want to use something called RegionData where Regions are heirarchical: div class=region-data div class=region street title=child-of-city665 3rd St.; Suite 207/div span class=region city title=child-of-stateSan Francisco/span, span class=region state title=child-of-countryCA/span span class=post-code94107/span div class=region country title=child-of-continentU.S.A./div /div Now, someone needs to use both: div class=region-data vcard div class=region street title=child-of-city div class=street-address665 3rd St./div div class=extended-addressSuite 207/div /div span class=region city locality title=child-of-stateSan Francisco/span, span class=region state region title=child-of-countryCA/span span class=post-code postal-code94107/span div class=region country country-name title=child-of-continentU.S.A./div /div How to disambiguate with Profile URI? (Please make the assumption that the developer of region-data knew nothing of vcard when region-data was published.) ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Regarding Profile URIs and Disambiguation (was Comments from IBM/Lotus rep about Microformats)
On Dec 12, 2006, at 4:52 PM, Mike Schinkel wrote: div class=region-data vcard div class=region street title=child-of-city div class=street-address665 3rd St./div div class=extended-addressSuite 207/div /div span class=region city locality title=child-of-stateSan Francisco/span, span class=region state region title=child-of-countryCA/span span class=post-code postal-code94107/span div class=region country country-name title=child-of-continentU.S.A./div /div How to disambiguate with Profile URI? (Please make the assumption that the developer of region-data knew nothing of vcard when region-data was published.) As I've said before, I don't think this kind of same name, same document, different meaning conflict is solved by profile URIs (because they don't have namespaces). But I also think it's both a rare and a bad practice to use one symbol to communicate two different ideas in a single context. Nonetheless, in the interest of ending this discussion, here's what you can do to solve this problem whenever you encounter it: 1) add profiles for both vcard and region-data, e.g.: head profile=http://www.w3.org/2006/03/hcard http://yourdomain.com/ region-data-profile 2) add prefixes to all your region-data tags when you decide to add the conflicting hCard names, e.g.: span class=my-prefix-region my-prefix-city locality title=child-of-stateSan 3) designate that prefix in a meta tag, e.g.: meta name=profile-prefixes content=* my-prefix- / (where * indicates no prefix for hcard) 4) convince developers of region-data parsers to look for prefixes Note this won't require any changes to hCard. Now you can go crazy with your double entendre markup and this list can move on with developing microformats to solve specific problems. Sound good? Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
