Re: [uf-discuss] species microformats OpenSearch

2006-12-07 Thread Andy Mabbett
In message [EMAIL PROTECTED], Shorthouse, David
[EMAIL PROTECTED] writes

ou wrote (END)
[David Shorthouse wrote:]

Please note my earlier comment on quoting formats.

And this is exactly what uBio already provides with their LinkIT tool
(http://names.mbl.edu/tools/linkit.php) and essentially nullifies the
need for microformat mark-up.

I fail to see how you can claim that the uBio nullifies the need for
microformat markup; when it provides virtually none of the functionally
provided by microformats. I refer you again to the initial proposal:

Imagine viewing a web page with a reference to a species - and
being able to use an add-on to you browser to be taken directly
to information about that species, on, say, Wikipedia, or
Wikispecies, or Google Images, or another site, such as in an
academic database, of your choosing.

Your software would automatically know to search site A if the
scientific name referred to a moth, site B for a bird, and site
C for a plant - and you could set your preferences as to which
sites those were to be, and in which order two or more were to
be searched (e.g. for moths, try UK Moths
(http://ukmoths.org.uk/) first, if not found try The Global
Lepidoptera Names Index
(http://www.nhm.ac.uk/research-curation/projects/lepindex/index.h
tml)).

Or supposing someone writes a long, chronologically-ordered web
page about all the birds, insects, mammals and plants they saw
on a wildlife safari, with lots of prose description about the
paces where they saw them and the people they were with, but you
want to extract a list of species, sorted into alphabetical
order within taxonomic class (birds first, then insects then...)
or in taxonomic order.

Those are just two of the things a species microformat might
do for you.

Please explain how uBio does those things; taking:

http://www.westmidlandbirdclub.com/ladywalk/latest
and:
http://en.wikipedia.org/wiki/Black-tailed_godwit

as test cases.

I previously argued with you on my forum (http://canadianarachnology.dy
ndns.org/forum/viewtopic.php?t=118) this point and you provided no
compelling argument for me to spend effort marking up my pages with
microformat.

I wasn't aware that you were the person with whom I'd had that
discussion, some months ago. Nor was I aware that the discussion had
continued, since your forum does not appear to send e-mail notices of
further replies (leastways , I received none). I note also that Charles
Roper, my co-proponent of this proposal, subsequently gave you a lengthy
reply.

A glib reply was not convincing.

Nor was one given. My reply may have been short, but it was accurate and
pertinent.

I argue that using such generic microformats as species or taxon
provides no valuable information  is no better than having binomen.

And I have already shown you how it does; nor is having binomen a bad
thing.

 In fact, I would argue that using such mark-up may dangerously provide
mis-information if not intelligently implemented.

Unfounded scare-mongering.

 Take for example a politically-charged scenario where a genus receives
revision, species renamed, and consequently erroneously struck from a
red-list merely because the name cannot then be found via a
hypothetical web page aggregator that uses microformats.

Such bizarrely hypothetical speculation - not to mention the political
slant - is way outside the scope of microformats.

I have no fundamental problem with microformats; I believe there is a
responsibility here to do it right and not simply provide something
because something is better than nothing.

So do I. However, you don't appear to see, or to appreciate, what the
it is that we're trying to do.

-- 
Andy Mabbett
Say NO! to compulsory ID Cards:  http://www.no2id.net/

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


Re: [uf-discuss] New Microformats Cheatsheet PDF

2006-12-07 Thread brian suda
Ryan Cannon wrote:
 ... I till prefer ?, + and *, as I have to continually move my
 eye between the two charts in order to remember which is which. I would
 remember ?, + and *.
--- while i agree, i am trying to strike a happy balance between those
of use who KNOW the REGEX syntax and those who don't have a Computer
Science degree. The '?' tends to look like maybe, we don't know or
some sort of image/character is missing. I don't claim to be a designer,
but something with the look and feel of the '?' doesn't quite sit right
with my eye at the moment - but i'll have a play around and see if i
can't work something out.
 Perhaps instead of the table on the right, which duplicates the other
 information on the page, you could  have a similar column to the right
 of each class name, with either and symbols for occurrence:
--- the tricky thing is that you still need to know what that
cardinality is with respect to a given format. URL in hCard is 0-*,
whereas URL in hCalendar is 0-1.
 Regardless, moving the class name requirements closer to the structure
 list will decrease the amount of time a reader takes to look up the
 the information.
--- i agree, originally the only way to tell the cardinality was to
typography of the text, bold, italics, bold-italics, or normal. The
characters on the right were a recent addition - and i couldn't just
bold/italicize those words because the cardinality depends on the
specific microformat.  I know on the wiki there has been work to have
typography and to add the 'indicator' characters. This is something that
might make it into the next cheatsheet, or again i am trying to strike a
happy balance between the folks who know REGEX and those who barely know
HTML. saying class=vcard? might get literally cut-and-pasted into
their HTML.

One of the things i had considered was to allow the  master InDesign
File to be downloaded as well, so people could re-mix the information
in  any way they wanted... i don't think i'm quite ready for that until
the data itself is more stable and error free. At that point, folks can
do what they like and know their version is pretty reliable.

Thanks for all the suggestions,
-brian

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


RE: [uf-discuss] Comments from IBM/Lotus rep about Microformats

2006-12-07 Thread Costello, Roger L.
Mike Schinkel wrote:

 The core problem is no strategies have been adopted to avoid naming
 collisions, and to avoid having the whole concept self destruct from
it's
 own weight of complexity. People who want to contribute but can't
because
 the centralized Microformat community is not interested will go off
and
 create their own and names start clashing, we'll just be left with
one big
 mess. 

 Most of the Microformat community seems to want to keep Microformats
a tight
 knit club focused on a small number of use cases that reviews and
approves
 everything, declining things they don't like, but I think there is
really an
 obligation to the Internet at large to address how to scale the
process
 because Microformats squat on a scare resource (names in classes.) 

Mike, you've raised some excellent concerns.  It fundamentally boils
down to an issue of interoperability.  If the Microformat's community
splinters and, say, multiple versions of hCard are created then we
immediately have an interoperability problem.  

Tantek calls namespaces an enabler of stovepipes. 

I hope that Tantek will weigh in on this issue.  In the past he has
addressed this issue, but a regular repeat is very worthwhile I
believe.  It strikes at the very heart of the Microformat's philosophy,
and the very heart of achieving interoperability on the Web.

/Roger

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


Re: [uf-discuss] hrecipe examples

2006-12-07 Thread Ryan King

On Dec 7, 2006, at 9:47 AM, Ted Drake wrote:


Hi All

Are there any examples of an hrecipe encoded page?
I realize it is still in development. I'd like to see if there has  
been any

progress made and/or something to go by.

I've looked at the twiki and there seems to be examples of recipe  
pages, but

I don't see any hrecipe encoding on them.


There is no hRecipe. There is research into a recipe microformat, but  
there is no microformat (yet?).


-ryan
--
Ryan King
[EMAIL PROTECTED]



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


Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats

2006-12-07 Thread Ryan King

On Dec 6, 2006, at 5:45 AM, Bruce D'Arcus wrote:

On 12/5/06, Scott Reynen [EMAIL PROTECTED] wrote:

...


In HTML or JSON, new formats need new parsers, which must be written
by someone.


Exactly. The point is if you have a generic model you have a  
generic parser.



Elias is coming from an RDF background, and microformats
simply aren't RDF, and they never will be.  And that's a good thing.
If what you want is RDF, just use RDF.


The issue isn't really microformats vs. RDF (except as RDF provides a
model), but microformats vs. RDFa.

Both microformats and RDFa are addressing the exact same use cases and
requirements (augmenting visible content with structured data).

RDFa includes namespacing, the lack of which is already a problem in
microformats (witness hCite and the serious awkwardness that title
will be indicate using fn), and which will grow over time as more and
more people want to mark up their content.

Moreover, the need to write dedicate code for each new microformat
will also present serious scalability problems.


Yes, in order to parse and consume microformats, you'll have to have  
code that knows about those formats.


The RDF dream of having a generic parser and model has yet to win on  
the open web. I'm more than happy to let the market decide whether  
it's more value to have formats that are easy to publish, or those  
that are easy to parse (I'm sure you can guess which side I'll take).



Finally, that there's no model at the heart of microformats with clear
extension rules means that the vaunted social process here is a mess.
It's all centralized, and people get frustrated when their pet
property isn't included because they know what that means: the tools
written for the blessed microformats won't see them.


I agree that there are cases where we can be more organized and I'm  
more than willing to implement new tools or processes to do this.


Also, I'm not sure how 'people not getting their pet properties' is a  
problem specific to microformats.


With other technologies, like XML, the person who didn't get their  
pet property included in a given namespace could create their own  
namespace and advocate that people make use of it. Still, I don't  
believe that it changes the reality that tools won't know what to do  
with it unless *someone* writes some code. I don't think the  
situation is any worse in microformats, and it may in fact be better.  
If your 'pet property' doesn't make it into a microformat, you can  
still publish it and advocate that others use it. If consumers of  
said microformat decide that the data is valuable, they'll parse it  
and if enough people do this, then it'll get added to the microformat.


-ryan

--
Ryan King
[EMAIL PROTECTED]



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


Re: [uf-discuss] Issue with fn org when also organization unit

2006-12-07 Thread David Janes

I Concur.

On 12/7/06, Ryan King [EMAIL PROTECTED] wrote:

Mine too. I think that the org-fn rule should state something to the
effect that if organization-name is given, then if fn and
organization-name match, then the hcard is an organization hcard.

I've added this as an issue on http://microformats.org/wiki/hcard-issues

-ryan


On Nov 25, 2006, at 12:52 PM, David Janes wrote:

 This would be my preferred solution, but it doesn't conform to the Org
 Contact Info rule [1].

 Regards, etc...

 [1] http://microformats.org/wiki/hcard#Organization_Contact_Info

 On 11/25/06, Chris Messina [EMAIL PROTECTED] wrote:
 On 11/25/06, David Janes [EMAIL PROTECTED] wrote:

  To make it an organization hCard, I need somehow to have org == fn,
  while still independently expressing the -unit. Something like this
  ...
 
  span class=org fn organization-nameABC, Inc./span,
  span class=org
   span class=organization-unitNorth American Division/span
  /span
 
  ... which strikes me as inadequate. Thoughts?

 Why not:

 span class=org
   span class=fn organization-nameABC, Inc./span,
   span class=organization-unitNorth American Division/span
 /span

 I dunno if that's legit, but just another class ordering.

 Chris

 --
 Chris Messina
 Citizen Provocateur 
   Open Source Ambassador-at-Large
 Work: http://citizenagency.com
 Blog: http://factoryjoe.com/blog
 Cell: 412 225-1051
 Skype: factoryjoe
 This email is:   [ ] bloggable[X] ask first   [ ] private
 ___
 microformats-discuss mailing list
 microformats-discuss@microformats.org
 http://microformats.org/mailman/listinfo/microformats-discuss



 --
 David Janes
 Founder, BlogMatrix
 http://www.blogmatrix.com
 http://www.onamine.com
 http://blogmatrix.blogmatrix.com
 ___
 microformats-discuss mailing list
 microformats-discuss@microformats.org
 http://microformats.org/mailman/listinfo/microformats-discuss

--
Ryan King
[EMAIL PROTECTED]



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





--
David Janes
Founder, BlogMatrix
http://www.blogmatrix.com
http://www.onamine.com
http://blogmatrix.blogmatrix.com
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss


RE: [uf-discuss] Comments from IBM/Lotus rep about Microformats

2006-12-07 Thread Mike Schinkel
S. Sriram wrote:
 This is not a scarce resource, people can 
 (and are) naming classes as they choose.
 Any constraint happens at the parsing stage, 
 since microformat-aware parsers look for 
 specific class names etc. (see below) 

If it is not a scarce resource, please tell me what would happen if I
decided to start marking up documents, as an example, using the class
directory and license, for purposes other than rel-directory and
re-license?  How could my markup and those Microformats co-exist in the same
HTML document?

-Mike Schinkel
http://www.mikeschinkel.com/blogs/
http://www.welldesignedurls.org/


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


Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats

2006-12-07 Thread Bruce D'Arcus

On 12/7/06, Ryan King [EMAIL PROTECTED] wrote:

...


The RDF dream of having a generic parser and model has yet to win on
the open web. I'm more than happy to let the market decide whether
it's more value to have formats that are easy to publish, or those
that are easy to parse (I'm sure you can guess which side I'll take).


Why does this need to be an either/or choice?  Why must
ease-of-authoring trade-off generality here?

...


Also, I'm not sure how 'people not getting their pet properties' is a
problem specific to microformats.


True. It doesn't mean it has to repeat the same mistake though. I
would certainly hope the HTML 5 effort would be open minded about
learning from all of the efforts in this space.

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


Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats

2006-12-07 Thread Ryan King

On Dec 7, 2006, at 12:29 PM, Bruce D'Arcus wrote:

On 12/7/06, Ryan King [EMAIL PROTECTED] wrote:

...


The RDF dream of having a generic parser and model has yet to win on
the open web. I'm more than happy to let the market decide whether
it's more value to have formats that are easy to publish, or those
that are easy to parse (I'm sure you can guess which side I'll take).


Why does this need to be an either/or choice?  Why must
ease-of-authoring trade-off generality here?


I'm not saying that it has to be, but that it appears to be so in  
practice. I've found that general purpose data formats are harder to  
author than specific ones. For example, HTML is more work than  
Markdown for the kinds of writing that Markdown allows. I tend to use  
Markdown pretty often because of that.



...


Also, I'm not sure how 'people not getting their pet properties' is a
problem specific to microformats.


True. It doesn't mean it has to repeat the same mistake though. I
would certainly hope the HTML 5 effort would be open minded about
learning from all of the efforts in this space.


HTML 5 has profile URIs and the specification is much more clear as  
to how they are to be used (thanks to Tantek bugging Hixie about  
that). I think HTML 5's current extension methods (profiles, rel and  
class) are sufficient.


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


Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats

2006-12-07 Thread S. Sriram

From: Ryan King [EMAIL PROTECTED]

On Dec 5, 2006, at 8:48 AM, S. Sriram wrote:

From: Mike Schinkel [EMAIL PROTECTED]

http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2006- 
December/00

8462.html

I wonder if his issues can be addressed?


How about a distributed parser-discovery service


What's wrong with GRDDL [http://www.w3.org/2004/01/rdxh/spec]?



Nothing. Except that in this case it  introduces yet another parsing burden 
on the

browser/renderer
i.e. from rdf/xml to JSON or other renderable format.

S. Sriram 


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


Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats

2006-12-07 Thread S. Sriram

From: Mike Schinkel [EMAIL PROTECTED]

S. Sriram wrote:

This is not a scarce resource, people can
(and are) naming classes as they choose.
Any constraint happens at the parsing stage,
since microformat-aware parsers look for
specific class names etc. (see below)


If it is not a scarce resource, please tell me what would happen if I
decided to start marking up documents, as an example, using the class
directory and license, for purposes other than rel-directory and
re-license?  How could my markup and those Microformats co-exist in the 
same

HTML document?



They would simply co-exist. Period.

Hypothetically, say the author uses rel-license
for some internal markup and has unwittingly cut/pasted in a
uf-snippet containing a rel-license tag. The consumer of this
microformat will now be presented with spurious/confusing
data.

How different is this from a web page (today) that contains a rel-license
entry which was not intended to be a microformat in the first place.
Not much. This too will lead to a spurious/confusing interpretation if 
consumed

as a microformat. But, is that not what ALL current usages of
this are and is that not how microformats even chooses these
terms by sifting through the way people actually use them.

In other words, just finding a markup on a page that resembles
a microformat 'does not necessarily mean that is is one'. This
is true today. The burden of interpretation is on the consumer
not the author.

Now, if the argument is that authors are 'constrained' in their
class naming freedom, and have to avoid the usage of rel-license
altogether (unless used as specifically noted by microformats.org)
since microformats have 'squatted' on it. The response is NO, you
are not constrained, as the burden of interpretation falls on the
consumer of the microformat and not its author.

As for multiple namespaces and a bureaucracy to govern that, it is
highly unlikely. What is more likely is a white/blacklisting mechanism
if spammers etc. begin wide use of it, much the same way blogs are
being white/blacklisted.

S. Sriram 


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


Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats

2006-12-07 Thread Scott Reynen

On Dec 7, 2006, at 2:28 PM, Mike Schinkel wrote:


If it is not a scarce resource, please tell me what would happen if I
decided to start marking up documents, as an example, using the class
directory and license, for purposes other than rel-directory and
re-license?


The classes wouldn't cause any problems, but if you mean the rel  
attribute, that would cause parsers to do confusing things with the  
data.  Then people would start complaining to the parser developers,  
and the parser developers would start ignoring those attributes  
unless they were accompanied by the appropriate profile headers.  And  
then publishers would start using the appropriate profile headers to  
disambiguate their microformats.  None of that is happening now  
because there's no (or very little) ambiguity now, so there's little  
incentive to pre-emptively disambiguate.  But if ambiguity ever  
becomes a real problem, there's a solution in profile headers ready  
to be used.


The next question I expect is: what if you want to use both the  
microformats.org rel-license and your own conflicting rel-license in  
the same document?  Well, you can't.  Just like in natural language,  
if you want to start using symbols with meanings that conflict with  
the established standard, you need to be prepared to establish a new  
standard meaning.  And the usefulness of your new meaning, rather  
than some central authority, will determine whether or not people use  
it in place of the alternative meaning.


Peace,
Scott

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


Re: [uf-discuss] species microformats OpenSearch

2006-12-07 Thread Andy Mabbett
In message [EMAIL PROTECTED], Shorthouse, David
[EMAIL PROTECTED] writes

Please note my earlier comment on quoting formats.
[David Shorthouse wrote:]
Sorry, you'll just have to tolerate it. Until Microsoft updates Office
2007 to deal with this possible bug with text email, I refuse to install
3rd party plug-ins.

Other people using the same software that you use seem to manage; and
nobody has suggested you use a 3rd party plug in.

Imagine viewing a web page with a reference to a species - and
being able to use an add-on to you browser to be taken
directly
to information about that species, on, say, Wikipedia, or
Wikispecies, or Google Images, or another site, such as in an
academic database, of your choosing.

I wrote the above, not you.

[David Shorthouse wrote:]
The key word here is imagine. Please show me where a species
microformat mark-up does this.

That's a ridiculous request - you've already been told, more than once,
that this is a proposal, not a finished product.

 uBio's LinkIT tool recognizes all the binomen on a
submitted webpage

... a web page which must be *manually* submitted...

and creates links to recognized scientific bodies of
work where one can be assured that the name is valid, or to receive
the species' current nomenclature. It would be trivial for them to also
produce a species list from such outputs or to permit a user to select
what
site they would like to be redirected to for more information. This,
without any microformats.

...and again that's hypothetical. Or are there any active proposals to
do that?

Your software would automatically know to search site A if the
scientific name referred to a moth, site B for a bird, and
site
C for a plant

[David Shorthouse wrote:]
And what does a microformat browser plug-in do when it comes across a
species name, _Agathis montana_ if the individual who created the
mark-up did not indicate that this species is a wasp and not a conifer
(they
share the same name, which is perfectly acceptable because they are in
different Kingdoms).

*If* they did not do so, then the result could be, for instance:


http://names.ubio.org/browser/search.php?names=onauthors=onsci=onvern=onsearch_all=Agathis+montana

(aka http://tinyurl.com/voofq )

or, if the user so desires:

http://www.google.co.uk/search?q=%22Agathis+montana%22

Why is that a problem?

The issue of the same name being used for two species, in different
kingdoms, has already been addressed, in previous discussion, to which
you have been referred, but which you appear not to have read.

[David Shorthouse wrote:]
Your copy  pasted post to the forum I maintain was no better than
spam.

That's a lie, and a libel (evidenced, not least by your previous
involvement in discussion in response to that post). Otherwise, feel
free to report me to my ISP.

 Had
you took the time to read through the registration process, you would
have
noticed that email replies are not provided.

Indeed - note that I said that your forum did not do so, not that I
didn't know that it did not do so.

And I have already shown you how it does; nor is having binomen a bad
thing.

[David Shorthouse wrote:]
Sorry, you have not.

I was replying to your assertion, which you have not quoted, that :

I argue that using such generic microformats as
species or taxon provides no valuable
information  is no better than having binomen.

and indeed I have, when I pointed out that your example:

h1span class=speciesTheridion agrifoliae/span Levi,
1957/h1

conveys more, and more semantic, information than simply:

h1Theridion agrifoliae Levi, 1957/h1

 Take for example a politically-charged scenario where a genus
receives
revision, species renamed, and consequently erroneously struck from a
red-list merely because the name cannot then be found via a
hypothetical web page aggregator that uses microformats.

Such bizarrely hypothetical speculation - not to mention the political
slant - is way outside the scope of microformats.

[David Shorthouse wrote:]
And why should it be?

You appear to have a very poor grasp of what microformats are, and what
they are for. Once again, I refer you to the introductory material
recommended to you by Charles Roper.

Are not microformats a step toward the semantic web?

Very much so.

Until you can demonstrate how microformats for taxa are linked to works
like Species2000  there is
an obvious attempt to accommodate the very dynamic and often problematic
nature of binomen (e.g. with ties to LSIDs), I won't mark-up any of the
species pages I host

The option to do those things *is* already demonstrated on the pages to
which you have previously been referred; there is no intention to
mandate such links.

You have a very specific need (or, rather, wish) which the proposal
caters for completely; it does not cater for your apparent wish to
impose your methodology on others.


[uf-discuss] Mars Moon news stories

2006-12-07 Thread Andy Mabbett

Both Mars and the Moon have been in the news this week:

  *  water on mars:

http://news.bbc.co.uk/1/hi/sci/tech/6214834.stm

http://mars.jpl.nasa.gov/mgs/newsroom/20061206b.html

  *  Mars landers photographed:

http://news.bbc.co.uk/1/hi/sci/tech/6211870.stm


http://marsprogram.jpl.nasa.gov/mro/newsroom/pressreleases/20061204a.html

http://hiroc.lpl.arizona.edu/images/PSP/PSP_001521_2025/
The complete image is centered at 22.3 degrees
latitude, 312.1 degrees East longitude.

  *  Moon base proposed:

http://news.bbc.co.uk/1/hi/sci/tech/6210154.stm

http://www.nasa.gov/home/hqnews/2006/dec/HQ_06361_ESMD_Lunar_Architecture.html

and in each case specific locations are referred to.

Where are we, with the 'Mars':

http://microformats.org/wiki/mars

and 'Luna':

http://microformats.org/wiki/luna

proposals?

-- 
Andy Mabbett
Say NO! to compulsory ID Cards:  http://www.no2id.net/

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


RE: RE: [uf-discuss] Comments from IBM/Lotus rep about Microformats

2006-12-07 Thread Mike Schinkel
 --- these values are not reserved across all of HTML. We 
 have a mechanism to prevent this, it is called Profile URIs, 
 if a parser comes across class=vcard then the best way to 
 determine if this is a random CSS Style or a semantic value 
 is to see if there is a Profile URI that matched the XMDP of hCard.

Are you referring to this?
http://www.w3.org/TR/html401/struct/global.html#profiles

Is a Profile URI a well-known URI where I have to find semantics elsewhere
or if not what format is returned by the URI? (just trying to understand)

How can I disambiguate when two Microformats collide?  Let me give a
concrete example (one I will be working on in the future):

Looking at ADR, here is an example:

div class=adr
 div class=street-address665 3rd St./div
 div class=extended-addressSuite 207/div
 span class=localitySan Francisco/span,
 span class=regionCA/span
 span class=postal-code94107/span
 div class=country-nameU.S.A./div
/div

Now let's say I want to use something called RegionData where Regions are
heirarchical:

div class=region-data
 div class=region street title=child-of-city
665 3rd St.; Suite 207
 /div
 span class=region city title=child-of-stateSan Francisco/span,
 span class=region state title=child-of-countryCA/span
 span class=post-code94107/span
 div class=region country title=child-of-continentU.S.A./div
/div

Now, someone needs to use both:

div class=region-data vcard
 div class=region street title=child-of-city
div class=street-address665 3rd St./div
 div class=extended-addressSuite 207/div
 /div
 span class=region city locality title=child-of-stateSan
Francisco/span,
 span class=region state region  title=child-of-countryCA/span

 span class=post-code postal-code94107/span
 div class=region country country-name
title=child-of-continentU.S.A./div
/div

How do I disambiguate between region-data's region and vcard's region?
Assume I created my RegionData with no knowledge that vcard existed, because
unless there is a central clearing house to avoid name clashes, two
different groups will end up creating conflicting microformats with clashing
names.

 It is also only a hypothetical issue, so until this becomes a 
 real issue, we're not going to worry too much about it, but 
 we do have a system that solves this problem. So we aren't 
 squatting on any values.

Hypothetical issues sometimes have a way of biting people in the ass,
using a phrase Mark Baker recently said on the REST-discuss forum on another
topic. :)
However, this is not a hypothetical issue. A project I'm working on that I'm
not willing to go public with yet will make heavy use of microformats-like
markup, and I've already seen a lot of potential for collision such as the
one above, which is an example of a planned use.

But maybe Profile URIs can solve this.  Can you please explain how, using my
example?

-Mike Schinkel
http://www.mikeschinkel.com/blogs/
http://www.welldesignedurls.org/


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


RE: [uf-discuss] Comments from IBM/Lotus rep about Microformats

2006-12-07 Thread Mike Schinkel
S. Sriram wrote:
 They would simply co-exist. Period

My only response to your comments is that I strongly disagree with you, but
as you appears you have a similar conviction it would be a waste of time to
debate it further.  

-Mike Schinkel
http://www.mikeschinkel.com/blogs/
http://www.welldesignedurls.org/


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


RE: Re: RE: [uf-discuss] [citation] url field

2006-12-07 Thread Mike Schinkel
Ironically, this sounds like another real-world (i.e. not hypothetical)
example of the need to provide a way to differentiate microformats.

-Mike Schinkel
http://www.mikeschinkel.com/blogs/
http://www.welldesignedurls.org/



 -Original Message-
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] On 
 Behalf Of Michael McCracken
 Sent: Thursday, December 07, 2006 6:05 PM
 To: Microformats Discuss
 Subject: Re: Re: RE: [uf-discuss] [citation] url field
 
 This seems to have been buried - so again, to anyone 
 interested in hCite:
 
 I want to define a new field URL to denote an http URL that 
 points to the location of a copy of the cited work.
 
 URIs that encode an identifier of the work can be combined 
 with this field, but do not need to be.
 
 I understand that the name URL may overlap a bit with URI, 
 and something like downloadlink, etc. might be more direct, 
 but I argue that URL is the better choice because it is the 
 most common name already in use in our examples from the web.
 
 Can we discuss this revised version of the proposal (or just 
 vote on it?)
 
 Thanks,
 -mike

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


differentiating microformats (was Re: RE: Re: RE: [uf-discuss] [citation] url field )

2006-12-07 Thread Michael McCracken

Mike, can you explain what you mean in the context of the citation format?

I haven't been following many of the other threads on this list this
week, so I don't know what you're referring to.

Thanks!
-mike

On 12/7/06, Mike Schinkel [EMAIL PROTECTED] wrote:

Ironically, this sounds like another real-world (i.e. not hypothetical)
example of the need to provide a way to differentiate microformats.

-Mike Schinkel
http://www.mikeschinkel.com/blogs/
http://www.welldesignedurls.org/



 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] On
 Behalf Of Michael McCracken
 Sent: Thursday, December 07, 2006 6:05 PM
 To: Microformats Discuss
 Subject: Re: Re: RE: [uf-discuss] [citation] url field

 This seems to have been buried - so again, to anyone
 interested in hCite:

 I want to define a new field URL to denote an http URL that
 points to the location of a copy of the cited work.

 URIs that encode an identifier of the work can be combined
 with this field, but do not need to be.

 I understand that the name URL may overlap a bit with URI,
 and something like downloadlink, etc. might be more direct,
 but I argue that URL is the better choice because it is the
 most common name already in use in our examples from the web.

 Can we discuss this revised version of the proposal (or just
 vote on it?)

 Thanks,
 -mike

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




--
Michael McCracken
UCSD CSE PhD Candidate
research: http://www.cse.ucsd.edu/~mmccrack/
misc: http://michael-mccracken.net/wp/
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss


Re: [uf-discuss] species microformats OpenSearch

2006-12-07 Thread Andy Mabbett
In message [EMAIL PROTECTED], Shorthouse, David
[EMAIL PROTECTED] writes

 my forum (http://canadianarachnology.dyndns.org/forum/viewtopic.php?t=
118)

It appears that Davis has now wiped the discussion of microformats from
the forum on his website!

-- 
Andy Mabbett
Say NO! to compulsory ID Cards:  http://www.no2id.net/

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


Re: [uf-discuss] species microformats OpenSearch

2006-12-07 Thread Andy Mabbett
In message [EMAIL PROTECTED], Andy Mabbett
[EMAIL PROTECTED] writes

In message [EMAIL PROTECTED], Shorthouse, David
[EMAIL PROTECTED] writes

 my forum (http://canadianarachnology.dyndns.org/forum/viewtopic.php?t=
118)

It appears that
David
 has now wiped the discussion of microformats from the forum on his
website!

It's cached here:

http://209.85.135.104/search?q=cache:ao83KPzUMGIJ:canadianarachnology.dyndns.org/forum/viewtopic.php%3Ft%3D118%26sid%3D711c2796371cee4f6a4c12be
0577d4df+microformats+site:http://canadianarachnology.dyndns.org/forum/hl=engl=ukct=clnkcd=1


(aka http://tinyurl.com/y6wlsw )

and I gave a copy saved should anyone need it once that's flushed.

-- 
Andy Mabbett
Say NO! to compulsory ID Cards:  http://www.no2id.net/

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


[uf-discuss] species microformats: a penultimate reprise

2006-12-07 Thread Shorthouse, David
Andy et al.,

I temporarily subscribed to this listserv once again to:

1) apologize for allowing my emotions get in the way of what can be a
fantastic solution to a very difficult problem and,
2) offer advice to take your proposed species microformats to the next level
of resilience in the face of taxonomic uncertainties.

Apologize to subscribers of this listserv that the repartee Andy and I have
been locked in has done little to realize your ultimate goal.

Some background about myself:

   I am a Ph.D. student working on spider biodiversity and systematics. As
an out-of-pocket initiative, I developed The Nearctic Spider Database and
associated websites including a forum, which is devoted to spider-related
research and is used by school children, educators, and researchers.
Curators and collectors throughout North America contribute to the database
and I also host peer-reviewed species pages. I am one of the first in this
field to embrace Web 2.0 as a means to coordinate much of the input and
output functions (e.g. Google Maps, Rico LiveGrid, etc.).

#1

  I welcome all manner of simplifying and diversifying web resources.
The Semantic Web, though at a very distant spot on the horizon, provides an
interesting direction to work toward. OpenSearch has some promise and I have
adopted that. I also expect GUIDs in the form of LSIDs to contribute in a
dramatic fashion to the aggregation of taxonomic resources in a rigorous
manner, but there is as yet little work done on the very difficult problem
of developing and maintaining name resolution functionality (i.e. the
synonymic to current nomenclatural mappings, though triple stores, RDF, and
other similar schema have some promise). I hope proponents of microformats
can sit at these tables. The current problem with the millions of species
pages in existence is that there are very few schemes governing their
structure and yet there is an opportunity here to do something remarkable
because all biological names naturally have structure. But, there is a
responsibility here to do it right. Organizations like the Taxonomic
Databases Working Group (TDWG) have participated in realizing the sorts of
things biologists dream about. Is there a TDWG participant here to help
species microformats be recognized and adopted?
  So, I apologize for directing a line of questioning that in a number
of instances stepped beyond the goals of species microformats. I hope you
appreciate the fact that my goals are much the same as yours. I am well
familiar with your proposal since it was first brought to my attention on
the forum I maintain. However, I would have appreciated being contacted
directly about it rather than seeing it in an arachnologists' forum. Species
microformats have nothing directly to do with spider research and
identification in their present level of acceptance and adoption. They are
at this stage a web developer's tool with future client possibilities. Andy,
because our discussion had degraded to a level that would offend the school
children and others who use the Nearctic Arachnologists' Forum, I did indeed
wipe out the thread. However, if I receive a similar public apology from
you, I will re-enable your account in the forum and will welcome your
participation in arachnology research and appreciation.

#2

Now, for those of you who have slogged through the above waiting for
something useful to microformat development, I have these things to write.

First, I urge you to be patient and to recognize the fact that many people,
especially those who are involved in developing biological resources on the
web, just won't get it. I am an exception. I have read through your
species microformat proposal and fully understand it. I was evidently out of
line by playing devil's advocate and forcing you to think outside the box.

I also urge you to participate in organizations like TDWG and bring your
arguments to the table  use language and patience that systematists 
biodiversity database managers will appreciate.

In the face of the mess taxonomy can be at times, it would be worth thinking
about GUIDs like LSIDs for use in microformats for species. uBio is but one
provider of LSIDs. There are at least a half dozen other providers and many
more are in the works.

I have participated in the upcoming GBIF portal development, an initiative
in the works called SpeciesBase, which if realized will be what GBIF is for
primary collections data, but for species pages, and will be participating
in the Entomological Collections Network where a lot of work is devoted to
producing web-based resources for collections data. So, you absolutely must
be more congenial to encourage the adoption and ultimate success of your
initiative. There is simply no other way for your proposal to succeed.

Cheers,

David P. Shorthouse


___
microformats-discuss mailing list
microformats-discuss@microformats.org

Re: [uf-discuss] species microformats: a penultimate reprise

2006-12-07 Thread Scott Reynen

On Dec 7, 2006, at 9:08 PM, Shorthouse, David wrote:

In the face of the mess taxonomy can be at times, it would be worth  
thinking
about GUIDs like LSIDs for use in microformats for species. uBio is  
but one
provider of LSIDs. There are at least a half dozen other providers  
and many

more are in the works.


I appreciate your attempts to offer constructive feedback.  I hope  
this community will prove more receptive to such feedback in the  
future, even - perhaps especially - when it is disagreeable.


If you know of any examples of such GUIDs being published in HTML, I  
would encourage you to add them to the wiki:


http://microformats.org/wiki/species-examples

Without such examples, this isn't likely to make it into a  
microformat, because microformats are based on current publishing  
rather than future publishing, however likely it may be.


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