Re: [uf-new] Re: Namespace anti-pattern and hAudio TITLE
In the Proposal put forward by Manu [1] would the distinction you propose Andy be allowed? possible? encouraged? needed? Walter - Andy Mabbett wrote: 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. [1]http://microformats.org/discuss/mail/microformats-new/2008-February/001468.html ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
[uf-new] Re: Namespace anti-pattern and hAudio TITLE
Manu wrote: Does it? If 'country-name' isn't namespaced, then we could get rid of country and 'name' by itself would have an unambiguous meaning. I think you're missing the distinction between 'namespace' and 'context', like Tantek suggested. Basically, you're stating the reductio for your own position -- you're basically saying that all adjectives are namespaces, and that's clearly incorrect. 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. *Of course* 'country' has semantic meaning. It's an adjective that provides context for 'name'. But context does not a namespace make... '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'. No, country does that because of its adjective-ness, not its namespace-ness. Ted -- Edward O'Connor [EMAIL PROTECTED] Ense petit placidam sub libertate quietem. ___ 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
Edward O'Connor wrote: Manu wrote: Does it? If 'country-name' isn't namespaced, then we could get rid of country and 'name' by itself would have an unambiguous meaning. I think you're missing the distinction between 'namespace' and 'context', like Tantek suggested. I assure you, I am not missing the distinction. I have quoted the definitions in the literature to back up what I'm asserting. Please read the namespace-inconsistency-issue page before making statements to that effect (I have updated it to reflect your comments): http://microformats.org/wiki/namespaces-inconsistency-issue All definitions are clearly cited - note that nobody else is citing definitions to what namespace means in this discussion. If you would like to cite some examples that support your viewpoint, that would be great. :) Basically, you're stating the reductio for your own position -- you're basically saying that all adjectives are namespaces, and that's clearly incorrect. This is what I'm saying: context/scope provide an enclosing structure that provides semantic meaning to the elements that it encloses.[1] When you name a context/scope, it is called a namespace.[2] *Of course* 'country' has semantic meaning. It's an adjective that provides context for 'name'. But context does not a namespace make... No, but a named context is a namespace. It's right there in your first semester programming languages text book (which I've cited several of them on the namespaces-inconsistency-issue page). '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'. No, country does that because of its adjective-ness, not its namespace-ness. In this case, they're the same thing. In general, I would go as far to say that adjectives and adverbs, by definition, are namespaces because they provide finer context for the subject that they describe AND they are named. A named context is... a namespace. -- manu [1]http://wordnet.princeton.edu/perl/webwn?s=context [2]http://en.wikipedia.org/wiki/Scope_%28programming%29 ___ 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 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] 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] 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] Re: Namespace anti-pattern and hAudio TITLE (was: hAudio FN or Title)
On Sun, 2008-02-03 at 14:31 -0500, Manu Sporny wrote: FN doesn't mean anything useful until it is wrapped by a Microformat - hCard, or hAudio, for example. This means that the wrapping Microformat brings context into the equation. The same as if we use title outside of hcard IT doesn't mean anything useful, wrap it in haudio the function of the object title would then become an audio title, nothing at all to do with hcard? Thanks Martin McEvoy ___ 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 2/3/08 11:31 AM, Manu Sporny [EMAIL PROTECTED] wrote: Martin McEvoy wrote: I think he means Context-Aware I And to answer Manu's no I don't think its necessary, Microformats already ARE context aware? Yes! This is my point exactly. If Microformats ARE context aware, then there is the concept of namespaces in Microformats. Namespaces are NOT an anti-pattern afterall. Manu, 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. fn *does* have meaning - it means formatted name. 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, 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. 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. Tantek ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
