Re: [uf-new] Re: Namespace anti-pattern and hAudio TITLE (was: hAudio FN or Title)
On Sun, 2008-02-03 at 22:34 -0800, Tantek =?ISO-8859-1?B?xw==?=elik wrote: 1) it's already used to mean job title in the context of microformats. 2) the concept that it is being proposed to represent is the *name* of an audio item. fn already means the name of an item. we should not introduce a new term to mean the same thing as an existing term. fn in vcard rfc 2426[1] [1] http://www.ietf.org/rfc/rfc2426.txt inherits its semantics from X.520[2] (2001) “commonName.” attribute [2] http://www.itu.int/ITU-T/asn1/database/itu-t/x/x520/2001/SelectedAttributeTypes.html [3] [...The Common Name attribute type specifies an identifier of an object. A Common Name is not a directory name; it is a (possibly ambiguous)...] http://sec.cs.kent.ac.uk/x500book/Chapter.3/Chapter3b.htm It may be more desirable to use cn meaning common-name instead of fn the semantics are more precise and we are not confusing anyone with using fn Thanks Martin McEvoy ___ 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)
On Mon, 2008-02-04 at 10:47 +, Ottevanger, Jeremy wrote: Hi. Coming out of lurk mode, I must say that I'm in complete agreement with Andy. Thanks to Jim, Is GRDDL not a solution to this whole dc question? W3C Completes Bridge Between HTML/Microformats and Semantic Web http://www.w3.org/2007/07/grddl-pressrelease Thanks Martin McEvoy ___ 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] Dublin Core (was: hAudio FN or Title)
On Mon, February 4, 2008 11:59, Brian Suda wrote: the process also states: There must be a problem to be solved (i.e. a real world use case). No problem, no microformat. The problem has already been stated. Jumping straight to making a generic OBJECT DC format is not the best approach. It is the best - the only - approach for solving the stated problem. 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 the issue can not be solved with existing microformats, then there are a few options. [...] 4) use something else, like RDFa, eRDF, GRDDL or others. ...or DC. That's what we're discussing. Given the negative, almost hostile, response to the idea here, I wonder if it might be better discussed in a DC forum? -- Andy Mabbett ** via webmail ** ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [no sig]RE: [uf-new] Dublin Core (was: hAudio FN or Title)
On Mon, 2008-02-04 at 16:29 +, Ottevanger, Jeremy wrote: why on earth should there NOT be a generic microformat out there to capture outline information about all sorts of things that fall through the cracks left by other I think there is a thing microformat item http://microformats.org/wiki/item It may be an idea to try and expand this? see if it fits? Thanks Martin McEvoy ___ 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)
On Feb 4, 2008 10:38 AM, Manu Sporny [EMAIL PROTECTED] wrote: Microformats use emulated namespaces[3], for proof, we need only look to hAtom[5]: * entry-title * entry-content * entry-summary In this example, entry is an emulated namespace. This community has been mis-using the word namespace for several years now, and it's causing too many problems for those that are attempting to understand why we allow entry-title, but don't allow namespaces. No, it just looks like it uses an emulates namespace - please see the hAtom discussions from two years ago if you're interested in the gory details. Essentially, the definition of those three items _is so specific to the problem domain_ that we invented names specifically for that. e.g. entry-title isn't any old title, it's specifically the Atom concept of a title. You could imagine a blog post semantically marked up where a fn is around the entry-title with some more information (David Janes says...) Regards, etc... -- David Janes Founder, BlogMatrix http://www.blogmatrix.com http://www.onaswarm.com http://www.onamine.com ___ 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)
David Janes wrote: On Feb 4, 2008 10:38 AM, Manu Sporny [EMAIL PROTECTED] wrote: Microformats use emulated namespaces[3], for proof, we need only look to hAtom[5]: * entry-title * entry-content * entry-summary In this example, entry is an emulated namespace. This community has been mis-using the word namespace for several years now, and it's causing too many problems for those that are attempting to understand why we allow entry-title, but don't allow namespaces. No, it just looks like it uses an emulates namespace There's no such thing as looking like you use an emulated namespace... just like there is no such thing as looking like you use a context. You either do or you don't. :) If you can find an example of looking like you're using an emulated namespace in any published linguistics, computer science, or programming/language theory literature then please post that as I am unaware of the concept. Here are more examples of Microformats using emulated namespaces: country-name (hCard) organization-name (hCard) organization-unit (hCard) please see the hAtom discussions from two years ago if you're interested in the gory details. Got a link? I'd like to know how the thought process went. Essentially, the definition of those three items _is so specific to the problem domain_ that we invented names specifically for that. Names were invented that have a common base stem, in the case of hAtom, you used 'entry-'. That's my point. When you use a common base stem, it is an indicator that you are using a form of namespacing - you are creating context for what comes after the base stem. I'm not stating that I think it was a bad decision. I'm stating that we do stuff like that in Microformats while touting this no namespaces! rhetoric, which is confusing to on-lookers. We should be saying: 1. No fully qualified namespaces! 2. Emulated namespaces are strongly discouraged! e.g. entry-title isn't any old title, it's specifically the Atom concept of a title. You could imagine a blog post semantically marked up where a fn is around the entry-title with some more information (David Janes says...) I'm not asking that you rip it out - I'm asking that we be more consistent in how we discuss namespaces. Here's what I think the community is for: 1. No fully qualified namespaces in Microformats. 2. Emulated namespaces in very specific cases, such as hCard and hAtom. 3. Context is used to determine more specific semantic meaning for class names such as FN and TITLE. #3 is what we're specifically talking about right now, but knowing #1 and #2 exist is also important to the discussion. -- manu ___ 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] Dublin Core (was: hAudio FN or Title)
On Mon, 2008-02-04 at 12:58 +, Andy Mabbett wrote: On Mon, February 4, 2008 11:53, Martin McEvoy wrote: On Mon, 2008-02-04 at 10:47 +, Ottevanger, Jeremy wrote: Hi. Coming out of lurk mode, I must say that I'm in complete agreement with Andy. Thanks to Jim, Is GRDDL not a solution to this whole dc question? How do use GRDDL to mark up published content about, say, a play or a sculpture? You would have to build a custom HTML-based Dialect such as ones here: http://esw.w3.org/topic/CustomRdfDialects?highlight=%28CategoryGrddl%29 or try RDFa http://www.w3.org/TR/xhtml-rdfa-primer/ It supports DC metadata and namespaces out of the box If its not possible then come back to the table and say we need dc to be ported to microformats. How many people have tried the alternatives first? Thanks Martin McEvoy ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [no sig]RE: [uf-new] Dublin Core (was: hAudio FN or Title)
There's been information collected about how an item microformat would work, though by no means consider this official, blessed, voted upon, or even official proposed. If anyone is really serious about going down this road, I suggest going back though the mailing list archives, especially around the time hAudio was getting to 0.1. For the record, my idea (now) of hItem would work is: - as the _intersection_ of item attributes, roughly ;-) - as a building block for use in other uFs, following the process I'm still lurking at hAudio discussions to see how this is all working out. Regards, etc... On Feb 4, 2008 11:54 AM, Martin McEvoy [EMAIL PROTECTED] wrote: On Mon, 2008-02-04 at 16:29 +, Ottevanger, Jeremy wrote: why on earth should there NOT be a generic microformat out there to capture outline information about all sorts of things that fall through the cracks left by other I think there is a thing microformat item http://microformats.org/wiki/item It may be an idea to try and expand this? see if it fits? Thanks Martin McEvoy ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new -- David Janes Founder, BlogMatrix http://www.blogmatrix.com http://www.onaswarm.com http://www.onamine.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Re: Namespace anti-pattern and hAudio TITLE (was: hAudio FN or Title)
On Mon, February 4, 2008 10:30, Martin McEvoy wrote: fn in vcard rfc 2426 inherits its semantics from X.520[2] (2001) 'commonName.' attribute [...The Common Name attribute type specifies an identifier of an object. A Common Name is not a directory name; it is a (possibly ambiguous)...] http://sec.cs.kent.ac.uk/x500book/Chapter.3/Chapter3b.htm It's worth understanding the meaning and usage of object in that context: http://sec.cs.kent.ac.uk/x500book/Chapter.2/Chapter2.htm#2.2%20OBJECTS%20AND%20ENTRIES (aka http://tinyurl.com/35tpfu) as well as remembering that X500 is a standard for distributed telephone directory databases, not intended for film reviews, employment histories, audio recordings or other use cases. -- Andy Mabbett ** via webmail ** ___ 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)
Tantek Çelik wrote: context is not the same as namespaces. namespaces provide one form of context, but not all contexts are namespaces. in the case of compound microformats, the context that is used is hierarchical containment. Tantek, The issue is not that cut and dry - and the definition of namespace as it relates to Microformats has been twisted to mean something different than it does in the rest of the world. Just so that we're on the same page, everyone should read the standard definition of a namespace[1] and the computer science definition of a namespace[2]. More specifically, the following line is quite clear about the relationship of a namespace[1] and a context and is in direct conflict with your definition: A namespace is also called a context, as the valid meaning of a name can change depending on what namespace applies. If you meant, fully qualified namespaces instead of namespace, then I would agree with you. Context is not the same as a fully qualified namespace is true - however, this is not what you said and I believe this to be a very long-running issue with Microformats: Oversimplification of the namespace problem. What Microformats have an issue with is fully qualified namespaces, which is fair - that concept adds unnecessary complexity as far as the community is concerned. However, that is not what is written up on the wiki in the anti-pattern section on namespaces[4]. The anti-pattern makes it sound like Microformats don't use namespaces at all - which is where all the confusion arises. Microformats use emulated namespaces[3], for proof, we need only look to hAtom[5]: * entry-title * entry-content * entry-summary In this example, entry is an emulated namespace. This community has been mis-using the word namespace for several years now, and it's causing too many problems for those that are attempting to understand why we allow entry-title, but don't allow namespaces. The definition that the Microformats community uses for 'namespace' is flawed and thus the logic becomes flawed - this needs to be fixed. fn *does* have meaning - it means formatted name. No, that is what FN expands to, Formatted Name - the semantic meaning of that is useless without context... without a namespace. I am asserting that very few of us, if any, mark up all the FNs on a page just because we can - names of buildings, cities, people, animals, countries. FN is semantically void without context, without a higher-level Microformat to encapsulate it, without a namespace. Inside an hCard it means the formatted name of either a person, organization, or location (depending on the specifics of the hCard). Inside an hReview item it means the formatted name of an item. So, it *DOES* have different meaning when used in a different context? The object (what you are naming) of the FN changes based on context. So, who is going to make an argument against using TITLE in hAudio? The problem of such use of the term title is twofold. 1) it's already used to mean job title in the context of microformats. Wait, what!? So FN can have two slightly different meanings based on it's context, but TITLE cannot? Why is that? This is exactly the issue: FN's meaning changes slightly based on if it is used in hCard or hReview. TITLE's meaning is locked in to mean job title in all Microformats. There is a glaring lack of consistency here, would anybody like to elaborate on why we're OK with that inconsistency? 2) the concept that it is being proposed to represent is the *name* of an audio item. fn already means the name of an item. we should not introduce a new term to mean the same thing as an existing term. Incorrect, the concept that it is being proposed to represent is the *title* of an audio recording. TITLE is widely used for that purpose in the english language. We should not restrict that word to mean job title, when the English language is fairly clear that TITLE can mean a variety of things[6] based on the context in which it is used. -- manu PS: This is also the reason that I don't spend more time on Microformats - these discussions are very unsatisfying... I've never had to argue about what the meaning of a word such as TITLE actually means at the W3C or any of the other communities that we work with. If we are unsure, we look it up in a dictionary and that is usually the end of the discussion. Microformat's seem to redefine key words like namespace and title as a means to an end, which is wholly frustrating as you need to re-learn parts of the English language in an attempt to contribute to the community. [1]http://en.wikipedia.org/wiki/Namespace [2]http://en.wikipedia.org/wiki/Namespace_%28computer_science%29 [3]http://en.wikipedia.org/wiki/Namespace_%28computer_science%29#Emulating_namespaces [4]http://microformats.org/wiki/namespaces [5]http://microformats.org/wiki/hatom#Entry_Title [6]http://wordnet.princeton.edu/perl/webwn?s=title ___
Re: [uf-new] Namespace anti-pattern and hAudio TITLE (was: hAudio FN or Title)
Scott Reynen wrote: if past decisions don't appear to make sense, please ask for explanations of the thought behind them rather than assuming there was no thought. Good point. So, I have a question: what is the explanation for generalizing the use of formatted name outside of the context of the name of a person? my understanding is that formatted name is useful when there are names that also exist unformatted, i.e. structured format, such as first name, last name, etc. I don't see the use of formatted name as relevant for a track name or an item name, etc. since these typically aren't stored in tokenized form. More on this: http://lebleu.org/blog/2008/02/02/the-meaning-of-vcards-fn/ Even vcard does not reuse fn for the name of an organization. Calling something that most English speaking people I know call track name or song title something else that noone else I know uses outside of microformats (formatted name) is confusing to me and other people on this list. Thanks in advance for the explanation. Guillaume ___ 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)
On Feb 4, 2008 4:05 PM, Brian Suda [EMAIL PROTECTED] wrote: We must be talking past one another with our definitions, it is probably best to start a wiki page and the discussion will not get lose between posts and threads. It will also make it easier for anyone to reference later. Continuing this thread will not be productive for very long. Actually, I've found it quite useful. Manu has brought up several points that I've been concerned about. I've almost chimed in a couple of times but Manu has beaten me to it and I've been reluctant to just post me too :-) Just because one person doesn't find a long and interesting thread productive doesn't mean it isn't productive for others. And, for the record, for most of Manu's comments: Me too. -cks -- Christopher St. John http://artofsystems.blogspot.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Re: Namespace anti-pattern and hAudio TITLE (was: hAudio FN or Title)
In message [EMAIL PROTECTED], Manu Sporny [EMAIL PROTECTED] writes We should be using TITLE for the title of audio recordings. So, who is going to make an argument against using TITLE in hAudio? I'm not, but I do think we should allow for distinction between the titles of tracks, albums, works and similar. This could take the form of: album-title track-title etc. or it could be: foo class=album fooclass=title Meddle /foo /foo foo class=track fooclass=title One of These Days /foo /foo The former, hyphenated, pattern could again borrow the DC qualified model, and be treated by parsers as equivalent to title for some purposes, but distinguished from each other, for other purposes. -- Andy Mabbett ___ 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)
Brian Suda wrote: 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. Then, I assert that your definition of what is and isn't a namespace is out of step with the common definition of a namespace[1] and it is causing confusion to those that are familiar with the common definition of a namespace[2][3][4][5]. 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. Even if there was no attempt to do any sort of emulated namespace, and even if you were attempting to just concatenate space-separated-terms so they could be used in the class attribute, the end result is an emulated namespace. Let me try and put it another way. If we have this (EX1): organization-name organization-unit We have a root, a separator, and a suffix. The root is 'organization', the separator is '-' and the suffixes are 'name' and 'unit'. If we have this (EX2): organization/name organization/unit We have a root, a separator and a suffix. The root is 'organization', the separator is '/' and the suffixes are 'name' and unit'. If we have this (EX3): http://organization.org/name http://organization.org/unit We have a root, a separator and a suffix. The root is http://organization.org;, the separator is '/', and the suffixes are 'name' and 'unit'. So why are we saying that EX1 doesn't have a namespace and EX3 definitely has a namespace (for those that are new to RDF - EX3 is how RDFa declares namespaces)[6]. Regardless of what those that put hCard together meant to do, a side effect of choosing to use '-' to separate elements and using the same root creates an emulated namespace. This same argument applies to hAtom. To create an emulated namespace and then to claim that it isn't one creates an inconsistency in the Microformat community's stance against namespaces. -- manu [1]http://en.wikipedia.org/wiki/Namespace [2]Programming and Problem Solving with C++, By Nell B. Dale, Chip Weems, p.369 [3]History of Programming Languages II, By Thomas J. Bergin , Richard G. Gibson, p.265 [4]Computer-Aided Verification '90: Proceedings of a DIMACS Workshop, June 18-21, 1990. p.571 [5]Handbook of Object Technology By Saba Zamir, p.15 [6]http://www.youtube.com/watch?v=ldl0m-5zLz4 ___ 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)
In message [EMAIL PROTECTED], Brian Suda [EMAIL PROTECTED] writes 008/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. OK, so let's use, say, track title, song title and/ or album title. Oh, they have spaces, so we have two choices... -- Andy Mabbett ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio vS hTrack?
In message [EMAIL PROTECTED], Martin McEvoy [EMAIL PROTECTED] writes what does anyone think of this: http://yahoomediaplayer.wikia.com/wiki/How_to_link do you think people are getting bored of waiting for hAudio... Interesting. +1 for their recognition of track as an important label +1 for their use of 'HTTP content-type'; the hAudio spec should suggest this, at least informatively. -1 for their abuse of tabindex, which is an accessibility tool for in-page navigation if they must use it, they could, perhaps, use 1001 as the first track, 1002 as the second, and so on; but that supposes only one album per page. (I'm no expert on the use of tab index; further advice should be sought.) -- Andy Mabbett ___ 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)
On 2/4/08 1:25 PM, Martin McEvoy [EMAIL PROTECTED] wrote: Hello Manu On Mon, 2008-02-04 at 15:17 -0500, Manu Sporny wrote: Then, I assert that your definition of what is and isn't a namespace is out of step with the common definition of a namespace If namespaces did exist in microformats? it would make it impossible to re-use other objects such as title in other microformats because names in namespaces can only be declared once and only have one contextual meaning? No one actually will admit to the existence of a namespace in microformats but there is lots of evidence suggesting otherwise. either intentional or not, Microformats MAY have created their own namespace of a kind I think? The problem is with this loose use of term namespace or namespace of a kind, not with microformats usage thereof which will result in endless semantic arguments which are not useful. Frankly, this entire thread is one of the reasons we have this mailing list guideline: http://microformats.org/wiki/mailing-lists#Bad_topics_for_discussion Microformats declare a formal profile[1] in their proposals[2] [1] http://gmpg.org/xmdp/ [2] http://microformats.org/wiki/haudio#XMDP_Profile and then do this... head profile=http://gmpg.org/xfn/11; very GRDDL Like head profile=http://www.w3.org/2003/g/data-view; The uses are quite different actually. XMDP uses the profile attribute for defining terms, and GRDDL uses the profile attribute for defining how to transform. Maybe someone can explain to me why declare a profile if there isn't some kind of metadata description at the end? http://gmpg.org/xfn/11 XMDP provides a simple description mostly just to define the terms. So far we've resisted additional metadata similar to DTDs or XML Schema docs. Another big difference is the way XMDP overrides work, linked from [1] cited previously above: http://gmpg.org/xmdp/description Note that if two different profiles define the same term, only the first definition is used. Thus they are not namespaces in any data/programming functional way (like XML namespaces), as such namespaces make such multiple references exist simultaneously and distinctly by keeping them in their own silos. I have added both of these to the XMDP FAQ: http://microformats.org/wiki/xmdp-faq Tantek ___ 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)
No, you're all wrong! :-) Ok, you're all right too. The way the uF antipattern looks to me is the intention of ugly URI-based XML namespaces and prefixes simply aren't necessary. Which, in a lot of senses, is probably on the nail. Manu's point seems reasonable, to the extent that parts of the markup hierarchy (vcard etc) do in effect delimit a namespace, though I'm not sure this applies to the hyphenated terms mentioned - I'd read those as names which happen to have hyphens in them. I would personally have no objection whether e.g. a song title was marked up with title or fn, as long as this was adequately documented, and the definition easily discoverable. Which leads me to something Martin mentioned - if HTML Meta Data profiles are used, the whole question becomes a non-issue. By using a profile URI and putting a description of the terms used in the profile on the Web, it's possible for people (and machines) to easily discover the intended meaning. Forget namespaces. Think of a follow-your-nose chain of information to the information the publisher or consumer might need to communicate. After all, the string title only has a well-known meaning to a minority of the global population. Why isn't it titel or titulo? Cheers, Danny. -- http://dannyayers.com ~ http://blogs.talis.com/nodalities/this_weeks_semantic_web/ ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
namespaces bad topic for uf mailing lists reminder (was Re: [uf-new] Namespace anti-pattern and hAudio TITLE (was: hAudio FN or Title))
On 2/4/08 1:25 PM, Martin McEvoy [EMAIL PROTECTED] wrote: Hello Manu On Mon, 2008-02-04 at 15:17 -0500, Manu Sporny wrote: Then, I assert that your definition of what is and isn't a namespace is out of step with the common definition of a namespace If namespaces did exist in microformats? it would make it impossible to re-use other objects such as title in other microformats because names in namespaces can only be declared once and only have one contextual meaning? No one actually will admit to the existence of a namespace in microformats but there is lots of evidence suggesting otherwise. either intentional or not, Microformats MAY have created their own namespace of a kind I think? The problem is with this loose use of term namespace or namespace of a kind, not with microformats usage thereof which will result in endless semantic arguments which are not useful. and On 2/4/08 1:20 PM, Christopher St John [EMAIL PROTECTED] wrote: On Feb 4, 2008 4:05 PM, Brian Suda [EMAIL PROTECTED] wrote: We must be talking past one another with our definitions, it is probably best to start a wiki page and the discussion will not get lose between posts and threads. It will also make it easier for anyone to reference later. Continuing this thread will not be productive for very long. Actually, I've found it quite useful. Manu has brought up several points that I've been concerned about. I've almost chimed in a couple of times but Manu has beaten me to it and I've been reluctant to just post me too :-) Just because one person doesn't find a long and interesting thread productive doesn't mean it isn't productive for others. That may be true, however, we decided long ago, that this wasn't a good forum for having such discussions about namespaces - there are other forums where you may find more others that find long discussions about namespaces interesting. http://microformats.org/wiki/mailing-lists#bad-topic-namespaces Thanks, Tantek ___ 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)
In message [EMAIL PROTECTED], Danny Ayers [EMAIL PROTECTED] writes I would personally have no objection whether e.g. a song title was marked up with title or fn, as long as this was adequately documented, and the definition easily discoverable. I think we also need to think about the convenience of publishers; not all of whom are very interested in the mechanics of microformats. What will be easiest for them to learn, remember and understand? Which leads me to something Martin mentioned - if HTML Meta Data profiles are used, the whole question becomes a non-issue. By using a profile URI and putting a description of the terms used in the profile on the Web, it's possible for people (and machines) to easily discover the intended meaning. What if the page includes profiles for hAudio *and* hCard? -- Andy Mabbett ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Re: hAudio issue: position
Andy Mabbett wrote: I've been meaning to document them for several weeks, but haven't gotten around to doing so. You'd be the best person to word it in a way that you agree with I agree it would be useful, and will do so if and when I have time; don't let that stop you if you have free time first! That said, I have previously found the placing of issues on with wiki to be pointless exercise, as they are often ignored, or rejected out-of-hand, with no adequate discussion. Can't speak for other initiatives, but it would be a shame to ignore any constructive criticism on issues surrounding hAudio. We didn't ignore input for the pre-draft hAudio, and we shouldn't start ignoring input now, either. What the hell; done. there are six at: http://microformats.org/wiki/haudio-issues Don't say I'm not good to you ;-) Awww... thanks Andy, you shouldn't have =P Looks like we're currently dealing with hAudio Issue #D2[1] -- manu [1]http://microformats.org/wiki/haudio-issues#2008 ___ 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)
Hello Manu On Mon, 2008-02-04 at 15:17 -0500, Manu Sporny wrote: Then, I assert that your definition of what is and isn't a namespace is out of step with the common definition of a namespace If namespaces did exist in microformats? it would make it impossible to re-use other objects such as title in other microformats because names in namespaces can only be declared once and only have one contextual meaning? No one actually will admit to the existence of a namespace in microformats but there is lots of evidence suggesting otherwise. either intentional or not, Microformats MAY have created their own namespace of a kind I think? Microformats declare a formal profile[1] in their proposals[2] [1] http://gmpg.org/xmdp/ [2] http://microformats.org/wiki/haudio#XMDP_Profile and then do this... head profile=http://gmpg.org/xfn/11; very GRDDL Like head profile=http://www.w3.org/2003/g/data-view; Maybe someone can explain to me why declare a profile if their isn't some kind of metadata description at the end? http://gmpg.org/xfn/11 Thanks Martin McEvoy ___ 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)
On Mon, 2008-02-04 at 15:05 -0800, Tantek =?ISO-8859-1?B?xw==?=elik wrote: Note that if two different profiles define the same term, only the first definition is used. Thus they are not namespaces in any data/programming functional way (like XML namespaces), as such namespaces make such multiple references exist simultaneously and distinctly by keeping them in their own silos. Really! that seems bad is it?, it makes little sense to re-use other parts like fn eg: head profile=http://microformats.org/wiki/hcard-profile http://microformats.org/wiki/haudio#XMDP_Profile; unless their context is exact fn in the above case would be bound to a hcard definition not an audio definition which when you think about it means something else...? Thanks Martin McEvoy ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: namespaces bad topic for uf mailing lists reminder (was Re: [uf-new] Namespace anti-pattern and hAudio TITLE (was: hAudio FN or Title))
On Feb 4, 2008 5:08 PM, Tantek Çelik [EMAIL PROTECTED] wrote: On 2/4/08 1:25 PM, Martin McEvoy [EMAIL PROTECTED] wrote: Actually, I've found it quite useful. Manu has brought up several points that I've been concerned about. I've almost chimed in a couple of times but Manu has beaten me to it and I've been reluctant to just post me too :-) Just because one person doesn't find a long and interesting thread productive doesn't mean it isn't productive for others. That may be true, however, we decided long ago, that this wasn't a good forum for having such discussions about namespaces - there are other forums where you may find more others that find long discussions about namespaces interesting. http://microformats.org/wiki/mailing-lists#bad-topic-namespaces (Much of) the discussion isn't about that kind of namespaces. It's about trying to clarify how the word used on the Wiki (in a very specific sense) has a more broadly accepted meaning that differs in important ways. The fact that no namespaces dogma makes little sense to people familiar with the general meaning suggests that clarification is important. Manu's post with references to the various meanings is probably something that should go up on the wiki. It's a productive contribution to the issue and a demonstration that dogmas should occasionally be pulled out from their glass case and given a good shaking. -cks -- Christopher St. John http://artofsystems.blogspot.com ___ 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)
Brian Suda wrote: If we have this (EX2): organization/name organization/unit We have a root, a separator and a suffix. The root is 'organization', the separator is '/' and the suffixes are 'name' and unit'. --- but your argument falls down with your other citation of country-name. This is NOT: country/name Does it? If 'country-name' isn't namespaced, then we could get rid of country and 'name' by itself would have an unambiguous meaning. However, if we were to do that in practice, 'name' wouldn't mean 'country name' anymore... it would be more ambiguous. By being more ambiguous, we're stating that the prefix that we removed, 'country', actually does have semantic meaning. 'country' is a namespace that gives scope to the following 'name' by specifying that we are talking about a 'country name' and not a 'person name'. But even with that argument, let's get rid of country-name - we're still left with: entry-title entry-summary entry-description organization-name organization-unit My argument still stands - we're providing a specific scope to 'title', 'summary' and 'description' - that scope is 'entry'. We are also providing a specific scope to 'name', and 'unit' - that scope is 'organization'. Regardless of what those that put hCard together meant to do, a side effect of choosing to use '-' to separate elements and using the same root creates an emulated namespace. --- this was never the intent of hCard, and i still no do not believe having a hyphen denotes namespaces of any kind. People who hypenate their surnames, jones-smith is NOT a namespace of jones/smith. We're not talking about people who hyphenate their surnames - we are talking about the use of TITLE in hAudio and the inconsistency in the Microformat community's definition of 'namespace'. To create an emulated namespace and then to claim that it isn't one creates an inconsistency in the Microformat community's stance against namespaces. Agreed, and this is why i do not consider this any sort of emulated namespace had it his been CamelCase would you still argue Namespace? Yes! You don't need a separator for namespaces to occur, you just need the root to be the same. getUser() is not namespaced, nor is smith-jones or country-name or e-mail. I agree that smith-jones is not namespaced, it is hyphenated. However, every other one of your examples is a form of scoping/namespacing: getUser() implies that there are other getters on the object - the implied namespace/scope is the set of getter methods for the object/module. country-name is namespaced/scoped - the named scope is 'country'. This differentiates it from 'audio-name', which implies a named scope of 'audio'. If we were to remove 'country' and 'audio' from these two examples, we would be left with 'name' and 'name' - which are indistinguishable from each other. The prefixes define a scope - a scope that is named is called a namespace. We must be talking past one another with our definitions Just to be clear - this isn't /my/ definition - it is the definition that is widely accepted in Computer Science. The definition on the Microformats page is, at best, vague, at worst, inconsistent with the definition that is widely accepted in Computer Science. it is probably best to start a wiki page and the discussion will not get lose between posts and threads. It will also make it easier for anyone to reference later. Sure thing - the page is up: http://microformats.org/wiki/namespaces-inconsistency -- manu ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: namespaces bad topic for uf mailing lists reminder (was Re: [uf-new] Namespace anti-pattern and hAudio TITLE (was: hAudio FN or Title))
Tantek Çelik wrote: No one actually will admit to the existence of a namespace in microformats but there is lots of evidence suggesting otherwise. either intentional or not, Microformats MAY have created their own namespace of a kind I think? The problem is with this loose use of term namespace or namespace of a kind, not with microformats usage thereof which will result in endless semantic arguments which are not useful. Is that why you RESOLVED the issue without consulting the list first? http://microformats.org/wiki?title=namespaces-inconsistency-issuediff=25462oldid=25450 If Andy did something like that, he'd be up for another ban... With all due respect, Tantek - I was attempting to make the definition of namespace that the Microformats community uses far more accurate - to clarify the no namespaces stance that the community has. By shutting down the discussion, you've single-handedly pre-empted that improvement to the wiki. An improvement that would help new comers to this list and Microformats understand what we mean by no namespaces. It was an improvement that the community largely agrees with, but the namespaces page doesn't express[1]. You even agree to this sentiment in the e-mail you quote in the RESOLUTION section[2]. I'm disappointed that this discussion is being pre-emptively shut down... just when it seemed as if we were making progress. -- manu [1]http://microformats.org/wiki/namespaces [2]http://microformats.org/wiki/namespaces-inconsistency-issue#Resolution ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Namespace anti-pattern and hAudio TITLE
Walter Logeman wrote: I am jumping in, new here, new to microformats, looking for a solution to a problem, but more on that later. Welcome to Microformat's, Walter :) This thread has helped me understand a few things, though I would not want to have endless debates about the meta-language used. Just a small pointer - microformats-new is for the design/debate/discussion for new Microformats under development. It's a pretty harsh place to start out learning about Microformats - you can learn a great deal from this list, but it's not meant as an introductory discussion group. You might want to check out microformats-discuss if you wanted to discuss the use of pre-existing Microformats in your website: http://microformats.org/mailman/listinfo/microformats-discuss/ That being said - if you could stomach the discussion about namespaces, you should do fine on this list :) Do I have this right then, within hAudio it would be possible to have title or fn? Well, that is what we're currently debating. The current draft specification for hAudio uses FN, which several of us are contesting as a bad choice. Some of us would like to use TITLE, but previously when we had suggested that, some on this list nixed the idea because TITLE is already used in hCard to mean job title. Since TITLE was defined to mean job title in Microformats, that precludes us from using it for hAudio. We're attempting to change the Microformats definition of TITLE to mean title instead of job title. It sounds like a no-brainer, but we're making sure it doesn't have any other ramifications before doing so. The best thing about this community is that we debate the merits and drawbacks of an idea in an open environment before coming to a conclusion. This helps everybody weigh in on the issues before a decision is made. Some also argue that this open debate is the worst part about this community :) I'd prefer title, it makes more intuitive sense to me. Good to know, thanks Walter - that helps us understand what would be most intuitive to somebody starting out in Microformats. We've been immersed in this stuff long enough that it's hard to see the forest for the trees at times. Would there also be tag name for file name? fn could get confusing ... There isn't a proposal for filename at the moment, other than using the ENCLOSURE class in @rel. Filenames, sizes, bitrates, etc. are outside of the scope of what hAudio is attempting to address (naming audio recordings). What if the page includes profiles for hAudio *and* hCard? I am a total newby, I just looked at my hCard thinking there would be a div class=hCard, but no it is div class=vcard ??? Yes, that certainly is confusing. VCARD was used as the class name for historical reasons - hCard is based on the VCARD format by Netscape: http://www.ietf.org/rfc/rfc2426.txt That is why the name of the class is VCARD instead of hCard. So does every microformat, regardless of the context need to be unique? It depends on what you mean by unique. If you mean, do the class names have to be unique, then yes, they do have to be unique. I am hoping to mix hCard, xfn and hArt if it were there, I saw a start on it? I will start some new threads. Yes, you can mix hCard and xfn on the same page, and even in the same paragraph. -- manu ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
(edited) Re: XMDP/GRDDL was Re: [uf-new] Namespace anti-pattern and hAudio TITLE (was: hAudio FN or Title)
Apologies, this email sent from my outbox as I was editing it and unintentionally duplicated some text sent in another email. It should have had its subject updated and been edited down to: On 2/4/08 3:05 PM, Tantek Çelik [EMAIL PROTECTED] wrote: Microformats declare a formal profile[1] in their proposals[2] [1] http://gmpg.org/xmdp/ [2] http://microformats.org/wiki/haudio#XMDP_Profile and then do this... head profile=http://gmpg.org/xfn/11; very GRDDL Like head profile=http://www.w3.org/2003/g/data-view; The uses are quite different actually. XMDP uses the profile attribute for defining terms, and GRDDL uses the profile attribute for defining how to transform. Maybe someone can explain to me why declare a profile if there isn't some kind of metadata description at the end? http://gmpg.org/xfn/11 XMDP provides a simple description mostly just to define the terms. So far we've resisted additional metadata similar to DTDs or XML Schema docs. Another big difference is the way XMDP overrides work, linked from [1] cited previously above: http://gmpg.org/xmdp/description Note that if two different profiles define the same term, only the first definition is used. Thus they are not namespaces in any data/programming functional way (like XML namespaces), as such namespaces make such multiple references exist simultaneously and distinctly by keeping them in their own silos. I have added both of these to the XMDP FAQ: http://microformats.org/wiki/xmdp-faq Tantek ___ 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
