Re: [uf-discuss] Live Writer and microformats

[Kevin Marks]

There is a list of current classes on the wiki, though being able to 
insert rel values is also important:


http://microformats.org/wiki/existing-classes

On Oct 5, 2006, at 10:22 PM, Chris Messina wrote:


This kind of delves into the "authoritative standards" doesn't it? And
how do you keep up with an ever-growing repository of microformats?

Obviously it can be done -- and it's something that we need,
especially if we're to get support for microformats into client-side
software... so isn't that where remote definitions/profiles come in?
Sorry for showing my ignorance here, but how would, for example,
Flock, (or better, Lucene) stay up-to-date with the most current
listing/definitions of all the available microformats?

Chris

On 10/5/06, Matt Augustine <[EMAIL PROTECTED]> wrote:
Yes, this is currently the case.  We are working on a solution, 
although I can't make any specific commitments.


>From what I've gathered, one of the reasons that some blogging 
platforms strip class attributes is to prevent users from marking up 
posts in a manner that uses existing CSS definitions to alter the 
layout of the page, hide ads etc.  One solution we've discussed is to 
create a white list of known microformat classes and to allow them.  
What do you all think about this?  Any other suggestions?


___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Live Writer and microformats

[Chris Messina]

This kind of delves into the "authoritative standards" doesn't it? And
how do you keep up with an ever-growing repository of microformats?

Obviously it can be done -- and it's something that we need,
especially if we're to get support for microformats into client-side
software... so isn't that where remote definitions/profiles come in?
Sorry for showing my ignorance here, but how would, for example,
Flock, (or better, Lucene) stay up-to-date with the most current
listing/definitions of all the available microformats?

Chris

On 10/5/06, Matt Augustine <[EMAIL PROTECTED]> wrote:

Yes, this is currently the case.  We are working on a solution, although I 
can't make any specific commitments.

>From what I've gathered, one of the reasons that some blogging platforms strip 
class attributes is to prevent users from marking up posts in a manner that uses 
existing CSS definitions to alter the layout of the page, hide ads etc.  One 
solution we've discussed is to create a white list of known microformat classes 
and to allow them.  What do you all think about this?  Any other suggestions?

Matt Augustine
Software Development Engineer
CSA Concept Development Team
Microsoft Corporation

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Conor O'Neill
Sent: Thursday, October 05, 2006 2:24 PM
To: Microformats Discuss
Subject: Re: [uf-discuss] Live Writer and microformats

I'm doing up a list of which blog and social networking platforms do and
don't support microformats. Sadly Windows Live Spaces seems to be one of
the non-supporting platforms. Can you confirm that Matt?

Conor

Matt Augustine wrote:
> Windows Live Writer publishes events that have been pasted into blog posts as 
hCal whenever possible, even if the event was subsequently modified using the 
built-in event editor.  The only exceptions are for blogging platforms that don't 
allow class attributes in the HTML.  Unfortunately, there are many that don't, but 
that's another issue.
>
> Matt Augustine
> Software Development Engineer
> CSA Concept Development Team
> Microsoft Corporation
>
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Conor O'Neill
> Sent: Thursday, October 05, 2006 11:41 AM
> To: Ryan King
> Cc: Microformats Discuss
> Subject: Re: [uf-discuss] Live Writer and microformats
>
> Ryan King wrote:
>
>> On Oct 3, 2006, at 11:55 PM, Conor O'Neill wrote:
>>
>>
>>> I'm not sure if any of you spotted this as it was not part of the
>>> original release notes but Windows Live Writer now has a plug-in
>>> which allows you to insert hCalendar events in your blog posts.
>>>
>> Has anyone looked at the markup they're producing?
>>
>> -ryan
>>
>>
> I haven't looked at the markup but Tails seems to like it (e.g.
> http://eirepreneur.blogs.com/eirepreneur/2006/10/experimenting_w.html)
>
> Conor
>
>
> ___
> microformats-discuss mailing list
> microformats-discuss@microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss
> ___
> microformats-discuss mailing list
> microformats-discuss@microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss
>
>

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss




--
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
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Citation Microformat: LazyWeb for BibTeXperts

[Bruce D'Arcus]

On 10/5/06, Brian Suda <[EMAIL PROTECTED]> wrote:


I have updated my Straw proposal slightly to avoid collisions with
class values and to bring it in line with other formats (e.g. hResume,
what was 'title' is now 'fn')


Why? Seems quite awkward to me to call a title a "fn."

...


Taking the implied schema, i began to create an XSLT that maps those
values to BibTeX. NOTE: this is NOT a 1:1 mapping of BibTeX, it is a
mapping of COMMON values in the wild to their BibTeX equivalents (or
atleast i think they are equivalent - some one will tell me otherwise
i'm sure). Eventually, there will be XSLTs to map between the
microformat and other citation formats through the Implied Schema.

XHTML-2-Citations
http://suda.co.uk/projects/microformats/X2C/


You have a list of formats. I'd call RIS (and the related
Refer/Endnote) an important legacy format; much more so than some of
the others. I'd be willing to send you some XSLTs I've written that
convert my RDF vocab to/from MODS, which might help. Contact me
off-list if interested.

...


let me know. Is the Straw proposal adequate? Is KEY required (can this
be accomplied with the ID attribute)?


I take you mean the bibtex key? I'm pretty sure it's required.

I don't your simple example is quite right. This:

@PDF{
TITLE="Using Microformats",
ABSTRACT="Interest in microformats has been steadily on the increase.
Microformats are easy to learn and implement. If you are a
Web-designer, a back-end programmer, or an interface engineer,
microformats are relevant to your field.",
KEYWORDS="book,oreilly,pdf,microformats,brian+suda",
YEAR="2006",
MONTH="09",
AUTHOR="Brian Suda",
PUBLISHER="O'Reilly Publishing",
ADDRESS="1005 Gravenstein Highway North, Sebastopol, CA 95472, USA",
}

... should be:

@BOOK{some-key,
TITLE="Using Microformats",
ABSTRACT="Interest in microformats has been steadily on the increase.
Microformats are easy to learn and implement. If you are a
Web-designer, a back-end programmer, or an interface engineer,
microformats are relevant to your field.",
KEYWORDS="book,oreilly,pdf,microformats,brian+suda",
YEAR="2006",
MONTH="09",
AUTHOR="Brian Suda",
PUBLISHER="O'Reilly Publishing",
ADDRESS="1005 Gravenstein Highway North, Sebastopol, CA 95472, USA",
}

@PDF is not a valid type, nor is it even a type in any case; it's a format.

Bruce
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: Software Projects Description Re: [uf-discuss] Potential Microformats

[Bruce D'Arcus]

On 10/5/06, Tantek Çelik <[EMAIL PROTECTED]> wrote:




> I didn't follow microformats.org process, though I do believe some of
> the key prerequisites have been fulfilled.

This is the key.  Just taking an existing format and translating them to
class names is not enough - as the folks working on citations will tell you.


I don't think the domains are equivalent though. Citation metadata
covers a whole lot of ground (basically everything referenced on
Wikipedia), and  has a long legacy. Not so with project descriptions,
and I think DOAP is pretty much the only game in town there (and
really well designed).

Bruce
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

RE: [uf-discuss] Citation Microformat: LazyWeb for BibTeXperts

[Joe Andrieu]

Brian,

Great work. I'm excited to see so much progress, as hCitation is one of the
most critical uFs in my current project.

Based on what you've done, I have a process question.

I, and others, have mentioned the need for a DateAccessed field, which is
required by several citation standards when referencing online work, e.g.,
the APA Style Guide [1].  I mentioned that on the Wiki, but didn't add the
use cases I'm concerned with, until just now.

I'm assuming that means it isn't included in what you've done so far.

One use case is capturing/copying HTML from web pages, ala Google
Notebook[2], Onfolio[3] or Kaboodle[4].  When such captures are made, it
makes sense to keep track of the full citation data, including the date it
was accessed, which may or may not be the date it was published.  Hence, my
interest in the recent Apple patent about meta-data with Cut & Paste.

Process-wise, how do I contribute such that a dtAccessed field (or
equivalent) makes it into the final standard?

The implied schema on the citations-formats page[5] includes the
dateAccessed, for which I just updated the link to examples so it goes to
the APA style guide (the old one was invalid).

However the implied schemas in your straw format in
citations-brainstorming[6] don't include dtAccessed and it seems wrong for
me to simply add it via the wiki.

Certainly, one could make a case that citations to online references fails
the 80/20 rule, because the vast bulk of current citations are to print
materials.  However, I think a bit of forward thinking here might be in
order.  Any blog that cites any other online content, whether a blog or news
article, /could/ use an hCitation to properly link to the cited reference.
Such citations, I would argue, should include the access date when the
blogger saw the referenced material, because we all know that the resources
on the other side of those links can change without notice.  This is another
common use case that I think should inform the new standard.

I just added the two use cases mentioned here to the Wiki.

And surprisingly, it was illuminating and disturbing. =)

I realized that the two cases focus on potentially marginal cases in the
microformats religion, because they are too forward-looking. The first
because it is missing the "output" part of the cut & paste, where the uF
would actually be used as part of the paste.  The capturing isn't where uFs
are important, it is the pasting and the current tools aren't necessarily
using HTML output.  The latter because bloggers have a working citation
mechanism that is just a link to the URL (hopefully a permaURL). One could
argue they wouldn't want a full hCitation. And in fact, until a tool exists
that makes it easy, they probably won't.  However, a tool that cuts & pastes
from anywhere on the web into a blog with a full citation seems like a nice
tool. Yet, I'm not really paving the cow paths with these ideas.

As you seem to be the shephard on this effort, what can I do to help with
this particular issue? (Other than raise a few points here?)

And what is the role of forward-looking use cases when the nature of the
situation is the shifting of real-world reference points from the
physical/published world to the online/digital world?  In other words, the
existing cow paths are through forests of dead trees!

That said, I am a big fan of what you've done so far.  I'm just not sure how
these remaining details get worked out on the way to a "final" microformat.

-j

[1] http://www.apastyle.org/elecsource.html 
[2] http://www.google.com/notebook 
[3] http://onfolio.com/
[4] http://www.kaboodle.com/
[5] http://microformats.org/wiki/citation-formats
[6] http://microformats.org/wiki/citation-brainstorming

--
Joe Andrieu
[EMAIL PROTECTED]
+1 (805) 705-8651



> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On 
> Behalf Of Brian Suda
> Sent: Thursday, October 05, 2006 2:12 PM
> To: Microformats Discuss
> Subject: [uf-discuss] Citation Microformat: LazyWeb for BibTeXperts
> 
> 
> Calling all BibTeXperts.
> 
> I have found a few free cycles here and there and have pieced 
> together the first of many XSLTs that will convert the 
> Citation Microformat to various other formats.
> 
> I have updated my Straw proposal slightly to avoid collisions 
> with class values and to bring it in line with other formats 
> (e.g. hResume, what was 'title' is now 'fn') i also added 
> reference to using rel-Tag as keywords. 
> http://microformats.org/wiki/citation-brainstorming#Example
> 
> Taking the implied schema, i began to create an XSLT that 
> maps those values to BibTeX. NOTE: this is NOT a 1:1 mapping 
> of BibTeX, it is a mapping of COMMON values in the wild to 
> their BibTeX equivalents (or atleast i think they are 
> equivalent - some one will tell me otherwise i'm sure). 
> Eventually, there will be XSLTs to map between the 
> microformat and other citation formats through the Implied Schema.
> 
> XHTML-2-Citations
>

RE: [uf-discuss] Live Writer and microformats

[Matt Augustine]

Yes, this is currently the case.  We are working on a solution, although I 
can't make any specific commitments.

>From what I've gathered, one of the reasons that some blogging platforms strip 
>class attributes is to prevent users from marking up posts in a manner that 
>uses existing CSS definitions to alter the layout of the page, hide ads etc.  
>One solution we've discussed is to create a white list of known microformat 
>classes and to allow them.  What do you all think about this?  Any other 
>suggestions?

Matt Augustine
Software Development Engineer
CSA Concept Development Team
Microsoft Corporation

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Conor O'Neill
Sent: Thursday, October 05, 2006 2:24 PM
To: Microformats Discuss
Subject: Re: [uf-discuss] Live Writer and microformats

I'm doing up a list of which blog and social networking platforms do and
don't support microformats. Sadly Windows Live Spaces seems to be one of
the non-supporting platforms. Can you confirm that Matt?

Conor

Matt Augustine wrote:
> Windows Live Writer publishes events that have been pasted into blog posts as 
> hCal whenever possible, even if the event was subsequently modified using the 
> built-in event editor.  The only exceptions are for blogging platforms that 
> don't allow class attributes in the HTML.  Unfortunately, there are many that 
> don't, but that's another issue.
>
> Matt Augustine
> Software Development Engineer
> CSA Concept Development Team
> Microsoft Corporation
>
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Conor O'Neill
> Sent: Thursday, October 05, 2006 11:41 AM
> To: Ryan King
> Cc: Microformats Discuss
> Subject: Re: [uf-discuss] Live Writer and microformats
>
> Ryan King wrote:
>
>> On Oct 3, 2006, at 11:55 PM, Conor O'Neill wrote:
>>
>>
>>> I'm not sure if any of you spotted this as it was not part of the
>>> original release notes but Windows Live Writer now has a plug-in
>>> which allows you to insert hCalendar events in your blog posts.
>>>
>> Has anyone looked at the markup they're producing?
>>
>> -ryan
>>
>>
> I haven't looked at the markup but Tails seems to like it (e.g.
> http://eirepreneur.blogs.com/eirepreneur/2006/10/experimenting_w.html)
>
> Conor
>
>
> ___
> microformats-discuss mailing list
> microformats-discuss@microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss
> ___
> microformats-discuss mailing list
> microformats-discuss@microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss
>
>

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Live Writer and microformats

[Conor O'Neill]

I'm doing up a list of which blog and social networking platforms do and 
don't support microformats. Sadly Windows Live Spaces seems to be one of 
the non-supporting platforms. Can you confirm that Matt?


Conor

Matt Augustine wrote:

Windows Live Writer publishes events that have been pasted into blog posts as 
hCal whenever possible, even if the event was subsequently modified using the 
built-in event editor.  The only exceptions are for blogging platforms that 
don't allow class attributes in the HTML.  Unfortunately, there are many that 
don't, but that's another issue.

Matt Augustine
Software Development Engineer
CSA Concept Development Team
Microsoft Corporation


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Conor O'Neill
Sent: Thursday, October 05, 2006 11:41 AM
To: Ryan King
Cc: Microformats Discuss
Subject: Re: [uf-discuss] Live Writer and microformats

Ryan King wrote:
  

On Oct 3, 2006, at 11:55 PM, Conor O'Neill wrote:



I'm not sure if any of you spotted this as it was not part of the
original release notes but Windows Live Writer now has a plug-in
which allows you to insert hCalendar events in your blog posts.
  

Has anyone looked at the markup they're producing?

-ryan



I haven't looked at the markup but Tails seems to like it (e.g.
http://eirepreneur.blogs.com/eirepreneur/2006/10/experimenting_w.html)

Conor


___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

  


___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

[uf-discuss] Citation Microformat: LazyWeb for BibTeXperts

[Brian Suda]

Calling all BibTeXperts.

I have found a few free cycles here and there and have pieced together
the first of many XSLTs that will convert the Citation Microformat to
various other formats.

I have updated my Straw proposal slightly to avoid collisions with
class values and to bring it in line with other formats (e.g. hResume,
what was 'title' is now 'fn') i also added reference to using rel-Tag
as keywords.
http://microformats.org/wiki/citation-brainstorming#Example

Taking the implied schema, i began to create an XSLT that maps those
values to BibTeX. NOTE: this is NOT a 1:1 mapping of BibTeX, it is a
mapping of COMMON values in the wild to their BibTeX equivalents (or
atleast i think they are equivalent - some one will tell me otherwise
i'm sure). Eventually, there will be XSLTs to map between the
microformat and other citation formats through the Implied Schema.

XHTML-2-Citations
http://suda.co.uk/projects/microformats/X2C/

So, now we can begin to "round-trip" data. I have marked-up a page or
two of my own and can convert that to a .bib file. The service is very
fragile, it isn't nearly as robust as the X2V, but this is still early
days.

I am calling on LazyWeb to check the BibTeX output (i think there are
some know errors already). As well, i am asking a few people to take
the straw proposal values and mark-up some examples themselves and
test the output from X2C as input into BibTeX applications. In
BibTeX... are there REQUIRED properties? enumerated TYPES? The
Microformats only maps to about 50% of all the BibTeX properties, but
that should be over 80% of what people are actually publishing, so
there SHOULDN'T be any issues, but i can't tell unless people test and
let me know. Is the Straw proposal adequate? Is KEY required (can this
be accomplied with the ID attribute)?

There are two properties that the XSLT does not yet support that were
in the Implied schema. IDENTIFIERS (which is still under debate) and
Language, which i COULD pull from xml:lang="en" attribute, but does
bibtex want "English" or "EN", or should there be a class="language"
property? or both?

-brian

--
brian suda
http://suda.co.uk
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

[uf-discuss] (hCalendar) "Outlook 2007 - time zones get marginal improvement"

[Andy Mabbett]

This may be of interest:

 

-- 
Andy Mabbett
Say "NO!" to compulsory ID Cards:  

Free Our Data:  
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: Re: [uf-discuss] GRDDL Primer and Microformats

[Brian Suda]

yes, that is the one. It was just created recently to correspond with
the release of the Primer and Use-cases. So that is why there is only
'1' message in the archives.

You could be the first to send a comment :)

-brian

On 10/5/06, Ryan King <[EMAIL PROTECTED]> wrote:


On Oct 4, 2006, at 5:13 AM, Brian Suda wrote:

> More importantly, we have just started a public mailing list for
> comments...

Is this [http://lists.w3.org/Archives/Public/public-grddl-comments/] it?

-ryan
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss




--
brian suda
http://suda.co.uk
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Species: where now

[Andy Mabbett]

In message
<[EMAIL PROTECTED]>, David
Janes <[EMAIL PROTECTED]> writes

>> What's next?
>
>Just keep working through the process: that is, if you're comfortable
>with the examples you've accumlated about how species is used on the
>web, brainstorm (which I see you've done), throw together a strawman
>uF,

Which I've done:



> then say "this should be an offical microformat proposal".

This should be an official microformat proposal!

>Then expect it to revised. It will be, over and over.

Good, I wouldn't want anything less.

>An aside:
>
>My concern with what you've done so far is that you're carving out a
>fairly large amount of namespace for a fairly niche application (yes,
>what isn't outside of its domain).

I'm not sure what you mean, here.

> "class", for example, is already
>used in vCard and current policy is one-name one-meaning.

Hence my suggestion of ""classis" or "taxo-class". I'd be just as happy
with some other such name.

-- 
Andy Mabbett
Say "NO!" to compulsory ID Cards:  

Free Our Data:  
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

RE: [uf-discuss] Live Writer and microformats

[Matt Augustine]

Windows Live Writer publishes events that have been pasted into blog posts as 
hCal whenever possible, even if the event was subsequently modified using the 
built-in event editor.  The only exceptions are for blogging platforms that 
don't allow class attributes in the HTML.  Unfortunately, there are many that 
don't, but that's another issue.

Matt Augustine
Software Development Engineer
CSA Concept Development Team
Microsoft Corporation


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Conor O'Neill
Sent: Thursday, October 05, 2006 11:41 AM
To: Ryan King
Cc: Microformats Discuss
Subject: Re: [uf-discuss] Live Writer and microformats

Ryan King wrote:
> On Oct 3, 2006, at 11:55 PM, Conor O'Neill wrote:
>
>> I'm not sure if any of you spotted this as it was not part of the
>> original release notes but Windows Live Writer now has a plug-in
>> which allows you to insert hCalendar events in your blog posts.
>
> Has anyone looked at the markup they're producing?
>
> -ryan
>
I haven't looked at the markup but Tails seems to like it (e.g.
http://eirepreneur.blogs.com/eirepreneur/2006/10/experimenting_w.html)

Conor


___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Wiki spamming

[Andy Mabbett]

In message <[EMAIL PROTECTED]>, Ryan
King <[EMAIL PROTECTED]> writes

>> I dd so again, a few hours ago.
>
>Username?

AndyMabbett

-- 
Andy Mabbett
Say "NO!" to compulsory ID Cards:  

Free Our Data:  
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] geo - accuracy of coordinates

[Andy Mabbett]

In message <[EMAIL PROTECTED]>, Ryan
King <[EMAIL PROTECTED]> writes

>I consider lat/long data as opaque metadata, which is likely to  fall
>victim to the same problems as hidden metadata.

That rather depends on who's maintaining the data, and why.

We should allow those who are capable of being-, wish to be-, or who are
compelled to be- precise, to be so.

-- 
Andy Mabbett
Say "NO!" to compulsory ID Cards:  

Free Our Data:  
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] GRDDL Primer and Microformats

[Danny Ayers]

On 05/10/06, Andy Mabbett <[EMAIL PROTECTED]> wrote:

In message <[EMAIL PROTECTED]>, Karl Dubost
<[EMAIL PROTECTED]> writes

>   http://www.w3.org/TR/grddl-primer/

If this:

GRDDL provides a relatively inexpensive set of mechanisms for
bootstrapping RDF content from uniform XML dialects in such a
way as to shift the burden of formulating RDF to transformation
algorithms written specifically for these dialects. XML
Transformation languages such as XSLT are quite versatile in
their ability to process, manipulate, and generate XML and the
use of XSLT to generate XHTML from single-purpose XML
vocabularies is historically celebrated as a powerful idiom for
separating structured content from presentation.

is the introduction to the primer, then I think some work on re-writing
in plain language is called for.


What wording do you suggest? (I'm serious - not sure how you'd make
that plainer without losing key points).

(probably better to send suggestions to
http://lists.w3.org/Archives/Public/public-grddl-comments/  even
though most if not all of the grddl-wg are subscribers to this list
:-)

Cheers,
Danny.
--

http://dannyayers.com
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: Software Projects Description Re: [uf-discuss] Potential Microformats

[Danny Ayers]

On 05/10/06, Tantek Çelik <[EMAIL PROTECTED]> wrote:


> I didn't follow microformats.org process, though I do believe some of
> the key prerequisites have been fulfilled.

This is the key.  Just taking an existing format and translating them to
class names is not enough - as the folks working on citations will tell you.


Hmm, nitpick, DOAP is more about domain model, independent of format.

I take your point about process, but then on the other hand Edd's
already done a pretty good description of the general problem [1],
existing formats [2] and modelling [3]. There are plenty of examples
in Apache [4], CodeZoo [5] and SWIK [6], there's even a continuous
stream of them at [7]. I can't help thinking any attempt at a software
project description microformat following the process to the letter
would mean significant duplication of Edd's work.

Whatever, there should be significant benefit in lowering the barrier
to publishing this kind of material  - if only to provide Technorati
with an extra search facility ;-)

Cheers,
Danny.

[1] http://www-128.ibm.com/developerworks/xml/library/x-osproj.html
[2] http://www-128.ibm.com/developerworks/xml/library/x-osproj2/
[3] http://www-128.ibm.com/developerworks/xml/library/x-osproj3/
[4] http://projects.apache.org/doap.html
[5] http://www.codezoo.com/
[6] http://swik.net/
[7] http://pingthesemanticweb.com/ (scroll down a bit)

--

http://dannyayers.com
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] hPlaylist Status?

[Lucas Gonze]

Sorry Ciaran, I have to get the work clear of my employer's lawyers first.

-Lucas

On 10/5/06, Ciaran McNulty <[EMAIL PROTECTED]> wrote:

On 10/5/06, Lucas Gonze <[EMAIL PROTECTED]> wrote:
> I'd be happy to have your input or help you tackle related problems.
> Let's talk offlist.

Lucas,

This is certainly something I'd be interested it hearing more about,
so I'd encourage you to continue progress on this in public!

Do you have some pointers to the existing research?

Thanks

-Ciaran McNulty
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss


___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] GRDDL Primer and Microformats

[Andy Mabbett]

In message <[EMAIL PROTECTED]>, Karl Dubost
<[EMAIL PROTECTED]> writes

>   http://www.w3.org/TR/grddl-primer/

If this:

GRDDL provides a relatively inexpensive set of mechanisms for
bootstrapping RDF content from uniform XML dialects in such a
way as to shift the burden of formulating RDF to transformation
algorithms written specifically for these dialects. XML
Transformation languages such as XSLT are quite versatile in
their ability to process, manipulate, and generate XML and the
use of XSLT to generate XHTML from single-purpose XML
vocabularies is historically celebrated as a powerful idiom for
separating structured content from presentation.

is the introduction to the primer, then I think some work on re-writing
in plain language is called for.

-- 
Andy Mabbett
Say "NO!" to compulsory ID Cards:  

Free Our Data:  
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Live Writer and microformats

[Conor O'Neill]

Ryan King wrote:

On Oct 3, 2006, at 11:55 PM, Conor O'Neill wrote:

I'm not sure if any of you spotted this as it was not part of the 
original release notes but Windows Live Writer now has a plug-in 
which allows you to insert hCalendar events in your blog posts.


Has anyone looked at the markup they're producing?

-ryan

I haven't looked at the markup but Tails seems to like it (e.g. 
http://eirepreneur.blogs.com/eirepreneur/2006/10/experimenting_w.html)


Conor


___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Species: where now

[David Janes]

On 10/5/06, Andy Mabbett <[EMAIL PROTECTED]> wrote:


What's next?


Just keep working through the process: that is, if you're comfortable
with the examples you've accumlated about how species is used on the
web, brainstorm (which I see you've done), throw together a strawman
uF, then say "this should be an offical microformat proposal".

Then expect it to revised. It will be, over and over.

An aside:

My concern with what you've done so far is that you're carving out a
fairly large amount of namespace for a fairly niche application (yes,
what isn't outside of its domain). "class", for example, is already
used in vCard and current policy is one-name one-meaning.

Even though there's a policy of avoiding namespacing, we ended up
doing that to a small degree in hAtom with entry-summary, entry-title
and entry-content because the "deep meaning" of those items were so
tied up into the particular problem domain.

Regards, etc...
David
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: Software Projects Description Re: [uf-discuss] Potential Microformats

[Ryan King]

On Oct 5, 2006, at 5:07 AM, Stephen Paul Weber wrote:

Wikis are awesome and a page to collect all this can't hurt  
anything :)




Is hDOAP going to be suggested into the microformats.org community?  
Has it already and I just can't find the wiki pages?  What about,  
as I've mentioned, the ability to list/markup/crawl non-open-source  
software downloads?


As you point out below, hDOAP has some problems (or, at least, does  
things differently than things are done around here). I don't see any  
reason why it couldn't be put through the process.


-ryan


hDOAP as it is seems to 'break' some rules too... like useing
alternate markup for people instead of hCard, not using
date-design-pattern.  rel=license instead of class=license would  
make sense, and the license URLs should probably be the actual,  
recognised URLs, not DOAP-only special ones (the DOAP-onlys could  
be specified as rel="license alternate" or something maybe...)   
rel=tag for actual categories, but many 'categories' don't seem to  
be real categories.


Just some thoughts :)


___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Microformats in Form Fields

[Ryan King]

On Oct 4, 2006, at 10:18 AM, Stephen Paul Weber wrote:

One thing about this would be that all current parsers would have  
to be tweaked to ignore  as the root of a data-extraction  
parseing.


Which may be a good idea anyway?

-ryan
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

[uf-discuss] Species: where now

[Andy Mabbett]

A while ago, Tantek Celik challenged me:

one thing that might help for the species discussion is if you
could cite URLs to a site or sites with millions (or even
thousands) of clearly obvious uses of "species" terminology
[...] on pages.  I'm not saying such examples don't exist, I'm
saying we need to explicitly find and cite such examples in
order to justify a microformat.

which I (with help from others, duly acknowledged) have done, both on
this mailing list and at:

  

listing well over seventy-five million (yes; over 75,000,000) examples -
and that's without bothering to list the myriad pages which use species'
common-, but not scientific-, names.

I have asked three times, since then, whether he is yet satisfied that
sufficient examples have been found, but he has not replied.

Does anyone else have any views on that question?

What's next?

-- 
Andy Mabbett
Say "NO!" to compulsory ID Cards:  

Free Our Data:  
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Examples in Wiki

[Ryan King]

On Oct 4, 2006, at 9:45 PM, Bob Jonkman wrote:

Hi all:  I've been looking at the examples on the Wiki, especially  
hCard, hCalendar and  hResume.  Many of the examples in the Wiki  
give the original format (vCard, iCalendar), then how the  
microformat should be coded, then "How this might look".  But not  
always: sometimes
the original format portion is missing; sometimes the "How this  
might look" is missing.  Sometimes the "How this might look" is  
actually marked up with microformats, which allows
those of us with microformat tools in our browsers to see the  
proper behaviour.  Most often that's not the case, tho.


Are there any style guidelines for preparing examples?  If not, any  
suggestions from the list?


I've written a good deal of those examples- there aren't any specific  
style guidelines, just try to keep things consistent.


I propose that whereever possible an example should consist of all  
three portions, with the "How this might look" portion properly  
marked up so that it triggers all the correct  behaviours in the  
browser.


I agree. Go for it! :D

-ryan
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Using Technorati to export hCal to Outlook 2003

[Ryan King]

On Oct 4, 2006, at 1:02 PM, Scott Reynen wrote:
I wonder if Technorati is having trouble parsing invalid HTML.   
Specifically, you're wrapping a span (an inline element) around a  
table (a block element), which is invalid.


Indeed. For now, we're using tidy. Unfortunately, when tidy  
encounters these situations, it has a policy of throwing away the  
outer element, which unfortunately can lead to data loss for  
microformats. I'm working on a more robust solution.


-ryan
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] GRDDL Primer and Microformats

[Ryan King]

On Oct 4, 2006, at 5:13 AM, Brian Suda wrote:

More importantly, we have just started a public mailing list for  
comments...


Is this [http://lists.w3.org/Archives/Public/public-grddl-comments/] it?

-ryan
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Live Writer and microformats

[Ryan King]

On Oct 3, 2006, at 11:55 PM, Conor O'Neill wrote:

I'm not sure if any of you spotted this as it was not part of the  
original release notes but Windows Live Writer now has a plug-in  
which allows you to insert hCalendar events in your blog posts.


Has anyone looked at the markup they're producing?

-ryan
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Wiki spamming

[Ryan King]

On Oct 3, 2006, at 3:26 PM, Andy Mabbett wrote:


In message <[EMAIL PROTECTED]>, Andy Mabbett
<[EMAIL PROTECTED]> writes

I've just reverted some porn spamming from the main page of the  
Wiki -

someone might want to remove the user concerned.


I dd so again, a few hours ago.


Username?

-ryan
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] geo - accuracy of coordinates

[Ryan King]

On Oct 3, 2006, at 1:17 AM, Andy Mabbett wrote:


In message <[EMAIL PROTECTED]>, Ryan
King <[EMAIL PROTECTED]> writes

you don't need to have lat/long to get distance. There  are plenty  
of services for translating human readable addresses into  machine  
readable values.


But with much less accuracy than lat/ long


Granted, when converting from human readable location information via  
a geocoding service (or any other data source), the information will  
be less accurate and less precise.


But, in the interest of "humans first, machines second" and building  
on existing practices, I think it makes sense to avoid introducing  
artificially precise data when the human readable information is  
sufficient and more likely to be maintained.*


-ryan

* I consider lat/long data as opaque metadata, which is likely to  
fall victim to the same problems as hidden metadata.

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Microformats in Form Fields

[Dr. Ernie Prabhakar]

Nice summary! I agree the issues are non-trivial, but I'm glad  
somebody is hashing them out...


On Oct 5, 2006, at 7:20 AM, Ciaran McNulty wrote:


Scott,

Thanks for the in-depth reply, lots of good points!  I've mulled it
over and here are a few thoughts.

On 10/5/06, Scott Reynen <[EMAIL PROTECTED]> wrote:

An empty hCard is not an hCard.
hCard requires at least a name, and
most other microformats have some basic requirements.  So I think
it's bad semantics to say there's an hCard somewhere when there's
not.


It's bad semantics, yes.  I don't know what the solution to that is,
because clearly in some cases (the editing case) what's being
presented is indeed a vcard and it's not reasonable for the
application to work out whether the form it's presenting is filled in
correctly or not and remove the vcard class if it's not.

I'd prefer to say that an hCard with missing elements *is* an hCard,
it's just invalid.  It's like saying that a web page that's missing
its  is invalid, rather than saying it's not HTML.

I'm sure we can find plenty of stuff in the wild that's marked up as
hCard that is missing a few mandatory fields, after all.


Even in the case where the hCard data is there (a pre-filled
form), it doesn't follow the current hCard parsing standards, so it's
only an hCard if we're redefining what hCard is.


Well I think that's what's being discussed.  There are lots of reasons
to want to not change hCard seeing as it's so established, but I'm not
sure about the economy of coming up with a separate 'input hCard' uF
that only differs slightly.


And I don't see the
point of that.  Parsers will need to be rewritten to make use of this
data regardless of the root class name.  Using the existing root
class names seems to only ensure that parsers will also need to be
rewritten if they want to ignore this data.


There are rewrites to parsers to accomodate new parsing rules all the
time, the a.include pattern is the latest that springs to mind.  That
said I'm not one of the people who's written a parser so I'm probably
undervaluing their time and effort somewhat and wouldn't like to write
it off as a trivial change.


That the form is used for input is obvious.  That the form is used
for input of hCards is not obvious, and I don't think adding
class="vcard" makes it obvious.


Can I ask why?  If you know a form accepts input, and it's got
class="vcard" on it then it would seem to make sense that the
[EMAIL PROTECTED]"given-name"] is expecting a first name.

I mentioned briefly that there might be the need for some sort of
convention such as tying the identifying class directly to the input
element, perhaps the vcard class would need to be tied to the form
element too?


What was the problem with Drew's
earlier suggestion of accept="text/html+vcard" to identify the
accepted microformat input format?


I don't see how @accepts is relevant in the case of prefilling forms,
to be honest.

@accept specifies a list of acceptable upload MIME types.  In a
context like this where we're submitting form values rather than file
uploads I don't think it's relevant at all (I'm happy to be corrected
if I'm reading the spec badly, the HTTP  traffic involved in a form
submission is a grey area for me).

It's probably highly relevant in a situation where we're POSTing or
PUTing a full hCard in a RESTful manner though.


I see no problem with that, but I still see no benefit in forcing
that change on all existing parsers by using the old class names to
mean new things.   Currently class="vcard" means "you can find  
contact

data within tags containing vcard property names as classes" and what
I'm seeing suggested here is changing class="vcard" to mean "you can
find contact data within tags containing vcard property names as
classes, or within the value attribute of input tags containing those
classes,


Well, currently it's "you can find contact data within tags containing
vcard property names as classes, or within those tags' @title if
they're an abbr or within their @alt if they're an img or somewhere
else on the page if you find an object.include or a.include pattern"
(I'm sure I've missed a few).

I'm not suggesting a redefinition of any of the hCard classes, that
would be too much of a headache, but the parsing rules have been
incrementally changed in the past and this would be some further
changes.


"or if those value attributes are blank and you have contact
data, this would be a good place to paste it."


An existing parser wouldn't at all need to know about this, it would
need to say, quite rightly, that the hCard wasn't valid and not try
and do stuff with it.

However, if I was writing a 'smart pasting' application, there's
already a whole rich semantic structure in hCard that would let me
immediately work out that, for instance, a certain [EMAIL PROTECTED]"text"]
is expecing my given-name.


That strikes me as a
complicated redefinition of a microformat to suit a hypothetical edge
case.


It is non-trivial, I

Re: Software Projects Description Re: [uf-discuss] Potential Microformats

[Andy Mabbett]

In message <[EMAIL PROTECTED]>, Tantek Çelik
<[EMAIL PROTECTED]> writes

>What is lacking is following the process step by step:
>
> http://microformats.org/wiki/process
>
>starting with a *-examples page, then a *-formats page (which should
>list DOAP of course), and *then* a *-brainstorming page.

Once again, you assert that something is required, when that is not
supported by the page you cite.

-- 
Andy Mabbett
Say "NO!" to compulsory ID Cards:  

Free Our Data:  
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Potential Microformats

[Andy Mabbett]

In message <[EMAIL PROTECTED]>, Karl Dubost
<[EMAIL PROTECTED]> writes

>> Someone asked me recently what other microformats might emerge, in the
>> future. Which set me thinking
>
>Be careful of the infobesity.

The *what*?

>As in I see many microformats development on this list these days
>without any questions being first

I'm sure you do, How does that apply to my post?

-- 
Andy Mabbett
Say "NO!" to compulsory ID Cards:  

Free Our Data:  
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: Software Projects Description Re: [uf-discuss] Potential Microformats

[Andy Mabbett]

In message <[EMAIL PROTECTED]>, Karl Dubost
<[EMAIL PROTECTED]> writes

>
>Le 5 oct. 06 à 20:50, Stephen Paul Weber a écrit :


>>Ultimately a search engine could search by
>> license/limitations as well as title/description, filtering out
>> shareware etc. if you don't want it, allowing it if you do, etc.
>
>I'm not sure I will bother ask each time. But let's try.
>
>* Use Case Scenarios?

How is the above not a use case?

>* Benefits for the End Users?

How is the above not a benefit for end users?

>Wrong answers:

...negative comment with no positive contribution

-- 
Andy Mabbett
Say "NO!" to compulsory ID Cards:  

Free Our Data:  
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: Software Projects Description Re: [uf-discuss] Potential Microformats

[Tantek Çelik]

On 10/5/06 9:18 AM, "Danny Ayers" <[EMAIL PROTECTED]> wrote:

> I could have sworn I mailed this or the dev list about hDOAP [1] , but
> I can't find anything substantial in the archives, probably forgot the
> cc...anyhow basically it's a way of describing software projects in
> HTML, based on DOAP [2] which could potentially become a microformat
> (according to microformats.org conventions).



> I didn't follow microformats.org process, though I do believe some of
> the key prerequisites have been fulfilled.

This is the key.  Just taking an existing format and translating them to
class names is not enough - as the folks working on citations will tell you.

> I believe what's lacking from a process point of view is mainly a few
> cycles through this list ;-)

What is lacking is following the process step by step:

 http://microformats.org/wiki/process

starting with a *-examples page, then a *-formats page (which should list
DOAP of course), and *then* a *-brainstorming page.


The reasons for this are very much inline with what Karl said:

On 10/5/06 6:51 AM, "Karl Dubost" <[EMAIL PROTECTED]> wrote:

> I'm not sure I will bother ask each time. But let's try.
> 
> * Use Case Scenarios?

E.g. *-examples


> * Benefits for the End Users?

I.e. what is the real world problem we are trying to solve?


> Wrong answers:
>  - more semantic pages
>  - to help the Web site manager with its data

Thanks Karl,

Tantek

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: Software Projects Description Re: [uf-discuss] Potential Microformats

[Danny Ayers]

I could have sworn I mailed this or the dev list about hDOAP [1] , but
I can't find anything substantial in the archives, probably forgot the
cc...anyhow basically it's a way of describing software projects in
HTML, based on DOAP [2] which could potentially become a microformat
(according to microformats.org conventions). I've done a GRDDL profile
and XSLT from DOAP to hDOAP and vice versa (though it looks like I've
broken the XSLT somewhere, will fix asap).

My original motivation was to be able to author and publish DOAP data
in XHTML, and in the process check out the viability of a) deriving a
microformat from an existing RDF vocabulary; b) the GRDDL mechanism
for interpreting XHTML as RDF. DOAP has a fairly constrained RDF/XML
syntax and transformation from DOAP to XHTML is possible, so being
able to render DOAP documents in a HTML browser is a bonus.

I didn't follow microformats.org process, though I do believe some of
the key prerequisites have been fulfilled.

On 05/10/06, Karl Dubost <[EMAIL PROTECTED]> wrote:


* Use Case Scenarios?
* Benefits for the End Users?


Edd Dumbill did an impressive amount of research for DOAP, check in
particular the goals [3] and the write-ups at developerWorks (linked
from the sidebar at [2]). He put a lot of effort into finding out what
people were already doing to describe projects, and came up with a set
of terms that he felt gave good coverage. DOAP has seen a substantial
amount of adoption, which validates Edd's approach - an approach which
I believe is generally in line with the research side of the
microformats process. Edd's paved the cowpaths, they just need a
little HTML varnish.

As Stephen noticed, what is lacking from a technical point of view is
a refactoring of various constructs to existing microformats. A XMDP
profile would also be very desirable, though this could largely be
derived from DOAP's RDF schema (as documented at [4]).

I believe what's lacking from a process point of view is mainly a few
cycles through this list ;-)

One key question would be whether to go with DOAPs coverage, or to
expand/modify/contract it. Because of Edd's prior work, my personal
opinion would be to stick to that scope, it also has the advantage of
easy interop with existing DOAP deployment.

Incidentally I've still got looking at the task description/scheduling
kind of project description on my personal to-do list, appropriately
enough starting with iCal's TODO (as suggested by Tantek).

Cheers,
Danny.

[1] http://purl.org/stuff/hdoap/profile
[2] http://usefulinc.com/doap
[3] http://usefulinc.com/doap/goals
[4] http://www-128.ibm.com/developerworks/xml/library/x-osproj3/

--

http://dannyayers.com
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Microformats in Form Fields

[Ciaran McNulty]

Scott,

Thanks for the in-depth reply, lots of good points!  I've mulled it
over and here are a few thoughts.

On 10/5/06, Scott Reynen <[EMAIL PROTECTED]> wrote:

An empty hCard is not an hCard.
hCard requires at least a name, and
most other microformats have some basic requirements.  So I think
it's bad semantics to say there's an hCard somewhere when there's
not.


It's bad semantics, yes.  I don't know what the solution to that is,
because clearly in some cases (the editing case) what's being
presented is indeed a vcard and it's not reasonable for the
application to work out whether the form it's presenting is filled in
correctly or not and remove the vcard class if it's not.

I'd prefer to say that an hCard with missing elements *is* an hCard,
it's just invalid.  It's like saying that a web page that's missing
its  is invalid, rather than saying it's not HTML.

I'm sure we can find plenty of stuff in the wild that's marked up as
hCard that is missing a few mandatory fields, after all.


Even in the case where the hCard data is there (a pre-filled
form), it doesn't follow the current hCard parsing standards, so it's
only an hCard if we're redefining what hCard is.


Well I think that's what's being discussed.  There are lots of reasons
to want to not change hCard seeing as it's so established, but I'm not
sure about the economy of coming up with a separate 'input hCard' uF
that only differs slightly.


And I don't see the
point of that.  Parsers will need to be rewritten to make use of this
data regardless of the root class name.  Using the existing root
class names seems to only ensure that parsers will also need to be
rewritten if they want to ignore this data.


There are rewrites to parsers to accomodate new parsing rules all the
time, the a.include pattern is the latest that springs to mind.  That
said I'm not one of the people who's written a parser so I'm probably
undervaluing their time and effort somewhat and wouldn't like to write
it off as a trivial change.


That the form is used for input is obvious.  That the form is used
for input of hCards is not obvious, and I don't think adding
class="vcard" makes it obvious.


Can I ask why?  If you know a form accepts input, and it's got
class="vcard" on it then it would seem to make sense that the
[EMAIL PROTECTED]"given-name"] is expecting a first name.

I mentioned briefly that there might be the need for some sort of
convention such as tying the identifying class directly to the input
element, perhaps the vcard class would need to be tied to the form
element too?


What was the problem with Drew's
earlier suggestion of accept="text/html+vcard" to identify the
accepted microformat input format?


I don't see how @accepts is relevant in the case of prefilling forms,
to be honest.

@accept specifies a list of acceptable upload MIME types.  In a
context like this where we're submitting form values rather than file
uploads I don't think it's relevant at all (I'm happy to be corrected
if I'm reading the spec badly, the HTTP  traffic involved in a form
submission is a grey area for me).

It's probably highly relevant in a situation where we're POSTing or
PUTing a full hCard in a RESTful manner though.


I see no problem with that, but I still see no benefit in forcing
that change on all existing parsers by using the old class names to
mean new things.   Currently class="vcard" means "you can find contact
data within tags containing vcard property names as classes" and what
I'm seeing suggested here is changing class="vcard" to mean "you can
find contact data within tags containing vcard property names as
classes, or within the value attribute of input tags containing those
classes,


Well, currently it's "you can find contact data within tags containing
vcard property names as classes, or within those tags' @title if
they're an abbr or within their @alt if they're an img or somewhere
else on the page if you find an object.include or a.include pattern"
(I'm sure I've missed a few).

I'm not suggesting a redefinition of any of the hCard classes, that
would be too much of a headache, but the parsing rules have been
incrementally changed in the past and this would be some further
changes.


"or if those value attributes are blank and you have contact
data, this would be a good place to paste it."


An existing parser wouldn't at all need to know about this, it would
need to say, quite rightly, that the hCard wasn't valid and not try
and do stuff with it.

However, if I was writing a 'smart pasting' application, there's
already a whole rich semantic structure in hCard that would let me
immediately work out that, for instance, a certain [EMAIL PROTECTED]"text"]
is expecing my given-name.


That strikes me as a
complicated redefinition of a microformat to suit a hypothetical edge
case.


It is non-trivial, I agree.  However the whole discussion is based on
that exact edge case.  If there's no use case for prefilling form
fields with for, for instance, a stor

Re: Software Projects Description Re: [uf-discuss] Potential Microformats

[Stephen Paul Weber]

Getting there... ;)  You'll note in my original message I said that I
was 'planning on doing research and suggesting soon'...  that was not
a real suggestion, but since a bunch of messages about existing work
came in I figured organising that a bit couldn't hurt ;)  Real-world
examples are coming.

On 10/5/06, Karl Dubost <[EMAIL PROTECTED]> wrote:


Le 5 oct. 06 à 20:50, Stephen Paul Weber a écrit :
> Definately interesting, but a microformat/semantic XHTML version would
> also be nice.  Plus, shareware/trial downloads should be able to be
> represented too.  Ultimately a search engine could search by
> license/limitations as well as title/description, filtering out
> shareware etc. if you don't want it, allowing it if you do, etc.

I'm not sure I will bother ask each time. But let's try.

* Use Case Scenarios?
* Benefits for the End Users?

Wrong answers:
   - more semantic pages
   - to help the Web site manager with its data


So what are the answers to my first two questions?

--
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 ***


___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss




--
- Stephen Paul Weber, Amateur Writer


MSN/GTalk/Jabber: [EMAIL PROTECTED]
ICQ/AIM: 103332966
NSA: [EMAIL PROTECTED]
BLOG: http://singpolyma-tech.blogspot.com/
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: Software Projects Description Re: [uf-discuss] Potential Microformats

[Karl Dubost]

Le 5 oct. 06 à 20:50, Stephen Paul Weber a écrit :

Definately interesting, but a microformat/semantic XHTML version would
also be nice.  Plus, shareware/trial downloads should be able to be
represented too.  Ultimately a search engine could search by
license/limitations as well as title/description, filtering out
shareware etc. if you don't want it, allowing it if you do, etc.


I'm not sure I will bother ask each time. But let's try.

* Use Case Scenarios?
* Benefits for the End Users?

Wrong answers:
  - more semantic pages
  - to help the Web site manager with its data


So what are the answers to my first two questions?

--
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 ***


___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Microformats in Form Fields

[Scott Reynen]

On Oct 5, 2006, at 5:17 AM, Ciaran McNulty wrote:


I agree with this.  I think indicating that a form contains an hCard
is semantically valid in and of itself, especially in the case of
presenting an hCard in a form for editing.  There's also nothing
immediately wrong with saying that an empty form is an empty hCard,
IMO.


An empty hCard is not an hCard.  hCard requires at least a name, and  
most other microformats have some basic requirements.  So I think  
it's bad semantics to say there's an hCard somewhere when there's  
not.  Even in the case where the hCard data is there (a pre-filled  
form), it doesn't follow the current hCard parsing standards, so it's  
only an hCard if we're redefining what hCard is.  And I don't see the  
point of that.  Parsers will need to be rewritten to make use of this  
data regardless of the root class name.  Using the existing root  
class names seems to only ensure that parsers will also need to be  
rewritten if they want to ignore this data.



Decoupling the semantics that say 'this accepts input' is a very good
idea.  I'm not actually sure if any new class needs to defined to say
that though - surely the semantics of FORM/INPUT elements say all of
that anyhow?


That the form is used for input is obvious.  That the form is used  
for input of hCards is not obvious, and I don't think adding  
class="vcard" makes it obvious.  What was the problem with Drew's  
earlier suggestion of accept="text/html+vcard" to identify the  
accepted microformat input format?



As you can probably gather from the above, my personal instinct would
be to expand uFs' parsing rules to explain how to deal with forms.


I see no problem with that, but I still see no benefit in forcing  
that change on all existing parsers by using the old class names to  
mean new things.  Currently class="vcard" means "you can find contact  
data within tags containing vcard property names as classes" and what  
I'm seeing suggested here is changing class="vcard" to mean "you can  
find contact data within tags containing vcard property names as  
classes, or within the value attribute of input tags containing those  
classes, or if those value attributes are blank and you have contact  
data, this would be a good place to paste it."  That strikes me as a  
complicated redefinition of a microformat to suit a hypothetical edge  
case.


Peace,
Scott
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: Software Projects Description Re: [uf-discuss] Potential Microformats

[Stephen Paul Weber]

Wikis are awesome and a page to collect all this can't hurt anything :)



Is hDOAP going to be suggested into the microformats.org community?
Has it already and I just can't find the wiki pages?  What about, as
I've mentioned, the ability to list/markup/crawl non-open-source
software downloads?

hDOAP as it is seems to 'break' some rules too... like useing
alternate markup for people instead of hCard, not using
date-design-pattern.  rel=license instead of class=license would make
sense, and the license URLs should probably be the actual, recognised
URLs, not DOAP-only special ones (the DOAP-onlys could be specified as
rel="license alternate" or something maybe...)  rel=tag for actual
categories, but many 'categories' don't seem to be real categories.

Just some thoughts :)

On 10/5/06, brian suda <[EMAIL PROTECTED]> wrote:

There has been some work done to model DOAP in XHTML. Pretty much all
the tools have been created and are ready to use.

http://dannyayers.com:88/xmlns/hdoap/profile/index.xhtml

-brian


Stephen Paul Weber wrote:
> Definately interesting, but a microformat/semantic XHTML version would
> also be nice.  Plus, shareware/trial downloads should be able to be
> represented too.  Ultimately a search engine could search by
> license/limitations as well as title/description, filtering out
> shareware etc. if you don't want it, allowing it if you do, etc.
>
> On 10/4/06, Karl Dubost <[EMAIL PROTECTED]> wrote:
>>
>> Le 5 oct. 06 à 10:08, Stephen Paul Weber a écrit :
>> > Software Downloads (license, download link, title, description,
>> > rating?)
>> > Might actually start some research and suggest this soon.
>>
>>
>> Already done. It's called DOAP
>> http://usefulinc.com/doap
>>
>>
>>
>> --
>> 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 ***
>>
>>
>> ___
>> microformats-discuss mailing list
>> microformats-discuss@microformats.org
>> http://microformats.org/mailman/listinfo/microformats-discuss
>>
>
>
> 
>
> ___
> microformats-discuss mailing list
> microformats-discuss@microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss
>

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss




--
- Stephen Paul Weber, Amateur Writer


MSN/GTalk/Jabber: [EMAIL PROTECTED]
ICQ/AIM: 103332966
NSA: [EMAIL PROTECTED]
BLOG: http://singpolyma-tech.blogspot.com/
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: Software Projects Description Re: [uf-discuss] Potential Microformats

[brian suda]

There has been some work done to model DOAP in XHTML. Pretty much all
the tools have been created and are ready to use.

http://dannyayers.com:88/xmlns/hdoap/profile/index.xhtml

-brian


Stephen Paul Weber wrote:
> Definately interesting, but a microformat/semantic XHTML version would
> also be nice.  Plus, shareware/trial downloads should be able to be
> represented too.  Ultimately a search engine could search by
> license/limitations as well as title/description, filtering out
> shareware etc. if you don't want it, allowing it if you do, etc.
>
> On 10/4/06, Karl Dubost <[EMAIL PROTECTED]> wrote:
>>
>> Le 5 oct. 06 à 10:08, Stephen Paul Weber a écrit :
>> > Software Downloads (license, download link, title, description,
>> > rating?)
>> > Might actually start some research and suggest this soon.
>>
>>
>> Already done. It's called DOAP
>> http://usefulinc.com/doap
>>
>>
>>
>> -- 
>> 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 ***
>>
>>
>> ___
>> microformats-discuss mailing list
>> microformats-discuss@microformats.org
>> http://microformats.org/mailman/listinfo/microformats-discuss
>>
>
>
> 
>
> ___
> microformats-discuss mailing list
> microformats-discuss@microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss
>   

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: Software Projects Description Re: [uf-discuss] Potential Microformats

[Stephen Paul Weber]

Definately interesting, but a microformat/semantic XHTML version would
also be nice.  Plus, shareware/trial downloads should be able to be
represented too.  Ultimately a search engine could search by
license/limitations as well as title/description, filtering out
shareware etc. if you don't want it, allowing it if you do, etc.

On 10/4/06, Karl Dubost <[EMAIL PROTECTED]> wrote:


Le 5 oct. 06 à 10:08, Stephen Paul Weber a écrit :
> Software Downloads (license, download link, title, description,
> rating?)
> Might actually start some research and suggest this soon.


Already done. It's called DOAP
http://usefulinc.com/doap



--
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 ***


___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss




--
- Stephen Paul Weber, Amateur Writer


MSN/GTalk/Jabber: [EMAIL PROTECTED]
ICQ/AIM: 103332966
NSA: [EMAIL PROTECTED]
BLOG: http://singpolyma-tech.blogspot.com/
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Microformats in Form Fields

[Ciaran McNulty]

On 10/5/06, Tom Armitage <[EMAIL PROTECTED]> wrote:

Quick question (and this isn't mean as a troll or a leading one, it's
just because right now I can't think of any): what uF could be
valuably applied to a radio button? I guessed you might have two radio
buttons saying "home address" and "work address"... but I can't see
_many_ instances where radios or checkboxes would be vastly useful
_for the uFs which exist right now_.


Your example of home address/work address is a very good one!  Another
might be an hCalendar event's free/busy time status.

Maybe [EMAIL PROTECTED]"radio" buttons weren't the best example, but I was
trying to point out that form elements' values often lie in odd places
that aren't covered by the parsing rules.

That said, I'd expect that a few additions to the uF parsing rules,
similar to those for IMG @alt and ABBR @title would cover more than
80% of the form use cases.

A similar element that wouldn't automatically parse well is SELECT.
It's fairly easy to come up with some use cases for this in forms -
date selection is the first that springs to mind.

It's also certainly possible that, for instance, my Person editing
form could constrain me to choosing their ORG from a SELECT that's
populated with organisations that are defined elsewhere.


as for class="vcard-input"? not sure. I think class="vcard input" -
adding *two* things to the form - is a better compromise, but I don't
think that's very microformatic. It's a bit like http verbs, I guess,
the difference between POST and GET at a url, except in this case we
have a vcard on inputs, and a vcard on display elements. One demands
input in a format, the other displays data with extra semantics.


I agree with this.  I think indicating that a form contains an hCard
is semantically valid in and of itself, especially in the case of
presenting an hCard in a form for editing.  There's also nothing
immediately wrong with saying that an empty form is an empty hCard,
IMO.

Decoupling the semantics that say 'this accepts input' is a very good
idea.  I'm not actually sure if any new class needs to defined to say
that though - surely the semantics of FORM/INPUT elements say all of
that anyhow?

As you can probably gather from the above, my personal instinct would
be to expand uFs' parsing rules to explain how to deal with forms.
The fact the uF consists of form elements is surely enough to allow a
'smart pasting' implementation to figure out where to place data
(although some guidance e.g. recommending that the field-identifying
classes are applied directly to the INPUT might turn out to be
necessary).

Regards,

-Ciaran McNulty
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] hPlaylist Status?

[David Janes]

"Alternates" [1]. There was some later discussion on this and I
believe Kevin Marks contributed some stuff later on.

I haven't championed this in any major way because the need for it
seems somewhat theoretical at the moment (though it's nice to have the
idea recorded in case someone needs it).

Regards, etc...
David

[1] http://microformats.org/wiki/alternates-brainstorming

On 10/5/06, Lucas Gonze <[EMAIL PROTECTED]> wrote:

On 10/4/06, Charles Iliya Krempeaux <[EMAIL PROTECTED]> wrote:
> Previously I remember there was discussion about hPlaylist.
>
> What was the result of that?  What's the status of that effort?

A couple things that I know of.
- David Janes went off and did a related minimicroformat, the name of
which slips my mind.
- I went off and did a hella lotta drafts and experiments with
alternative approaches.

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Microformats in Form Fields

[Tom Armitage]

On 05/10/06, Ciaran McNulty <[EMAIL PROTECTED]> wrote:

Elements like  that just wrap values could be parsed
normally but others like  would need to be parsed
using the @value, and I'm not sure what we'd have to do to be able to
parse, for instance, radio buttons.



Quick question (and this isn't mean as a troll or a leading one, it's
just because right now I can't think of any): what uF could be
valuably applied to a radio button? I guessed you might have two radio
buttons saying "home address" and "work address"... but I can't see
_many_ instances where radios or checkboxes would be vastly useful
_for the uFs which exist right now_.

I take everyone's points about updating parsers - I was entirely aware
that would be one outcome of that proposal.

As regarding vCard inside forms - well, that's fine. I don't think
"ignoring form as the root of data parsing" is a good idea. I think
ignoring s is more useful, because there are loads of reasons
to put "proper" uF data inside a form element.

as for class="vcard-input"? not sure. I think class="vcard input" -
adding *two* things to the form - is a better compromise, but I don't
think that's very microformatic. It's a bit like http verbs, I guess,
the difference between POST and GET at a url, except in this case we
have a vcard on inputs, and a vcard on display elements. One demands
input in a format, the other displays data with extra semantics.

I'm going to keep thinking on this, because - whilst it would require
a change in parsers - it's an interesting idea. And, the more I think
about it, the less workable putting uF classes onto name attributes
is.
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

[uf-discuss] mikroformate.org launched

[Sebastian Küpers]

hey folks,

for your information:

we launched a german metablog about microformats today on
http://mikroformate.org
we are three guys blogging about microformats for a while now and for
the reason, that we've allready pubslished over 100 articles about
microformats, we put our forces together and started this central
information point

(which of course directly links to the offical sources on
microformats.org as well)

more over there is a german wiki and mailinglist (which ryan is
allready reading, as we noticed - thx) associated with this metablog
... I think we will initiate a translation project of the official
wiki asap to get more information about microformats available on
german soon.

cheers from berlin,
sebastian
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Microformats in Form Fields

[Ciaran McNulty]

On 10/5/06, Ben Ward <[EMAIL PROTECTED]> wrote:

The first that comes to mind: If the form is pre-filled then you have
a valid vcard that could be parsed (with the addition of some form
parsing rules). Take for example an 'Edit Profile' page that contains
existing values.


That's a very good point, but it would depend on some changes to the
uF parsing rules.

Elements like  that just wrap values could be parsed
normally but others like  would need to be parsed
using the @value, and I'm not sure what we'd have to do to be able to
parse, for instance, radio buttons.

-Ciaran McNulty
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Microformats in Form Fields

[Ben Ward]

On 4 Oct 2006, at 19:37, Scott Reynen wrote:
What is the benefit of using the same root class name for forms  
accepting a microformat as we use for the published microformat?


The first that comes to mind: If the form is pre-filled then you have  
a valid vcard that could be parsed (with the addition of some form  
parsing rules). Take for example an ‘Edit Profile’ page that contains  
existing values.


Whether that falls outside 80/20 I'm not 
sure.___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] hPlaylist Status?

[Ciaran McNulty]

On 10/5/06, Lucas Gonze <[EMAIL PROTECTED]> wrote:

I'd be happy to have your input or help you tackle related problems.
Let's talk offlist.


Lucas,

This is certainly something I'd be interested it hearing more about,
so I'd encourage you to continue progress on this in public!

Do you have some pointers to the existing research?

Thanks

-Ciaran McNulty
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss