Timestamps are in UTC.
tantek is Tantek <http://tantek.com> and works on Technorati and develops microformats <http://microformats.org>
[[events/2006-09-13-future-of-web-apps-microformats]] http://microformats.org/wiki?title=events/2006-09-13-future-of-web-apps-microformats&diff=0&oldid=9463 * Tantek * (+83) added link to Microformats Practices podcast
[[podcasts]] http://microformats.org/wiki?title=podcasts&diff=0&oldid=9464 * Tantek * (+233) added future of web apps microformats practices podcast.
[[podcasts]] M http://microformats.org/wiki?title=podcasts&diff=0&oldid=9465 * Tantek * (+17)
[[podcasts]] M http://microformats.org/wiki?title=podcasts&diff=0&oldid=9466 * Tantek * (+0)
[[events/2006-09-13-future-of-web-apps-microformats]] M http://microformats.org/wiki?title=events/2006-09-13-future-of-web-apps-microformats&diff=0&oldid=9467 * Tantek * (+55) added link to fowa wiki
morning
bengee is Benjamin Nowack (http://bnode.org/)
trovster is a web developer from the UK who writes on http://www.trovster.com and helps with www.multipack.co.uk
danja is Danny Ayers, http://dannyayers.com
drewinthehead is the author of hKit and a developer for Yahoo! Europe
hi, can someone pleas explain me why hCard creator uses a <div> as a toplevel element and not an <address> element?
Because you're supposed to only use <address> for contact details for the author of the page. However, hCards can represent other people.. (?)
hCards don't strictly have to show an address, either?
I don't see a name and phone number as an adress, but it's a plausible use for a h/vCard
<address> for contact details ... which can be a phone number... but I don't like that argument
Hmm.. interesting.
I'd always assumed the <address> field was for addresses, rather than for any contact information.
heh.
Indeed.
but it's ONLY for contact details for that PAGE/Site
Ah!
Yes.
Which, imo, sucks
It does, actually.
Does hCard require you to use a div>
No...
All microformats are just classes (apart from datetime-pattern)
Then the question is moot, I guess :)
Indeed.
<p class="vcard">My name is <a href="http://www.trovster.com" class="fn url">trevor morris</a> and I work for a design agency as a <span class="role">web developer</span> called <a href="#" class="org url">Creation</a>.</p>
[[species-examples]] http://microformats.org/wiki?title=species-examples&diff=0&oldid=9468 * AndyMabbett * (+147) Breaking news - tunning new orchids from Asia's rainforest
[[species-examples]] http://microformats.org/wiki?title=species-examples&diff=0&oldid=9469 * AndyMabbett * (+10) Breaking news - Stunning new orchids from Asia's rainforest
drewinthehead is the author of hKit and a developer for Yahoo! Europe
csarven is Sarven Capadisli and can be found online at http://www.csarven.ca
danja is Danny Ayers, http://dannyayers.com
drewinthehead is the author of hKit and a developer for Yahoo! Europe
briansuda is brian suda of http://suda.co.uk and is at (-0000 GMT) and is author of "Using Microformats" for O'Reilly [http://www.oreilly.com/catalog/microformats/]
remi is Remi Prevost, a web developper (yeah, that's how we spell "developer" in french) from Quebec and blogs about web stuff at <http://remiprevost.com/>
sreynen is Scott Reynen, who makes things at makedatamakesense.com
anyone around have any experience with jQuery? i am using javascript to extract Microformatted data into LiveClipBoard and hit a small snag
#jquery ;) but I can try (only just started)
no worries, they support SOME XSLT, and SOME CSS rules
somehow i need some of each and the functions needed aren't supported
[[hcalendar]] http://microformats.org/wiki?title=hcalendar&diff=0&oldid=9470 * AndyMabbett * (-41) rm repeated text; too confusing for newbies
[[hcalendar]] http://microformats.org/wiki?title=hcalendar&diff=0&oldid=9471 * AndyMabbett * (+272) Introduction - start to list fields
[[hcalendar]] M http://microformats.org/wiki?title=hcalendar&diff=0&oldid=9472 * AndyMabbett * (+6) Introduction - make list
[[hcalendar]] M http://microformats.org/wiki?title=hcalendar&diff=0&oldid=9473 * AndyMabbett * (+42) Introduction - location
gsnedders is a 14 year old idiot from Scotland and pretends to have a website at http://geoffers.uni.cc/
[[hcard]] http://microformats.org/wiki?title=hcard&diff=0&oldid=9474 * AndyMabbett * (-45) move cedits etc to end; make semantic boilerplate a link, tweak
[[hcalendar]] M http://microformats.org/wiki?title=hcalendar&diff=0&oldid=9475 * AndyMabbett * (-3) Move credits, etc,. to end
BenWard is Ben Ward of http://ben-ward.co.uk (+0000/+0100 GMT)
hmm... not sure what i think about moving Credits/Copyright/etc to the bottom of the specs pages? anyone else have any thoughts?
[[hcalendar]] M http://microformats.org/wiki?title=hcalendar&diff=0&oldid=9476 * AndyMabbett * (+7) reorder & rename
cgriego is Chris Griego (-06:00) and a front-end architect with rd2inc.com
[[to-do]] http://microformats.org/wiki?title=to-do&diff=0&oldid=9477 * Tantek * (+994) added update specification section organization to-do item
mlinksva is Mike Linksvayer and from Creative Commons
bewest is curious about emerging standards and works for Alexa.com
http://www.sabi.co.uk/Notes/anno06-3rd.html#060809
briansuda, I too am not sure what i think about moving Credits/Copyright/etc to the bottom of the specs pages, except that doing such massive drastic edits to established pages without at least bringing it up with the *editor* or the mailing list is perhaps a bit rude.
plus, there are some important things, like the copyright statement to the bottom middle. - if someone contributes they should be aware of what their contribution means
Ryan King and I had been in the process of trying to improve the intro/header section of specs, and we decided to use hResume as a first place to start (since it was new and could afford that).
briansuda, correct
plus, (and you might have more experience) but most specs i have seen layout the Editor Author up-front
so I've documented my current thoughts on this here: http://microformats.org/wiki/to-do#update_specification_section_organization
that's right brian. much of the order of information in the specs have been modeled after W3C specs
re-use rather than re-invent that is. even specification structure.
bewest - that sabi.co.uk comment is raising no new arguments.
i also understand the yearning to "get right into" the data, so some refactoring is welcomed, but i'm not sure a whole move
but does contain some new misconceptions
tantek: his alternative suggestion: http://www.sabi.co.uk/Notes/anno06-3rd.html#060810b
e.g. this statement "Using the class attribute to indicate finer classes of semantics is a bit of an abuse, as they are meant to indicate finer classes of rendering"
nowhere in HTML specs does it say class attribute is for finer classes or rendering.
right
the argument that usually goes hand in hand with that one is that class attribute is CDATA, not PCDATA and as such should not contain semantic information
huh?
what does the format of the attribute have to do with the semantics?
that makes no sense.
I hear it a lot
briansuda, refactoring can be a good thing to do, but not singlehandedly by someone who hasn't done so before without any discussion on the list or in IRC
that's the part that was inappropriate
glad to know it wasn't just me then...
yeah, I have to compose an email to the list and revert some edits so we can discuss improvements first before making them
bewest, I think XML is having some serious problems in the market of the "public Web"
after seeing a presentation on JSON by Doug Crawford, I'm convinced JSON is much better for data exchange (from APIs) than XML
Crockford?
maybe - sorry, I may be misremembering - the guy who came up with JSON
JSON /is/ much better if the consumer is javascript
not necessary
YAML consumers and consume JSON as well
erm, JSON feels better than DOM to me
so maybe JSON > DOM
there are libraries for consuming/producing JSON in over a dozen languages
right
I retract
and it is *much* more readable than XML IMHO
yeah, Doug Crockford
his site is good for JS inspiration
and experience with semantic HTML + microformats has shown that it's much better of publishing human readable documents than XML with new vocabularies etc.
so XML, which supposed to be the end-all be-all for both data-exchange and document-exchange is now under fire from both sides by better solutions
JSON and microformats
I'm starting to wonder if XML actually has a practical future on the public Web
hmmm
yeah
then here's a challenge for you:
it was one of those, oh crap, moments
when I had that realization
remember, I'm not anti-XML
convert technorati's web API to do xhtml :-)
or rather, JSON
erm, that too
there was a thread started on the list about how to do data with xhtml
Technorati's website already publishes microformats, and we're adding more (nearly) every day
I think hAtom has a lot of potential for that
it didn't really get picked up although I was very interested in it
perhaps
you know, I think my observation is such that the main obstacle people are having is understanding that it is the visible nature of data that maintains its integrity and viability
and that data without high integrity isn't worth a whole lot
precisely!
this is stemming from your observations about links being public meta data
they think a pure model is more important than high integrity
which is absolutely false
and the *opposite* is true
the reason the "web is working" is because of the bits of data that are viewable
that's probably the biggest cultural/philosophical difference between the microformats and the XML/RDF world
it /is/ a little unintuitive... because it's a usability/social/human problem, not an engineering problem per se
*right*
unintuitive for people who ignore usability/social/human problems
meeting time :-)
afk
Frederic is Frederic de Villamil from France and the guy formerly known as neuro` and blogs at http://t37.net
re
rohit is in NYC these days
[[hcard]] http://microformats.org/wiki?title=hcard&diff=0&oldid=9478 * Tantek * (-15) reverted page to pre-reorg state but with new example in the wild that was added
kingryan is ryan king
[[hcalendar]] http://microformats.org/wiki?title=hcalendar&diff=0&oldid=9479 * Tantek * (-283) revereted to pre-org version
does hcard use relations like `distance` ?
how is distance a relation?
err i meant a relative concept
[[hcalendar]] http://microformats.org/wiki?title=hcalendar&diff=0&oldid=9480 * Tantek * (+168) added link to hcalendar-authoring to top of page to match hCard to help direct authors find it more quickly
csarven - still not understanding what that has to do with hCard, which represents a person or organization.
for a store locator search (based on a postal code), distance is given as one of the results, however the company's (organization) location is relative to the postalcode
ah that's a specific application
im wondering if hcard would cover dynamic/relative assignments or is it only for static information?
ok
that seems like a different question
:)
the "distance" is not an aspect of the organization
or the person
so it doesn't belong in hCard
hCards however do tend to be *dynamic* in that people update them when their contact info changes etc.
alright, thank you.
i understand.. what i meant by static is that the information is not calculated in one way or another -- not sure if this makes it any more clearer
[[mailing-lists]] http://microformats.org/wiki?title=mailing-lists&diff=0&oldid=9481 * Tantek * (+820) added mailing list proposal
[[mailing-lists]] M http://microformats.org/wiki?title=mailing-lists&diff=0&oldid=9482 * Tantek * (-4) rename header
csarven - if the information is "calculated" as you say, I'm not sure it belongs in a "format", other than as the formula that performed the calculation
otherwise you lose information
is it okay to add redirects to the wiki from non-existent pages to likely intended destinations?
Scott - that seems to make sense
any particular example?
well, somewhere there's a list of all class names in use, which i can never find
and the search is useless because "class" is on every page
[[mailing-lists]] M http://microformats.org/wiki?title=mailing-lists&diff=0&oldid=9483 * Tantek * (+69)
so i'd like some of my failed guesses to redirect me
is it not on class-names ?
that's blank
proves your point ;)
http://microformats.org/wiki/class-names
that was one of my guesses
so now i just need to figure out where it actually is, and redirect that
[[mailing-lists]] M http://microformats.org/wiki?title=mailing-lists&diff=0&oldid=9484 * Tantek * (+19) noted Chris Messina suggested microformats-suggest
home page search usually works for that Scott
http://microformats.org/wiki/existing-classes
Phae is Frances Berriman of http://www.fberriman.com/
you mean a Google site: search?
no just "find" in the browser
evening
hi Phae
is that how you found that?
i'm not seeing it on the home page
i just looked for "class" on the home page
wiki home page
oh - i see now
You guys seen this --> http://www.baekdal.com/future/web2rss-intro/
?
but yeah, not entirely easy to discover
well, that solves my personal problem, but i suspect redirects would help some others
oh i agree
go for it
blueNine - scrapers that generate RSS have been around for *many* years
i don't suppose it would be easy to get logs of most commonly accesses blank pages on the wiki?
since before people started publishing RSS feeds, people wanted ways to synthesize them automatically for sites that didn't have them
s/accesses/accessed/
sreynen - that's a good question
tantek: Seems a little ineligant.
kingryan - how hard it is to get such 404-like (maybe they are actual 404s) logs from the wiki
blueNine - yes, but not new
Phae, note: http://microformats.org/wiki/mailing-lists#new_list_proposal
since you and Drew helped kick off the whole "new mailing list" discussion ;)
ah, okay
I'll decide over dinner.
the real answer is that microformats-discuss *should be* the entry level microformats list in general
tantek, sreynen: try this: http://microformats.org/wiki/Special:Wantedpages
Yeah, that's probably accurate.
and when someone "advances" from that they can jump on one of the more advanced lists
re the mailing list proposals...
maybe a diagram would help ;)
why don't we try fixing uf-dev first and see if that helps?
No, it's not that complicated :P
uf-dev is the wrong place for *new* microformats
two problems
I know
I know
uf-dev should be focused on code
but why don't we fix it?
uf-dev is just mostly unused isn't it? I glance at the archives sometimes and they seem short
see uf-dev thread on that kingryan
it's unused because we don't let people join
heh
I've read that tantek
then reply to it
I'm just sayin', let's just change one variable at a time
if no-one objects within a day or so
then we can make that change first
we'll give the "new list name" discussion a bit more time
since there appears to be a calm in the species/currency/mars storm
;)
that's exactly what I'm proposing
excellent
the "Martian currency birdstorm of 2006"
heh
we'll be telling our grandkids about this someday
[[mailing-lists]] http://microformats.org/wiki?title=mailing-lists&diff=0&oldid=9485 * ScottReynen * (+72) new list proposal -
grep $error `ls -t /path/to/logs/*access* | head -$numhead` | cut -d "\"" -f 2,3,4 | sort | uniq # where $error = 404 and $numhead = 10 will give you 404'd urls from the 10 freshest logs
[[mailing-lists]] http://microformats.org/wiki?title=mailing-lists&diff=0&oldid=9486 * RyanKing * (+65) adding my vote for the null action (there's alway a null hypothesis, right?)
won't give you the most common 404's though
ryanking, that's not exactly what i'm looking for
yeah, bewest, that'd be nice if mediawiki served empty pages as 404s
I just hit http://microformats.org/wiki/asdfasdfasd and got this:
66.92.180.250 - - [16/Oct/2006:11:38:19 -0700] "GET /wiki/asdfasdfasd HTTP/1.1" 200 6012 "-" "Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.4) Gecko/20060613 Camino/1.0.2"
ah
so there's really no way to get such a list then, eh?
so look for all files with about 6000 bytes
:-)
I cold make guesses based on page size, I guess?
yup
they would be remarkably similar, I'm guessing
.
[[class-names]] N http://microformats.org/wiki/class-names * ScottReynen * (+30) redirect to existing-classes
thanks scott
hmm, that's more of a rewrite than a redirect
kingryan, I *do not* want to see uf-dev get overwhelmed with discussion of the creation of new microformats the way that uf-discuss has been
I don't think it will
that only moves the problem, rather than fixes it
ok
I just want to be clear that the scope of uf-dev is not changing
but spreading some discussion and interest around (load balancing, if you will) could help
topics of discussion / purpose etc.
yes
it's only changing in scope of who gets in
yes
I think one of the other complaints about uf-dev is that only those with public, working implementations can take part... and I realise that's to keep out time-wasters, but if you allowed more people in, it'd move some threads to that list instead
[[mailing-lists]] http://microformats.org/wiki?title=mailing-lists&diff=0&oldid=9487 * Cgriego * (+14) Added vote for microformats-research
Phae, yes, that's the point of opening up uf-dev subscriptions
Phae, I thought that, but then I realized exactly how low that hurdle is
sreynen, right, but even maybe that low hurdle may be too much of a hurdle
hmm
and it puts the burden on the list moderators
which we've been unable to deal with
have more list moderators?
i'm not sure we need the moderation
i think self-moderation might work
i'm willing to risk the openness and see what happens
I'm talking about moderating the subscriptions
right
i.e. what's proposed
yeah, sreynen.
right to scott that is
we *did* have a problem back when mf.org first started - very few people had written any code
certainly seems more reasonable than creating more lists
I think self-moderation would work. I mean, it's not like uf-discuss is unbearably active. I'm sure dev would look after itself just fine as a specialised, open, list
but I don't think we have that problem anymore- the number of people with experience will outweigh those who don't know what they're talking about
Elzriel is not sleeping. He is waiting.
kingryan, right, I think those are the points I tried to make on the list
As Tantek said - try it for a while. If it's not working out well as a self-moderated list in a month or two, change it back.
Phae, actually, I think uf-discuss did get unbearably active with new microformats discussions for a while
No real harm in trying.
hence the need to shunt those discussions off to another list
because right now they are scaring away newbies
I guess it didn't bother me? I suppose people have different tolerences.
right
Fair enough.
tantek: I agree. seems like every day someone has a new proposal for something or other
I can see how that'd be the case.
for a lot of folks, microformats are something they can only put a little bit of time towards, and we should respect that
bewest: I think a part of that is because, as we were saying in the thread, the introductory information on the site and wiki isn't good/clear enough.
i think it's good to keep the existing implementation hurdle in words though, just to have something to point to if/when problems do arise, so it doesn't come off as an arbitrary rule
they just want to use them, maybe get a little advice about when and how etc.
So people jump straight in at the discuss list
sreynen - good point
Phae, but that's good that they jump straight into the discuss list
You think?
Phae: agreed. but even the proposals for what to do about that are forthcoming all the time
I'd like to see the wiki pages better maintained.
we want folks new to microformats to feel welcome
I've put question on the wiki for htem to be ignored.
questions*
Phae, you're right, and thanks much for your help with the FAQ pages
Phae: part of the problem is that people propose things and then create new pages, furthering the fragmentation in that effort
No where near started :P but things like that need to be looked after more
I'd be interested to know what other topics on the wiki you're interested in helping improve
and those people who have started wiki-FAQ and discuss pages should make sure to look after them
and respond to queries and ideas that get put there
yes
but sometimes there are only 24 hours in a day
I realise that :P
But pages don't get updated or looked at (it seems) for months
which makes it all look and feel a bit stagnant..
Sorry. Tangent, but I do think if you want to cut down on the newbie-ish threads, you need a better maintained wiki
sreynen: you have a good point- we can keep the rule, but just enforce it differently. Currently our policy is that you're unqualified until you prove otherwise- we can invert that, but keep the same expectations.
sounds good to me
[[mailing-lists]] http://microformats.org/wiki?title=mailing-lists&diff=0&oldid=9488 * Phae * (+65) Voting
wb
ugh
darn net disconnects
tantek: the darn apple battery recall has sent another technorati sticker to the dustbin in the sky :) :(
or at least the landfill
unintended consequences for us stickerphiles :)
[[mailing-lists]] http://microformats.org/wiki?title=mailing-lists&diff=0&oldid=9489 * BenWest * (+27) voting
I don't see how -research, -process, -suggest, -propose are substantially different
from a practical perspective
they're not that different. research is the only one I like because it doesn't insinuate that a format has to necessarily be suggested... it's more general.
sreynen: for your redirect writing pleasure: http://microformats.org/temp/404.txt
great, thanks
those are pages around the size of the mediawiki empty page
bewest, from my perspective -suggest and -propose encourage actions that we want to discourage
Phae, I like -research as well because it can continue even for established formats
yeah
Exactly
sreynen: actually let me redo it with 200's only (there's a bunch of 304's in there)
ok
is the main page of the wiki considered "stable" or what?
[[HCalendarIssues]] http://microformats.org/wiki?title=HCalendarIssues&diff=0&oldid=9490 * ScottReynen * (-1)
I suppose, bewest, why do you ask?
http://simile.mit.edu/solvent/ I like how they have /very/ FAQs on the main page of each project... specifically "What is this?" "What can I do here?" "Why do we do this?"...
I think it reads it a bit clearer
[[faq]] http://microformats.org/wiki?title=faq&diff=0&oldid=9491 * Phae * (+41) minor tweaks
sreynen: list updated to include only 200's in the range
some of the information on the main page overlaps with what I believe people are interested in, but it's not quite the same focus and is a bit hard to read
thanks ryan
I agree
I've had a todo item to trim the homepage for awhile
mm.. I do like that, bewest
we just need to make sure that nothing gets lost or ophaned
perhaps a more rigid structure (like a skeleton outline for certain types of pages) would solve a lot of the complaints about the wiki being hard to read etc....
bewest: we've tried to to that with the specs a bit
right, with the specs
bewest - if you have specific suggestion, add them to a section with your name on it in the "to-do" page
http://microformats.org/wiki/hresume is a big improvement over the previous ones (IMNSHO)
[[mailing-lists]] http://microformats.org/wiki?title=mailing-lists&diff=0&oldid=9492 * AndyMabbett * (+95)
kingryan: :-)
and there was a plan at some point to "backport" that organization to older specs
To be honest bewest... I think it's one of those things that we should start improving as we see the need.
I'm guilty of talking about it more than doing it, so I'm going to stop that :P
Phae: what do you mean
oh right right
yes, it's very seductive
talk is easy
kingryan, bewest, see: http://microformats.org/wiki/to-do#update_specification_section_organization
Well.. rather than saying.. we should do this.. it'd be awesome. Just do it :) It's a wiki. If everyone hates it, it'll get rolled back :D
[[mailing-lists]] http://microformats.org/wiki?title=mailing-lists&diff=0&oldid=9493 * JustinThorp * (+18)
kingryan, it makes more sense to discuss the reorganization that we experimented with in hResume on the list etc.
the people like the voting
yeah - I didn't react in time to do the same for currency stuff
having a "poll" on a separate
site
why discuss it? I think it's proven to be useful
is not as useful/flexible
just do it
how has it been proven?
people have said "the hresume page is easier to read"
we discuss it because you and I are not the only ones interested in helping contribute to improvement of the usability of the wiki
I think it's easier to read (but I wrote it, so I don't really count)
and others will likely have better ideas too
makes sense to have some amount of community buy-in
I think starting with our improvements is a good first step
kingryan, I too think it is easier to read
I think so too - but would rather involve more community input - since many others have expressed interested in helping with readability/usability
we can implement our ideas first, the The Community can add more suggestions (and even implement them)
tantek, it *is* a wiki
The Community can edit it
http://theryanking.com/blog/archives/2006/08/18/etfw/
for smaller incremental improvements that works fine
kingryan: Andy would agree
for reorganization/rewrites it doesn't work
you just get thrash
the community doesn't edit those pages on the wiki because they're looking to us for approval
kingryan, there is some of that
but there is some of the "edit too much" also
why not simply let the discussion take place?
that's true. I know I wouldn't feel "comfortable" re-writing or re-organising an entire, well-established, section
less talk, more rock!
not when more rock wastes time for everyone
and causes more thrash
we don't really use the talk pages on the wiki
go ahead, have the discussion
it's a fuzzy line, eh?
I'm just sayin...
KevinMarks - we have the list for that
which is different from the wikipedia pattern
KevinMarks: that may be a solution... encourage talk use?
KevinMarks: that's on purpose
right
tantek: but the list is being used to talk about work
...because that's a bad way to have a discussion
well, it's a scale thing
tantek: the talk pages allow people to test out real ideas where they will actually be implemented...
but if we start using talk we have to deal with what goes in talk vs. what goes in -discuss
it is one way to stop the same discussions recurring
pnhOldbook: aren't we already dealing with what goes into -discuss, regardless?
I don't think the talk pages would get used anymore than the research and FAQ pages for specific formats get used, anyway
discuss is just *faster*
and we're all impatient people
the list just about works at our current scale, but I don't read all the threads
bewest: just raising a potential concern.. its just another place for things in that middle is it meta- or spec stuff to get lost
(and i didn't mean the list sorry.. i meant -issues)
pnhOldbook: ok, to clarify: I'm not talking about spec pages
pnhOldbook: I'm talking about pages like the main page or all the pages revolving around "getting started" issues
gotcha
the -discuss lists generates lots of proposals, more fragmentation on the wiki, and not much else. using the talk pages on existing pages might encourage more incremental work
ah. now I've read the thread on -discuss
back to the subject of reorganizing old spec pages....
just because the community may have more and better suggestions shouldn't keep us from implementing good ideas for improvement we already have
Phae: are you interested in spec pages or supporting pages?
both :P
In this conversation - support.
right
in Andy's 'rewrite hCalendar spec' example, putting his refactoring on the Talk page might make sense. I have seen that work fairly well in contentious areas on wikipedia
ok so under the category of "making the wiki easier to use" there are two areas which might use different techniques? how to reorganize specs versus how to make "support" pages more useful?
is that accurate?
yeah.
certainly, though they overlap
ugh - dropped off again
of course.
specs need to be clearer, for one, and supporting pages need to be better maintained as people use them
specs also have a special need to be "stable", correct?
the way hCalendar RPC's to iCalendar for the field list is a bit confusing; putting a list of the fields in the spec itself would be good
well... ideally. stable formats should have stable reference points.
Phae: not sure I followed you
ah
then? uh... what.
heh
and you likely missed some of ours
but I just read the archvies
I'm listening to a podcast, and my mother just appeared on msn. :/
Good evening
archives even
Phae: multitasking to the extreme?
yes :(
sorry. what i meant is...
the spec pages are mostly... overcomplicated and don't have enough quick-start help
and there are often supporting pages that look like they encourage questions and such
but are never responded to
hmmm
I'm a fan of recording *everything*
mostly because I don't like repeating myself
and i know we have mail archives, but they're not the easiest thing to use for a new person
we need some IA, basically
Phae, I agree
mail archives suck for findability
is there a way to run a card sort on the list/wiki?
perhaps that could give the community some guiding direction on how things should be organized
it's why i'm trying to start off that "rejected-formats" list, because I don't like reading about the same ideas, that just don't work, reguarly
heh
but that'll mean i need to go back through the archives
which i'll do on a day i have nothing else to do :/
Phae, not necessarily
drewinthehead is the author of hKit and a developer for Yahoo! Europe
we can think of formats in a spectrum of stages
hey drew
from rejeted to wel establisehd
yea
and all sorts of "idea" "problem defined" "researched" etc. inbetween
a few catchup responses:
yeah, but there's some things that just don't work. the example i've logged so far was that one drew and i wasted a day on
greetings, people of the internets
Phae, that's true too
the people of the internets greet you, drewinthehead
greetings drew
re: scaling (Talk pages). Not a scale thing Kevin. different in content. Wikipedia pages can locally figure out what's best for them whereas standards/specs etc. help if there is more globally agreed upon style/organization etc.
re: it is one way to stop the same discussions recurring. KevinMarks - you can document discussion resolutions on the wiki in *-issues and then simply reference those in email with permalinks.
we're not using Talk pages. that's why they are removed from the UI of the wiki.
intro questions about wiki pages is perfectly core for uf-discuss
kingryan, you and I and other "oldtimers" in particular have a responsibility to more overtly solicit input and encourage participation by more folks in the community in such things as how to make pages more usable.
of course it is *easier* if you or I etc. just go make the changes, but it is better if we encourage others who have already spoken up to also help, as Kevin might say, it scales better in the long run (more active, harmoniously cooperating participants), even if it is slower in the short run.
it did, tantek
bbiab - I have to go
:)
Phae: so which is the focus on the wiki? the spec pages, or quick start support pages that funnel interested readers to the specs?
currently?
ah .. that's me
I think it'd encourage more use to have quick-starts to the foreground
but specs there for those that wish to use them
Coming face-to-face with a spec as your first encounter with microformats doesn't exactly make them welcoming
right
i don't think it will work to move the specs away from where they are now, but if we had good quick start pages in a standard location, i'd start pointing people there instead of the spec pages
mm
it's a toughie.
like /wiki/hcard-info ?
and /wiki/rel-tag-info
like hcard-authoring
like hcalendar-authoring
we could also start *-intro pages
[[hcalander]] N http://microformats.org/wiki/hcalander * ScottReynen * (+23) Misspelling redirect
to provide quick intros
and *-tutorial pages to provide longer detailed introductions and tutorials about each microformat
can we have deeper hierarchies?
like /wiki/learn/hcard
[[hcal]] N http://microformats.org/wiki/hcal * ScottReynen * (+23) Common abbreviation redirect
BTW - this is why at the top of hCard and hCalendar the first thing after the intro paragraph is a sentence (or two) directing new folks to the hCard creator and hcard-authoring pages
tantek - do you agree that a list of hCalendar fields in the spec would be a useful addition?
Kevinmarks - did you see my email on the list about that?
[[date]] N http://microformats.org/wiki/date * ScottReynen * (+37) Common (?) abbreviation redirect
[[to-do]] http://microformats.org/wiki?title=to-do&diff=0&oldid=9494 * BenWest * (+1072) Ben West (bewest) - added wiki revision to my todo list. can we converge on organization goals?
thanks bewest
mmmm don't thank me too soon
not yet
haven't done any work yet
[[resume]] N http://microformats.org/wiki/resume * ScottReynen * (+21) Common abbreviation redirect
bewest, even just outlining what you think needs to happen, in a public place like that is progress
the goal here is to invite collaboration on such matters
and encourage
since there are a bunch of people that want to help make it happen
all of whom almost certainly have different ideas as to how to "best" do it
gr
Ernie wanted to do the same thing "F
Phae, yeah
OK, now I have read the whole thread and I still don't see and answer to that
tantek: you think it's worth bringing up on the list? perhaps with something actually on the wiki in a place designated as a work area we can get some intertia and get some consensus going
bewest, i'm worried about the list-thrash-noise potential
I'd rather that folks attempted to organize their own thoughts first - using their own to-do sections
there are clearly lots of people, including Andy, who are prepared to help. thrash/noise comes from a lack of convergence of goals
having to go and read RFC2445 to know what the field names are is offputting, especially when you then discuss them in detail in the following sections
and from a lack of desire to listen to others
in that case, I will simply add my 2 cents to the current thread
KevinMarks - I said: That is very reasonable, the right thing to do then is to add a section
similar to the section in hCard which serves that purpose, *without doing
any other changes*.
at the top of the message from me at 12:13pm on the uf-discuss list
ah right sorry
lost that in Andy's rhetorical overdose
right
i think it would be best for the microformats community if someone else started responding to andy
his most recent message appears to indicate he didn't read my previous message thoroughly either
I'm not sure how to best follow-up
sreynen, point taken. thanks.
I'm replying now with the invite to comment on changes in the to-do section
thanks bewest
nothing against tantek, but andy seems to have an evil villain picture in his mind
looking at hCard, the property list would make more sense under 'In General', before 'More Semantic Equivalents'
i'd respond myself, but i think he has the same picture of me
sreynen, i suppose we can't all be evil villains right, and if we are, then what's the point of being on the list? ;)
indeed
KevinMarks - perhaps add that to your section on the to-do page
as specific suggestions will likely get as lost here as they do on the mailing list when there is a lot of traffic
right
thanks!
it seems to me that wiki/* (where people are mostly likely to go) should be the intro page and it should link to wiki/*-spec
cgriego: me too. do you have a to-do section?
I do not
cgriego: then I invite you to A.) leave a comment in my to-do section with your name stating as such or B.) Starting your own to-do section and commenting there
hmmm you know what would be cool?
for my blog posts tagged as microformat and todo to automatically show up in my wiki to-do section
[[to-do]] http://microformats.org/wiki?title=to-do&diff=0&oldid=9495 * Cgriego * (+475) Commented in bewest's section on wiki/* as an intro page and wiki/*-spec.
cgriego: thanks
bewest: np
cgriego: this intro page would look something like "What is this?" "Why are we doing this?" "Current Status?" "Simple Example"
?
brb
bewest: right, just enough to get people started and then where to look for more info
I think hCard should have a boolean "Evil Villain" value.
http://technorati.com/tag/microformat%20AND%20todo
Hi Ashley
you can simply use the "categories" as "tags" and tag an hCard as "Evil Villain"
that should work
;)
Ooh, man. I really need to get a grip on hCard.
Thanks tantek. :-)
np
So you can add <x class="category">Villain</x>
Can you have something more definition-like... As in Villain=Evil, or something?
why? at it's simplest it is just a label
its simplest
I'm just thinking for parsing. I'm musing over writing some software that's going to need to parse some attributes like that, but I'm not sure how to do it.
key value pairs in hCard, or more generally?
More generally. I'm going to try come up with a decentralised social network.
Well, beyond XFN.
You know, categories could work anyway.
[[to-do]] http://microformats.org/wiki?title=to-do&diff=0&oldid=9496 * Tantek * (+81) add property list to hCalendar - duh how did I forget this?
[[to-do]] http://microformats.org/wiki?title=to-do&diff=0&oldid=9497 * AndyMabbett * (+3) [[hcalendar|hCalendar]] - correction
have you checked out rel-tag, Ashley? perhaps rel-tag + XFN does what you need
I'd say see how far you can go with tagging, before worrying about key-value pairs
tagging is much simpler for people to grasp generally
That's probably more what I'm looking for, rather than using categories on an hcard.
and very flexible
another interesting use is in hReview, where you can rate the thing you're reviewing on different tags
What do you mean?
say you're reviewing a restaurant you cna give it 3 stars on food and 2 on ambience
Oh, that's cool. :-)
I could've used that the other day.
it uses rel-tag fro those
li class="rating"><a href="http://flickr.com/photos/tags/Ambience" rel="tag">
Ambience: <span class="value">19</span>/<span class="best">30</span></a>;</li>
This might sound strange, but is there a way to categorise tags?
I'm aiming to let the user publish different interests, by category. For example under the music category they'd have a bunch of favourite artists. Is that even an okay use?
hm
rel-tag deliberately leaves the scope a little vague so other formats that sue it cna tighten it up
litigious formats, eh?
usually, tag overlap isn't a big problem;
bah
do we have/need a wiki-complaints page for people to record their experience of using the wiki?
to-do is different
I'm interested in collecting a list of places people had trouble reading
typically people will respond, such as Roger when I asked him for clarification on why he was having trouble with fn + org
putting that type of thing on the to-do page doesn't seem quite right
and just now Justin Thorp has described his problems with "not seeing page on authoring"
he also had a suggestion for a sidebar
where does such a thing go?
to-do page again seems kind of inapropriate
on tag spaces you could certainly use different tag clouds/spaces for different topics (via the url / href) but I'm not sure how well that would be
... would be enforced outside of your specific application
(that data often gets stripped/ignored by consuming applications)
Well, KevinMarks said that tag overlap isn't a big problem, and I think I agree.
if they are your own tagspaces, you could have http://ashley.com/tag/artist/Pink and http://ashley.com/album/Pink
bewest: how about /wiki/wiki-feedback ?
or you could use last.fm as a tagspace
exactly.. though it will probably wind up being combined with the color by some applications regardless
KevinMarks: That's hat I was thinking, but ultimately it'll be up to the user if they want to change it.
http://www.last.fm/music/New+Order
they do artist/album/track
http://www.last.fm/music/New+Order/Substance+1987
kingryan|lunch: I'm on it
as well as having a general tagspace
http://www.last.fm/tag/80s
hm, their data has got a lot more filled out since I last looked at it
cool
[[wiki-feedback]] N http://microformats.org/wiki/wiki-feedback * BenWest * (+682) started wiki feedback page. added two examples
[[wiki-feedback]] http://microformats.org/wiki?title=wiki-feedback&diff=0&oldid=9498 * BenWest * (+12)
i used it for a little while.. twice.. but i never really did anything but let it 'listen' to me
[[wiki-feedback]] M http://microformats.org/wiki?title=wiki-feedback&diff=0&oldid=9499 * BenWest * (+14)
[[wiki-feedback]] http://microformats.org/wiki?title=wiki-feedback&diff=0&oldid=9500 * Ashley * (+345)
too many things are tagged just plain wrong
when beethoven is tagged as bach and they don't support fixing it, I can't use it
Really? I've been pretty impressed so far.
well, tags are subjective
ok, but I don't like Beethoven tagged as Bach :-)
I might just be a snob though
they don't really address the performer/composer problem
but then no-one really does
snobs don't like tags
also, Enya and other inapropriate stuff is tagged as jazz
snobs like ontologies
evidently everyone defining mp3 tags didn't listen to classical music much
when I'm expecting to hear Myles Davis and then all of a sudden get Enya...
the effect on me is severe
I'm getting the heebie-jeebies just thinking about it
Haha. I'm shocking classifying genres of music, but that's just terrible.
consensus tags are hard
kingryan, has nothing to do with ontologies vs tags. one can incorrectly choose jazz from an ontology as easily as they can type "jazz" in a tag field ... if they think enya is jazz. in both cases you want to filter out bogus assertions, but doing so is almost completely orthogonal to ontologies vs tags.
I know mlinksva, the thing is, with tags, there is no *correct* answer. Whereas with an ontology there is.
tantek is Tantek <http://tantek.com> and works on Technorati and develops microformats <http://microformats.org>
[[wiki-feedback]] http://microformats.org/wiki?title=wiki-feedback&diff=0&oldid=9501 * BenWest * (+274) Complaints: - doing a search on "trouble" in the mailing list... added Andy's coworker's troubles
i disagree, unless you consider tags semantically meaningless and ontologies' meaning precisely defined, neither of which is true for practical purposes ... but who cares :)
ontologies are for things that already mean something. tags are for things that might mean something. both can contain false assertions?
ontologies are better for things that are static and don't change over time.
oh wait...
[[wiki-feedback]] http://microformats.org/wiki?title=wiki-feedback&diff=0&oldid=9502 * BenWest * (+335) added the common complaint that there is no place capturing "rejected" or "dead" ideas. result is repeated discussion and effort.
[[wiki-feedback]] M http://microformats.org/wiki?title=wiki-feedback&diff=0&oldid=9503 * BenWest * (+0) Complaints: - minor formatting
bewest, wiki-feedback page is a great idea, thanks for creating that
np
[[wiki-feedback]] http://microformats.org/wiki?title=wiki-feedback&diff=0&oldid=9504 * BenWest * (+433) What can I do here? - some instructions on use.
gah.. evidently I don't know how to make links properly
[[wiki-feedback]] http://microformats.org/wiki?title=wiki-feedback&diff=0&oldid=9505 * BenWest * (+31) What can I do here? -
[[wiki-feedback]] http://microformats.org/wiki?title=wiki-feedback&diff=0&oldid=9506 * BenWest * (+493) What can I do here? - suggestions for places to look for complaints
[[wiki-feedback]] M http://microformats.org/wiki?title=wiki-feedback&diff=0&oldid=9507 * BenWest * (-1) What can I do here? -
[[wiki-feedback]] M http://microformats.org/wiki?title=wiki-feedback&diff=0&oldid=9508 * BenWest * (+1) What can I do here? -
[[to-do]] http://microformats.org/wiki?title=to-do&diff=0&oldid=9509 * BenWest * (+81) Information Architecture - request for help, link to wiki-feedback
[[wiki-feedback]] M http://microformats.org/wiki?title=wiki-feedback&diff=0&oldid=9510 * BenWest * (-1) Complaints: - fixed link to my name
bewest: You can type four tildes and it'll sign your name automagically.
~~~~
aha :-) thanks for the tip!
I was wondering how you did it
[[to-do]] http://microformats.org/wiki?title=to-do&diff=0&oldid=9511 * BenWest * (+52) Frances Berriman - shameless attempt to recruit resident usability expert.
*ahem*
[[wiki-feedback]] M http://microformats.org/wiki?title=wiki-feedback&diff=0&oldid=9512 * BenWest * (+69) Complaints: - fix my name again
hah... it works
Well, I'm off. It's been great talking in here -- I've got more reconnaissance done for my app in a few minutes than I have in the last week. ^_^
[[User:BenWest]] N http://microformats.org/wiki/User:BenWest * BenWest * (+351) my personal wiki page
[[User:BenWest]] M http://microformats.org/wiki?title=User:BenWest&diff=0&oldid=9513 * BenWest * (+4) See Also - fix links
ontologies try to be hard-edged and disjoint; tags are overlapping and fuzzy
David weinberger is writing a whole book about this
sreynen is Scott Reynen, who makes things at makedatamakesense.com
These logs were automatically created by mflogbot on chat.freenode.net using a modified version of the Java IRC LogBot.
See http://microformats.org/wiki/mflogbot for more information.