According to the XFN spec, rel="muse" is a link to someone who inspires
you, and is listed as being a "romantic" relationship. I was wondering
if it is always implied as a romantic relationship, since one could
certainly find someone else inspiring without being romantically
involved/interested.
I did a cursory search for anyone/anything that covered this, but
couldn't find anything more specific. Does anyone have any input on
this? Thanks for your help!
Jason Garber
ja...@sixtwothree.org
_______________________________________________
microformats-discuss mailing list
microforma...@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss
> Hi everyone, I'm pretty new to the mailing list, so apologies if this
> has already been covered.
Not that I've seen, so I guess ditto ;)
> According to the XFN spec, rel="muse" is a link to someone who inspires
> you, and is listed as being a "romantic" relationship. I was wondering
> if it is always implied as a romantic relationship, since one could
> certainly find someone else inspiring without being romantically
> involved/interested.
I tend to agree; certainly a quick dictionary check[1] does not say
anything about the relationship being romantic in the same sense as
other XFN classifications.
Probably the neatest definition is "the goddess or the power regarded
as inspiring a poet, artist, thinker, or the like". The defining
aspect of the relationship is inspiration.
I'm not really very well versed in classical mythology (thanks "modern
history only" high school); but despite the often-romantic
connotations of a relationship between goddess and mortal I think the
muse relationship still does not *require* a romantic link. Those with
more knowledge in the area can correct me if I'm wrong :)
All that said, the actual definition at http://www.gmpg.org/xfn/11
still works: "Someone who brings you inspiration." So, it's really
just that it's a bit misleading to include it in the "romantic"
category.
cheers,
Ben
[1] http://dictionary.reference.com/browse/muse
--
--- <http://www.200ok.com.au/>
--- The future has arrived; it's just not
--- evenly distributed. - William Gibson
Hey Jason!
I actually discussed this with Tantek offlist a while ago, just in
passing, as I was curious about this also. I think the decision made
(by examining uses in the wild) was that muse shouldn't be purely
romantic, as yes - many people mean it in a platonic way. I think
it's something that the XFN documentation could do with clarifying.
Having it understood as purely romantic is much too restrictive, imho.
So - use it as you see fit.
Frances
--
Frances Berriman
http://fberriman.com
I wasn't aware that muse has any connection to "romantic" unless by
"romantic" you mean "of Roman influence" in the same way you might use
"hellenic" to mean "Greek influence."
In fact the etymology of "music" comes from "muse": "music is the art
of the Muses". At that time "music" connoted a much larger subset of
"the arts" than our understanding of rhythm, harmony, and melody,
along with the other elements of music that we currently define it to
be. In ancient Greece, "music" could refer to poetry, dance,
recitation, music, instruments, and even certain scientific endeavors
such as math and science. It was frequently set as equal partners
against athletics. Education was often divided along these two broad
lines, eg "educated in music and gymnastics" would encompass much of
what we would consider to be education in elementary school, or
perhaps a liberal arts curriculum.
<http://en.wikipedia.org/wiki/Muse>
On a side note: music was a highly symbolic term to encompass many
abstract concepts, as opposed to concrete/practical activities such as
gymnastics, or concrete techniques to manipulate the world in which we
live. (To the extent that it would also include math and philosophy
to some degree.) What many would currently consider music today would
not have much in common with the music of ancient Greece; heterophony
was the main strategy for organizing voices, along with drone
techniques, and pitch organization would have been so drastically
different (although they, like all known musics, did at least organize
around the octave), that most modern listeners would likely not
recognize it as music.
Suffice to say: "muse" would be apropriate for any categorization of a
relationship characterized by a strong influence transmitted from one
party to another.
Ben
PS I /knew/ that music degree would come in handy somehow!
> On 10/12/06, Jason Garber <ja...@sixtwothree.org> wrote:
>> Hi everyone, I'm pretty new to the mailing list, so apologies if this
>> has already been covered.
>>
>> According to the XFN spec, rel="muse" is a link to someone who inspires
>> you, and is listed as being a "romantic" relationship. I was wondering
>> if it is always implied as a romantic relationship, since one could
>> certainly find someone else inspiring without being romantically
>> involved/interested.
>>
>> I did a cursory search for anyone/anything that covered this, but
>> couldn't find anything more specific. Does anyone have any input on
>> this? Thanks for your help!
>>
>> Jason Garber
>> ja...@sixtwothree.org
>
> Hey Jason!
>
> I actually discussed this with Tantek offlist a while ago, just in
> passing, as I was curious about this also. I think the decision made
> (by examining uses in the wild) was that muse shouldn't be purely
> romantic, as yes - many people mean it in a platonic way. I think
> it's something that the XFN documentation could do with clarifying.
> Having it understood as purely romantic is much too restrictive, imho.
> So - use it as you see fit.
Certainly "muse" was not intended to only be purely romantic in the literal
"romantic relationship" sense (though it is clear how that could easily be
misconstrued), and of course that meaning is included.
The categorization as "romantic" is in a broader sense, similar to
romanticism [1] as in enabling the elevation of:
"the achievements of what it [Romanticism] perceived as misunderstood heroic
individuals and artists that altered society."
or romance the genre [2]
[1] http://en.wikipedia.org/wiki/Romanticism
[2] http://en.wikipedia.org/wiki/Romance_%28genre%29
That the first specific section in [1] is on music only echoes what Ben West
wrote as well.
Is this worthy of an xfn-faq entry?
Tantek
:) So, there you go...it causes riffs in relationships and
misunderstandings. LOL
Tara
--
tara 'miss rogue' hunt
agent provocateur
Citizen Agency (www.citizenagency.com)
blog: www.horsepigcow.com
phone: 415-694-1951
fax: 415-727-5335
Ah, that's interesting, I was just thinking "the historical period
would kind of fit", but even so I feel this is a bit of a stretch!
I'm not so sure muse should be grouped with "crush, date, and
sweetheart." I actually think muse is more apropriate under Identity
than anything else. The Greeks had a play on words that roughly meant
"control the rhymes of a nation, and you can control their laws." The
idea was that music (or "the muses") had an "ethos" that could have a
profound impact on the composition of the person. The people that
inspire us often have a profound impact on how we see ourselves, and
how we identify with others.
Jason Garber, welcome to the list, and thanks for a much appreciated bit of
levity on a weekend afternoon.
On 12/10/06 4:31 PM, "Tara Hunt" <horse...@gmail.com> wrote:
> Interesting anecdote about this...rel="muse" actually caused a bit of
> a tiff between Chris and I about 6 months back, as he had a bunch of
> women marked up as this...since it was under 'romantic', he agreed to
> change them to 'colleague' and 'friend'.
Given the variety / diversity of relationships (romantic and otherwise) and
the broad spectrum of exclusivity/openness boundaries among people, it's
good to clearly communicate about such matters.
Tara, since you brought up the topic, did you ask him to change the
rel="muse" relationships that Chris had for men as well?
This brings up another question in the usage of XFN. The public nature.
XFN has always implicitly been designed and used in purely "public" contexts
- e.g. the set of relationships was very much filtered by what was found
publicly in the wild (before we even had the microformats principles), and
what we thought people would feel comfortable expressing publicly. The
"romantic" relationships certainly engendered the most debate/discussion
among the XFN creators, "crush" and "muse" in particular.
While there are a few sites that have publicly searchable indexes of XFN
relationships, I don't know of any that provide stats on what XFN
relationships are used the most/least (even the Google markup study [1]
doesn't mention XFN values).
For example how many rel="crush" links are there?
> :) So, there you go...it causes riffs in relationships and
> misunderstandings. LOL
I think I have to pass the buck to communication when it comes to
riffs/misunderstandings in relationships. A public admittance to someone
being someone else's muse just seems like open honesty IMHO.
Thanks,
Tantek
[1] http://code.google.com/webstats/index.html
So yes, Tantek, a FAQ entry would certainly be appreciated.
Chris
--
Chris Messina
Citizen Provocateur &
Open Source Ambassador-at-Large
Work: http://citizenagency.com
Blog: http://factoryjoe.com/blog
Cell: 412 225-1051
Skype: factoryjoe
This email is: [ ] bloggable [X] ask first [ ] private
but the world is not "open honesty" ;) it is made of complexity, of
long walks in forest, of double meanings, of opacity, the richness of
our world lies specifically in this. Binary statement of life
destroys the poetry and the social nature of humans.
Do not forget that lies are necessary in a social group (think about
caring for others for example). It is part of the glue as much as
"honesty".
and yes thanks tara and all for other topics. Though Tara has just
breached a private discussion with her husband in public, I hope he
doesn't mind ;)
--
Karl Dubost - http://www.w3.org/People/karl/
W3C Conformance Manager, QA Activity Lead
QA Weblog - http://www.w3.org/QA/
*** Be Strict To Be Cool ***
> Le 11 déc. 2006 à 10:04, Tantek Çelik a écrit :
>>> :) So, there you go...it causes riffs in relationships and
>>> misunderstandings. LOL
>>
>> I think I have to pass the buck to communication when it comes to
>> riffs/misunderstandings in relationships. A public admittance to
>> someone
>> being someone else's muse just seems like open honesty IMHO.
>
> but the world is not "open honesty" ;)
I would differ only slightly from your statement -
the world is not *just* "open honesty"
though it does contain some. as does the Web.
and it is this existing open honesty on the Web (existing real world
publishing behaviors) that microformats seek to represent and communicate.
> it is made of complexity, of
> long walks in forest, of double meanings, of opacity, the richness of
> our world lies specifically in this.
indeed. and this is one of the reasons why microformats do not try to alter
people's publishing behavior in an unnatural way - and ask of them to make
openly honest what is not already so - unlike "a priori" formats efforts
which seek to change behavior as such with metadata etc. that they "wish"
people would simply magically start publishing.
> Binary statement of life
> destroys the poetry and the social nature of humans.
But it is exactly such binary statements in aggregate (digital data formats)
which have done more to communicate and propagate without loss of fidelity
poetry, music, movies etc. in recent history.
> Do not forget that lies are necessary in a social group (think about
> caring for others for example). It is part of the glue as much as
> "honesty".
I tend to question how much are any specific lies necessary as you say, as
rationalizations such as this are the frequent apologies of those who have
not yet chosen to challenge the assumptions given them by the contexts which
appear to make such lies necessary. But that is merely a matter of opinion
and so I choose to simply agree to disagree with you rather than seriously
offer any debate.
However, in science, I'm not sure there is any need, nor any room for, lies.
And science forms the basis of our work here.
Thanks,
Tantek
> And despite my attempts to explain, as you all have, the origins of
> the "romantic" sense of the term, Tara never gave me the benefit of
> the doubt, hence the semantic change. ;)
>
> So yes, Tantek, a FAQ entry would certainly be appreciated.
It is done.
http://microformats.org/wiki/xfn-faq#Why_is_muse_in_the_romantic_category
Thanks,
Anytime! It's good to see everyone responding so quickly and generously
to something that had been bugging me for a few days.
Thanks also for adding this to the wiki, I imagine I'm not the only
person to have wondered about rel="muse".
> And despite my attempts to explain, as you all have, the origins of
> the "romantic" sense of the term, Tara never gave me the benefit of
> the doubt, hence the semantic change. ;)
>
> So yes, Tantek, a FAQ entry would certainly be appreciated.
Have a look at the Albert Brooks movie 'The Muse'
http://www.imdb.com/title/tt0164108/
it explains the concept (and the misunderstandings) rather amusingly,
if you'll excuse the pun.
>Subject: Re: XFN usage stats and Re: [uf-discuss] rel="muse"
>implies romantic relationship?
Did you perhaps forget to change that?
>microformats do not try to alter people's publishing behavior in an
>unnatural way - and ask of them to make openly honest what is not
>already so - unlike "a priori" formats efforts which seek to change
>behavior as such with metadata etc. that they "wish" people would
>simply magically start publishing.
Perhaps you missed this comment:
<http://microformats.org/wiki?title=hresume-feedback&curid=1777&diff=0&oldid=11198&rcid=20574>
in which a poster describes how he rejected hResume because it sought to
change his publishing behaviour.
--
Andy Mabbett
* Say "NO!" to compulsory ID Cards: <http://www.no2id.net/>
* Free Our Data: <http://www.freeourdata.org.uk>
* Are you using Microformats, yet: <http://microformats.org/> ?
>Perhaps you missed this comment:
>
> <http://microformats.org/wiki?title=hresume-feedback&curid=1777&diff=0&oldid=11198&rcid=20574>
>
>in which a poster describes how he rejected hResume because it sought to
>change his publishing behaviour.
To address the poster's concerns, <address> is a block-level element, not inline, and it is suggested but not mandated. Likewise, skills are optional, as are linking them.
At least that's how I read the spec. Anyone see it differently? (I've also added my answers to the wiki page.)
~ Tim
tjameswhite.com/blog
____________________________________________________________________________________
Have a burning question?
Go to www.Answers.yahoo.com and get answers from real people who know.
>>Perhaps you missed this comment:
>>
>> <http://microformats.org/wiki?title=hresume-feedback&curid=1777&diff=0&oldid=11198&rcid=20574>
>>
>>in which a poster describes how he rejected hResume because it sought to
>>change his publishing behaviour.
>skills are optional, as are linking them.
*all* microformats are optional; that's hardy the point.
--
Andy Mabbett
* Say "NO!" to compulsory ID Cards: <http://www.no2id.net/>
* Free Our Data: <http://www.freeourdata.org.uk>
* Are you using Microformats, yet: <http://microformats.org/> ?
OTOH, I could use any of the following if attached to "professional":
Respect, admire, impressed by,awed, revere, worship, idolize, iconize. If
would be nice if there was a way to extend professional respect and
admiration.
-Mike Schinkel
http://www.mikeschinkel.com/blogs/
http://www.welldesignedurls.org/
> To address the poster's concerns, <address> is a block-level element, not
> inline, and it is suggested but not mandated. Likewise, skills are
> optional, as are linking them.
>
> At least that's how I read the spec. Anyone see it differently? (I've also
> added my answers to the wiki page.)
I do read the same. And in fact, not microformats.org suggested <address>, but
the w3c. Microformats is about a vocabulary for some attributes, not about
elements.
>OTOH, I could use any of the following if attached to "professional":
>Respect, admire, impressed by,awed, revere, worship, idolize, iconize.
>If would be nice if there was a way to extend professional respect and
>admiration.
Not to mention: mentor, mentee, trainer, trainee,
--
Andy Mabbett
* Say "NO!" to compulsory ID Cards: <http://www.no2id.net/>
* Free Our Data: <http://www.freeourdata.org.uk>
* Are you using Microformats, yet: <http://microformats.org/> ?
I wonder if idolizing someone is in some way analogous to a VoteLinks
vote-for.
If we start encoding not only hierarchical relations but expressions of
approval/disapproval, you have the possibility to write some extremely
career-limiting XFN expressions.
<a href="..." rel="colleague boss despise"> ... </a>
and
<a href="..." rel="colleague subordinate sweetheart"> ... </a>
are two that might not do you any good in the workplace ...
Angus
>If we start encoding not only hierarchical relations but expressions of
>approval/disapproval, you have the possibility to write some extremely
>career-limiting XFN expressions.
>
> <a href="..." rel="colleague boss despise"> ... </a>
>
>and
>
> <a href="..." rel="colleague subordinate sweetheart"> ... </a>
>
>are two that might not do you any good in the workplace ...
I should think that:
<a href="..." rel="spouse despise"> ... </a>
might cause some trouble, too! ;-)
--
Andy Mabbett
* Say "NO!" to compulsory ID Cards: <http://www.no2id.net/>
* Free Our Data: <http://www.freeourdata.org.uk>
* Are you using Microformats, yet: <http://microformats.org/> ?
It would probably have a reciprocal:
<a href="..." rel="spouse sleeping-on-couch"> ... </a>
;)
--
--- <http://www.200ok.com.au/>
--- The future has arrived; it's just not
--- evenly distributed. - William Gibson
I agree. It's an amusing situation, but possibly a bit personal!
Adding additional attribute values seems a bit like splitting hairs to me.
What exists at the moment is a generalised, but for the most part
adequate list of types that describe in a loose terms (so as not to be
restrictive) just about any relationship a person is likely to have.
There are probably merits to adding a couple more, but I'm not sure
adding every single explicit type of relationship has any extra value.
Infact, adding too many additional terms starts to water down the
effect and would no doubt make creating useful maps of information
from these relationships difficult.
F
--
Frances Berriman
http://fberriman.com
This would seem to contradict that?
http://www.w3.org/TR/html4/struct/global.html#h-7.5.6
I've stayed away from using <address> on some of my pages precisely
because of this, so I'd be delighted to find I'd read it wrong!
-Ciaran McNulty
I would suspect that mentor, trainer would suffice, with then
@rev="mentor" and @rev="trainer" providing the reciprocal
relationships.
This would also help in that parsers could 'trust' @rev relationships
less than @rel (which I believe has been mooted in the vote-for
discussions), because the statement 'this person is my mentor' is
pretty irrefutable but saying 'this person is my mentee' probably
needs a bit of extra vertification.
I can think of a few people I'd like to link to with
@rev="object-of-lust", otherwise ;-)
-Ciaran McNulty
<address> is an element designed to contain contact information. So if you
want to include contact information use <address>. That is indepenent of
using hCard or not. <address> is a html element, specified by the w3c, hCard
is an attribute vocabulary, designed by microformats. You can pretty well use
both together. In fact, microformats is designed in that way: To be used
together with html.
regards
Siegfried
I'm referring to it's inline-ness.
-Ciaran
With a lot of these (I've personally been pondering ‘employee’ and
‘employer’ of late) the reverse is not required as a unique term,
but can instead be put in the rev="" attribute of the link.
——
On SmallCompany.com
<h1>Employees</h1>
<ul>
<li class="vcard"><a class="fn url" href="http://ben-ward.co.uk"
rev="employer">Ben</a></li>
</ul>
Corresponding on Ben-Ward.co.uk:
<p class="vcard"> … <a class="fn org url" href="http://
smallcompany.com" rel="employer">Small Company</a> … </p>
——
I think there're some legs on the idea of XFN Professional additions.
Ben
>On 12/11/06, Tim White <tjame...@yahoo.com> wrote:
>> To address the poster's concerns, <address> is a block-level
>element, not inline,
>
>This would seem to contradict that?
>http://www.w3.org/TR/html4/struct/global.html#h-7.5.6
>
>I've stayed away from using <address> on some of my pages precisely
>because of this, so I'd be delighted to find I'd read it wrong!
>
>-Ciaran McNulty
I believe that the (%inline) refers to what <address> can contain -- inline elements. See same structure for headings:
http://www.w3.org/TR/html4/struct/global.html#h-7.5.5
I'm not the greatest at reading those specs, so if someone else can confirm that, I'd appreciate it.
~ Tim
tjameswhite.com
____________________________________________________________________________________
Have a burning question?
Go to www.Answers.yahoo.com and get answers from real people who know.
_______________________________________________
Aha, that sounds probable (apologies to Siegfried).
The fact it can't contain block level elements still makes it unusable
for my needs though (I can't fit my hCard into entirely inline
elements, so my pages don't validate correctly if I add <address>).
-Ciaran
Actually, it's more severe than just not validating. Nesting block
level elements within ADDRESS triggers error-handling in browsers,
such that the DOM does not reflect your mark-up. Mark-up such as:
> ADDRESS
--> DIV
----> UL
----> P
Will make a DOM of:
> ADDRESS
> DIV
--> UL
--> P
Where DIV is a sibling of ADDRESS, not a child.
This affects parsing, styling and anything you like, another reason
ADDRESS is not required by any microformat.
Ben
But you can still use hCard -- just wrap it in something else (<div id="hcard"></div>). <address> is allowed, not mandated.
And thank you Ben for the DOM clarification. I wasn't aware of that behavior.
~ Tim
____________________________________________________________________________________
Do you Yahoo!?
Everyone is raving about the all-new Yahoo! Mail beta.
http://new.mail.yahoo.com
If you want to take a look at my address info:
http://www.rorkvell.de/impressum
>On 12/12/06, Andy Mabbett <an...@pigsonthewing.org.uk> wrote:
>> Not to mention: mentor, mentee, trainer, trainee,
>
>I would suspect that mentor, trainer would suffice, with then
>@rev="mentor" and @rev="trainer" providing the reciprocal
>relationships.
I thought "rev" was in the process of being deprecated?
--
Andy Mabbett
* Say "NO!" to compulsory ID Cards: <http://www.no2id.net/>
* Free Our Data: <http://www.freeourdata.org.uk>
* Are you using Microformats, yet: <http://microformats.org/> ?
I do hope not; I'm quite a fan of the little blighter. Do you have a
URL for that?
>On 13 Dec 2006, at 18:29, Andy Mabbett wrote:
>> I thought "rev" was in the process of being deprecated?
>>
>
>I do hope not; I'm quite a fan of the little blighter. Do you have a
>URL for that?
No, but it was recently discussed here, IIRC.
--
Andy Mabbett
* Say "NO!" to compulsory ID Cards: <http://www.no2id.net/>
* Free Our Data: <http://www.freeourdata.org.uk>
* Are you using Microformats, yet: <http://microformats.org/> ?
I too like the idea of the rev attribute, but it's potentially a crap
shoot as there's so little behavior for it to be semi-worthless.
The idea of XBN is one we've explored previously as well
(x-business-network). Again, try searching.
Lastly, as Tantek pointed out, we should consider how these links
would help exchange data between two or more parties.
As LinkedIn and XING now support microformats, there a strong case for
figuring out how to export your professional relationships, using
terms that they both support (hint: start your research there!). While
'colleague' and 'co-worker' are a good start, they don't capture
'former-employer', 'client', 'consultant' or much else.
The goal is not to describe all relationship variations, but common
ones that are shared between professional networking/resume sites.
Chris
--
Chris Messina
Citizen Provocateur &
Open Source Ambassador-at-Large
Work: http://citizenagency.com
Blog: http://factoryjoe.com/blog
Cell: 412 225-1051
Skype: factoryjoe
This email is: [ ] bloggable [X] ask first [ ] private
So please let me clarify that when I said:
>OTOH, I could use any of the following if attached to "professional":
>Respect, admire, impressed by,awed, revere, worship, idolize, iconize.
>If would be nice if there was a way to extend professional respect and
>admiration.
I was simply saying that I felt there was a strong need for ONE additional
value to be used in the "professional" relationship category. When I blog I
frequently refer to people to whom I would like to include some form of
professional respect and admiration, but none of the words I thought of were
quite right. This has the effect of my just having no motivation to use XFN.
So in order to start the discussion about which ONE term to add, I listed
all the ones of similar meaning I could think of in hopes to have people say
"I think 'xxxx' would be best."
And at the risk of rehashing, I'll try to state clearly why I don't think
the current list is sufficient. While the people who defined XFN 1.1
intended "muse" to be used for what I find missing, I am completely
uncomfortable denoting someone as my "muse" unless a.) they are of the
opposite sex, b.) she is a celebrity of sorts, c.) and I don't know her
personally. As the web is mostly a social phenomenon I would contend that
although the use of muse makes perfect dictionary sense, the common use
"muse", especially when paired with "romantic" has implications I personally
would not want anyone to infer if I linked to Steve Jobs, Bill Gates, or
Linus Torvalds. Call me uptight, but I'm sure I'm not the only one.
That said, I would like to propose that we add to XFN "respect" in the
professional category, or some other similar term which the community
decides is more appropriate, and increment the version to 1.2.
--
>While
>'colleague' and 'co-worker' are a good start, they don't capture
>'former-employer', 'client', 'consultant' or much else.
>
>The goal is not to describe all relationship variations, but common
>ones that are shared between professional networking/resume sites.
Perhaps the aim should be to allow for all relationship variations,
albeit at a low level of granularity|? For instance, "worked-with"
(using past tense) or some such would cover all three of your examples,
until something more specific might come along.
--
Andy Mabbett
* Say "NO!" to compulsory ID Cards: <http://www.no2id.net/>
* Free Our Data: <http://www.freeourdata.org.uk>
* Are you using Microformats, yet: <http://microformats.org/> ?
<a rel="custom:xxxx" href="...">John Smith</a>
Where "xxxx" is of course the person's one identifier. Basically this would
allow people to create a folksonomy. It could even require one of the other
predefined tags to ensure that aggregators can still get a rough idea.
-Mike
>I would like to propose that we add to XFN "respect" in the
>professional category, or some other similar term which the community
>decides is more appropriate, and increment the version to 1.2.
I'm curious in the absence of "rev", what would be the reverse
relationship of "respect"?
--
Andy Mabbett
* Say "NO!" to compulsory ID Cards: <http://www.no2id.net/>
* Free Our Data: <http://www.freeourdata.org.uk>
* Are you using Microformats, yet: <http://microformats.org/> ?
> In message <023d01c71efc$2292daf0$0702...@Guides.local>, Mike Schinkel
> <mikesc...@gmail.com> writes
>
>>I would like to propose that we add to XFN "respect" in the
>>professional category, or some other similar term which the community
>>decides is more appropriate, and increment the version to 1.2.
>
> I'm curious in the absence of "rev", what would be the reverse
> relationship of "respect"?
basking?
--
Nic Ferrier
http://www.tapsellferrier.co.uk for all your tapsell ferrier needs
rel="diss"
> Andy Mabbett wrote:
>> In message <023d01c71efc$2292daf0$0702...@Guides.local>, Mike Schinkel
>> <mikesc...@gmail.com> writes
>>
>>
>>> I would like to propose that we add to XFN "respect" in the
>>> professional category, or some other similar term which the community
>>> decides is more appropriate, and increment the version to 1.2.
>>>
>>
>> I'm curious in the absence of "rev", what would be the reverse
>> relationship of "respect"?
>>
>>
>
> rel="diss"
No, no. The reverse relationship would be pointing from someone who
was the object of respect to someone who performed the act of
respecting.
Hence my suggestion of:
basking
--
Nic Ferrier
http://www.tapsellferrier.co.uk for all your tapsell ferrier needs
>> I'm curious in the absence of "rev", what would be the reverse
>> relationship of "respect"?
>
>rel="diss"
Ah, but that's the opposite, not the reverse.
--
Andy Mabbett
* Say "NO!" to compulsory ID Cards: <http://www.no2id.net/>
* Free Our Data: <http://www.freeourdata.org.uk>
* Are you using Microformats, yet: <http://microformats.org/> ?
> On 13 Dec 2006, at 18:29, Andy Mabbett wrote:
>> I thought "rev" was in the process of being deprecated?
>>
>
> I do hope not; I'm quite a fan of the little blighter. Do you have
> a URL for that?
Currently it's not in HTML5. To be conservative, I don't think we
should build on any features that won't be in HTML5 (not that we
can't change the course of the WHAT-WG).
-ryan
--
Ryan King
ry...@technorati.com
At least that's something new in my html knowledge, ta.
Rob
You don't need the "custom:" prefix. Anyone can define his/her own
relationships. BTW, there are more relationships than between persons. Think
of rel="prev", rel="next", rel="contents", ...
So if you need your own relations for whatever, simply use them. It's just it
is no microformat.
regards
Siegfried
You are making an invalid assumption which is that I'm concerned about my
markup. No, I'm not. I've concerned about the need for a standard to be
created so that a body of knowledge and tools can be developed around that
body of knowledge, and people will evangelize and a large number of people
will implement.
But that said, it's now clear to me that the microformat brand is not going
to address my concern. No need to discuss any more; it's a dead issue.
--
-Mike Schinkel
http://www.mikeschinkel.com/blogs/
http://www.welldesignedurls.org/
That made me laugh! :)
--
-Mike Schinkel
http://www.mikeschinkel.com/blogs/
http://www.welldesignedurls.org/
> You are making an invalid assumption which is that I'm concerned about my
> markup. No, I'm not. I've concerned about the need for a standard to be
> created so that a body of knowledge and tools can be developed around that
> body of knowledge, and people will evangelize and a large number of people
> will implement.
>
> But that said, it's now clear to me that the microformat brand is not going
> to address my concern. No need to discuss any more; it's a dead issue.
Are you sure? In any democracy a standard is a matter of adoption. And
microformats do have the potential to be widely adopted. Although not for the
majority of pages (at least not within the next ten years). But that's not a
matter of microformats. It is simply that the majority of pages do not care
for semantic markup at all, so why should they care for microformats? In an
old-style page, marked up 100% vo visual effect, microformats is not even
thought of. Nevertheless, and although microformats aren't perfect, it is
still worth the efford.
Thanks for the comment, but I wasn't able to figure out what point you were
trying to make.
Were you saying that Microformats will develop to be a standard? If that
was your point, I don't debate it; I expect it. But w/o disambiguation and a
way to scale of the process, I think it will create a mess.
Or are you saying that there won't be a mess because you don't think many
pages will use Microformats?
Again, I'm rather confused on your point.
--
-Mike Schinkel
http://www.mikeschinkel.com/blogs/
http://www.welldesignedurls.org/
_______________________________________________
> Thanks for the comment, but I wasn't able to figure out what point you were
> trying to make.
>
> Were you saying that Microformats will develop to be a standard? If that
> was your point, I don't debate it; I expect it. But w/o disambiguation and
> a way to scale of the process, I think it will create a mess.
Right. But some degree of mess is acceptable. Better than some system
developed by some elite, which my be perfect for that elite but useless or
not understood by the majority.
So then to be precise: No, microformats will never be a _standard_, there is
no ISO norm about that. But it will become some kind of "industry standard"
through relatively wide adoption, but that will always be a living thing. And
living things always include some degree of mess (or say: some degree of
chaos). That's acceptable.
>
> Or are you saying that there won't be a mess because you don't think many
> pages will use Microformats?
LOL No, contrary: There will be much mess out in the wild because most pages
do not even use semantic markup at all :)
But that's not a problem of microformats.