Subject: Re: [Geopriv] Draft Updates "GEO TAGS for HTML"

From: Andrew Daviel <[email-masked]>
Date: Tue, 25 Sep 2007 02:15:13 -0700 (PDT)

Apologies for apparently random timing of replies; I still have some 
vacation mail to deal with which I may have only skimmed earlier.

On Fri, 10 Aug 2007, Henning Schulzrinne wrote:

> I hope we're not having the discussion based on "existing software", as this 
> essentially means that you might as well stop asking this group for input.

Well, no. It's not exactly a huge installed codebase.

>
>> 
>>> The space-only version simply conforms to the XML version. The semicolon 
>>> adds no particular value here.

...
>
> I think GEOPRIV is a pretty good example that the IETF has no good way to 
> determine majorities reliably :-)

:-7

> My general concern is that inconsistency leads to mistakes. This working 
> group, at least, should try to stick to one way to encode data.

True, everyone seems to do things a little bit differently.

In the HTML draft, I'm not trying to define XML or RDF elements for the 
semantic Web. I'm trying to formalize a metadata element for legacy HTML 2/3/4.
The specification of HTML META element I used is W3C's HTML 4.01. The 
value of the content field is character data without trailing or leading 
spaces but is otherwise fairly free. There has been an informal 
convention of using a comma or semicolon to separate subfields,
ignoring whitespace, e.g.
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-2022-JP">
<META HTTP-EQUIV="Refresh" CONTENT="3;URL=http://www.some.org/some.html">
<META NAME="ROBOTS" CONTENT="NOINDEX, NOFOLLOW">
<META name="keywords" lang="en-us" content="vacation, Greece, sunshine">
<meta name = "DC.Format" content = "video/mpeg; 14 minutes">
I happened to pick a semicolon, as used in RFC2731 (or  RFC2426, RFC2445 
which define a GEO element, admittedly not in HTML metadata)

I guess I'm saying that in defining semantics of an HTML META element, 
that the relevant conventions to be followed are those of HTML META 
elements, familiar to Web authors, rather than the conventions of a newer 
language or protocol.

On the other hand, the development of a new structured machine-parsable 
document format which includes geographic data is a worthwhile goal. But 
a different one.

Andrew Daviel

_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 25 Sep 2007 06:43:29 -0400

As pointed out before, nobody is suggesting that you define a new  
document format. The suggestion is to define civic and geo meta tags  
that have a one-to-one correspondence with PIDF-LO tags, as in

<meta name = "geo.pcn" content="Mainville">

This makes it trivial to create a PIDF-LO from such meta data and  
vice versa. (There may be some subsetting required for complicated  
geometric constructs.)

On Sep 25, 2007, at 5:15 AM, Andrew Daviel wrote:
> In the HTML draft, I'm not trying to define XML or RDF elements for  
> the semantic Web. I'm trying to formalize a metadata element for  
> legacy HTML 2/3/4.
> The specification of HTML META element I used is W3C's HTML 4.01.  
> The value of the content field is character data without trailing  
> or leading spaces but is otherwise fairly free. There has been an  
> informal convention of using a comma or semicolon to separate  
> subfields,
> I happened to pick a semicolon, as used in RFC2731 (or  RFC2426,  
> RFC2445 which define a GEO element, admittedly not in HTML metadata)
>
>
> I guess I'm saying that in defining semantics of an HTML META  
> element, that the relevant conventions to be followed are those of  
> HTML META elements, familiar to Web authors, rather than the  
> conventions of a newer language or protocol.
>
> On the other hand, the development of a new structured machine- 
> parsable document format which includes geographic data is a  
> worthwhile goal. But a different one.
>
>
> Andrew Daviel

---

From: Andrew Daviel <[email-masked]>
Date: Thu, 27 Sep 2007 02:42:09 -0700 (PDT)

On Tue, 25 Sep 2007, Henning Schulzrinne wrote:

>
> As pointed out before, nobody is suggesting that you define a new document 
> format. The suggestion is to define civic and geo meta tags that have a 
> one-to-one correspondence with PIDF-LO tags, as in
>

So, do I have this right ? :

as per PIDF-LO from draft-ietf-geopriv-pidf-lo-03.txt or RFC 4776

<meta name="geo.country" content="CA">     as per ISO3166-1
<meta name="geo.a1" content="BC">          matches ISO3166-2 for US, CA
                                            but seems less obscure than
                                            ISO elsewhere

<meta name="geo.a3" content="Vancouver">   City (locality)
<meta name="geo.pc" content="V6T 2A3">     Postcode/Zip

etc.

If I resubmit draft-daviel-html dropping geo.region and geo.placename and
adding the PIDF fields as above, would this be acceptable?
I could enumerate the fields from RFC4776, or simply refer to this RFC.

I had some feedback that the totality of PIDF fields is too complex for 
the intended purpose of my draft (non-professional human authoring). But 
as I understand, the fields are optional and not all fields have values 
in any case. I could mention country and A1 specifically and the others 
by reference.

Regarding "a new document format", I came across a piece by Berners-Lee
et al. bemoaning the fact that people like me are still writing "quirks 
mode" HTML instead of fully embracing the XML semantic web
http://www.w3.org/2007/03/vision
I do wonder occasionally whether advances in artificial intelligence
will render it all moot (except for industrial uses where communities can 
agree on a schema)

But on the other hand I find the microformat community has been busy 
defining things like hCard while I've been asleep, which seems to be
embeddable in XHTML/RSS  (looks like they adopted GEO from RFC 2445)
http://microformats.org/wiki/geo

Andrew Daviel

---

From: "Tschofenig, Hannes (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 27 Sep 2007 11:50:33 +0200

Hi Andrew, 

> adding the PIDF fields as above, would this be acceptable?

These change look promising to me. 

> I could enumerate the fields from RFC4776, or simply refer to 

You will have to add a reference to RFC 4776 anyway. 

> in any case. I could mention country and A1 specifically and 

Complexity for what exactly? 

You might omit a few fields but you again have to be careful that you
can still represent a location in, let's say, Japan. 

Ciao
Hannes

---

From: "Winterbottom, James" <[email-masked]>
Date: Thu, 27 Sep 2007 04:56:10 -0500

Or reference the revised civic specification.

> -----Original Message-----
> From: Tschofenig, Hannes (NSN - DE/Munich)
> [mailto:[email-masked]]
> Sent: Thursday, 27 September 2007 7:51 PM
> To: ext Andrew Daviel; Henning Schulzrinne
> Cc: [email-masked]
> Subject: AW: [Geopriv] Draft Updates "GEO TAGS for HTML"
> 
> Hi Andrew,
> 
> 

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

---

From: Andrew Daviel <[email-masked]>
Date: Fri, 28 Sep 2007 00:26:27 -0700 (PDT)

On Thu, 27 Sep 2007, Tschofenig, Hannes (NSN - DE/Munich) wrote:

>> I had some feedback that the totality of PIDF fields is too
>> complex ...

> Complexity for what exactly?

"ordinary mortals to comprehend", basically. I had originally intended 
just a single "region" field as a check against lat/long quadrant 
goofups, but with the online tools like Google maps that is not so much 
of an issue now.

For the kind of use I envisage, it has to at least appear simple or 
people won't use it. Witness the penetration of Dublin Core metadata vs. 
"keywords". However, if most fields are optional, an application may use 
only a preferred few. So I guess it's not really an issue.

> Or reference the revised civic specification.

That would be draft-ietf-geopriv-revised-civic-lo-05.txt ?
If I understand right, you aren't supposed to refer to
IDs as normative. Unless they go to RFC in tandem.
But in principle, yes. Or RFC4119 and revise it later.

-- 
Andrew Daviel, TRIUMF, Canada

---

From: "Felix Kaegi" <[email-masked]>
Date: Fri, 28 Sep 2007 10:28:36 +0200

Gentlemen

To fulfill everybody' expectation I'd like to suggest following;

Defining both elements (the proposed author friendly HTML META tags and new
an
HTML reference to a machine processable XML file implementing any location
specific schema to map an address or an area) shall be optional.
If a valid coordinate in the META TAG geo.position is defined this shall be
the preferred
location definition for HTML location specification.

Advantage of this suggestion:
As the number of HTML META tags would rise enormously to map PIDF-LO or
other Address schemas and the further chances that HTML authors would use
them are very low, it would make more sense to reference an XML file
describing a location or area. Such a file may use any XML schema and also
may map RFC 4776 or any other location specification. This would further
rise the door to describe complex geometric areas as it was not yet possible
and would therefore also fit future specifications and needs. Also the
Google location specification may be used then.

Would this suggestions meet everybody' expectation to a simple, global,
language and culture independent,
accurate enough definition to GEO TAGS for HTML Docs?

felix

-----Ursprüngliche Nachricht-----
Von: Tschofenig, Hannes (NSN - DE/Munich) [mailto:[email-masked]]

Gesendet: Donnerstag, 27. September 2007 11:51
An: ext Andrew Daviel; Henning Schulzrinne
Cc: [email-masked]
Betreff: AW: [Geopriv] Draft Updates "GEO TAGS for HTML"

Hi Andrew, 

> complex for 

Ciao
Hannes

---

From: "Winterbottom, James" <[email-masked]>
Date: Fri, 28 Sep 2007 04:24:30 -0500

I fully expect Revised civic to go RFC before HTML Tags.. ;)

> From: Andrew Daviel [mailto:[email-masked]]
> Sent: Friday, 28 September 2007 5:26 PM
> To: Tschofenig, Hannes (NSN - DE/Munich)
> Cc: [email-masked]
> Subject: Re: AW: [Geopriv] Draft Updates "GEO TAGS for HTML"
>

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 28 Sep 2007 08:58:14 -0400

I think your problem here is "global and culture independent".  The proposed
"author friendly" tags are not global or culture independent.  The PIDF tags
are.  We worked pretty hard on that.  One of the reasons that the tags are
labled "A1", etc is "culture independent". 

Brian

> From: Felix Kaegi [mailto:[email-masked]]
> Sent: Friday, September 28, 2007 4:29 AM
> To: 'Tschofenig, Hannes (NSN - DE/Munich)'; 'ext Andrew Daviel'; 'Henning
> Schulzrinne'
> Cc: [email-masked]