Re: [Tagging] Issues relating to URIs and tagging

[Andy Mabbett]

On 2 April 2014 10:49, Andy Mabbett  wrote:

> It should be posisble to give JOSM (or other editors)
> the URL of a "contact us" web page, and for JOSM
> to then go to that page, read an hCard microformat
> (or some other contact metadata) and bring it back
> into the preset dialogue for editing and confirmation.
>
> It should also be able to do that with a Wikidata URL
> or "Q" identifier, and bring back a range of properties.
>
> I'll raise a bugs for these.

Done:

   https://josm.openstreetmap.de/ticket/9885

   https://josm.openstreetmap.de/ticket/9886

respectively.

-- 
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Issues relating to URIs and tagging

[Andy Mabbett]

On 2 April 2014 03:58, André Pirard  wrote:

> I opened a JOSM bug saying that many presets
> lack the Website tag box where to enter an URL.

It should be posisble to give JOSM (or other editors) the URL of a
"contact us" web page, and for JOSM to then go to that page, read an
hCard microformat (or some other contact metadata) and bring it back
into the preset dialogue for editing and confirmation.

It should also be able to do that with a Wikidata URL or "Q"
identifier, and bring back a range of properties.

I'll raise a bugs for these.

-- 
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Issues relating to URIs and tagging

[André Pirard]

  
  
On 2014-04-01 17:29, Andy Mabbett wrote
  :


  Hello everyone,

This is my first post to the list, which I've just joined, but I've
been a mapper for a few years and some of you might remember me as
compere at last year's State of the Map.

Yesterday, I met with the W3Cs'  "data on the web best practice"
working group. At their request, I gave a talk on the use of URIs
(particularly linked data URIs) and related tags,  in OSM.

I described, and we then discussed, how we tag entities in OSM, using
UIDs but not necessarily URLs, and issues facing data users who need
to resolve those UIDs back to URLs; ...


On my side, I often pointed out how little URL are used and that
they could be used (consumed) by auto-recognizing them in tags where
they were not initially supposed to be, like operator=*.
I opened a JOSM bug saying that many presets lack the Website tag
box where to enter an URL.
I suggested embedding.
They created a full Annotation:Contact preset and a command to embed
a preset into another.
Remains to effectively embed in defective presets that Contact
preset containing the Website box.
I also pointed out that for a user to help improve presets while
tagging along, presets should be reloadable.
They claimed that stopping/restarting JOSM during a work session is
a mere matter !!!  Not so.
They finally said that they can improve the presets themselves.
Bottom line:
If you find a missing Website tag box in a JOSM preset, open a bug
to request a Contact embedding.

Practically yours,
Cheers,


  

  André.

  



  


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Issues relating to URIs and tagging

[Eugene Alvin Villar]

On Tue, Apr 1, 2014 at 11:29 PM, Andy Mabbett wrote:

> The model used there fails with Wikipedia links,
> expressed as "en:Example", because the equivalent URL is
> . Any suggestions for dealing
> with that?
>
> [...] ambiguous keys ("ref=1234" - ref in whose database?) [...]
>

I think you might be better off providing an "algorithm" to generally
handle such cases because specifying a URL pattern like "
http://openplaques.org/plaques/[value]"; is too simple for the diverse ways
that people tag OSM objects.

For example, the algorithm will use capturing regexes to split the key
and/or value into parts. And then you can assemble the URI/URL depending on
the presence of other tags and on GIS-related aspects of the tagged object
(for example, if the object is inside the boundary relation for France).

For the wikipedia=* example, you can have:

tag_regex = ([^;]+):(.+)
> uri_algorithm = uri_pattern:"https://$1.wikipedia.org/wiki/$2";
>

The uri_algorithm would have to be in the form of a switch or case
construct like for ref.

uri_algorithm =
>case fr_highways:
>   condition = has:highway=* && in polygon[has:type=boundary &&
> has:admin_level=2 && has:ISO3166-1=FR]
>   uri_pattern = "http://...$value...";
>

Now that I think about it, Apache's HTTP server mod_rewrite rules work
exactly like this. mod_rewrite takes an input URL (or a tag in our case)
and rewrites it to another URL by specifying RewriteCond and RewriteRule
elements that correspond to my "condition" and "uri_pattern"/"tag_regex"
example above respectively.

RewriteCond is quite flexible since you can match on any aspect of the HTTP
request such as requesting IP address, date and time of request, cookies,
etc. RewriteRules specify a regex on the input URL and then the resulting
URL pattern.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Issues relating to URIs and tagging

[Richard Welty]

On 4/1/14 1:01 PM, Andy Mabbett wrote:
> I'd be happy to do that; what do others think? While semantically
> correct, I think more mapper might understand "URL". 
is it a URI or a URL? if it's strictly a URL, that's fine, URL as a term is
not deprecated, it's merely a subset of URI. but if you intend to
be able operate on the URN side of the URI house, then you need
to use URI properly.

as for ref, i think that the door to the barn has been open
for a long time and it may be challenging to accomplish a
general fix. i think instead that for specific entities that use
ref (e.g., highways) you'll get farther by specifying what ref
means for the class of entity.

richard

-- 
rwe...@averillpark.net
 Averill Park Networking - GIS & IT Consulting
 OpenStreetMap - PostgreSQL - Linux
 Java - Web Applications - Search




signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Issues relating to URIs and tagging

[Andy Mabbett]

On 1 April 2014 17:31, Dan S  wrote:

> 2014-04-01 16:29 GMT+01:00 Andy Mabbett :

>> last year's State of the Map.
>
> And well done indeed!

Thank you.

>> I've just modified [[Template:KeyDescription]] by adding
>> two parameters:

>> for "website" and "url_pattern"

> Tell me if I've misunderstood you, but you're proposing that the
> url_pattern given in the wiki "infobox" KeyDescription is intended to
> be machine-readable, in the sense that a third-party data consumer can
> plug url_pattern together with the actual key-values found in OSM and
> automatically find the URL for something? If so, the idea is
> intriguing and I think it's a nice lightweight thing we can do.

Yes; that's it.

> I have a small quibble which is please change it from "URL" to "URI",
> since I think the latter is the more appropriate concept. We're aiming
> to interlink _identities_ of items really, for the machines.

I'd be happy to do that; what do others think? While semantically
correct, I think more mapper might understand "URL".

>>
>>
>> The sooner we move that from "Talk:Proposed_features/" to "Key:", the better.
>
> Wikidata proposal looks good to me.

I'm about to move it to RfC. I look forward to your support ;-)

>> Other issues which are unhelpful to data re-users include keys with
>> missing documentation; redundant keys ("Key:openplaques_plaque" vs
>> "Key:openplaques_id");
>
> I have never seen these tags, but there are very few uses - this
> example is probably really easy to consolidate into one tag.

Yes; but it was just an example. Nonetheless, the former is the better
name, as OpenPlaques also has IDs for people and organisations, as
well as the plaques themselves.

>> ambiguous keys ("ref=1234" - ref in whose database?)
>
> That's an interesting question. "ref" is widely used, and generally
> used quite coherently, _but_ its meaning is contextual on other tags.
> For example, "amenity=post_box" & "operator=Royal Mail" tells you
> where to expect the ref to point. I wonder if "operator" sets the
> context in many other cases? (I accept, of course, that many objects
> aren't tagged with operator.)

Or the ref may not relate to the operator.

-- 
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.u

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Issues relating to URIs and tagging

[Dan S]

Hi Andy,

2014-04-01 16:29 GMT+01:00 Andy Mabbett :
> Hello everyone,
>
> This is my first post to the list, which I've just joined, but I've
> been a mapper for a few years and some of you might remember me as
> compere at last year's State of the Map.

And well done indeed!

> Yesterday, I met with the W3Cs'  "data on the web best practice"
> working group. At their request, I gave a talk on the use of URIs
> (particularly linked data URIs) and related tags,  in OSM.
>
> I described, and we then discussed, how we tag entities in OSM, using
> UIDs but not necessarily URLs, and issues facing data users who need
> to resolve those UIDs back to URLs; for example:
>
> openplaques_plaque = 1536
>
> to:
>
>http://openplaques.org/plaques/1536
>
> To that end, I've just modified [[Template:KeyDescription]] by adding
> two parameters:
>
>
> https://wiki.openstreetmap.org/w/index.php?title=Talk:Tag:historic%3Dmemorial&diff=prev&oldid=1010411
>
> for "website" and "url_pattern"

That URL doesn't seem right. I think you mean


> see:
>
>https://wiki.openstreetmap.org/wiki/Key:openplaques_plaque
>
> of an example of how they're intended to be used (the label display
> needs tweaking).

Tell me if I've misunderstood you, but you're proposing that the
url_pattern given in the wiki "infobox" KeyDescription is intended to
be machine-readable, in the sense that a third-party data consumer can
plug url_pattern together with the actual key-values found in OSM and
automatically find the URL for something? If so, the idea is
intriguing and I think it's a nice lightweight thing we can do.

I have a small quibble which is please change it from "URL" to "URI",
since I think the latter is the more appropriate concept. We're aiming
to interlink _identities_ of items really, for the machines.

> The model used there fails with Wikipedia links,
> expressed as "en:Example", because the equivalent URL is
> . Any suggestions for dealing
> with that?

I don't see a plausible way of dealing with this that wouldn't be a
crazy hack. So I'd recommend that data re-users will simply need to
treat this as a special case if it's important to them. (I've always
thought the wikipedia tag would have worked better as
"wikipedia:en=Example" -- in that case, your template approach would
have worked fine.)

> They were very impressed with the inclusion of Wikidata IDs
>
>
>
> The sooner we move that from "Talk:Proposed_features/" to "Key:", the better.

Wikidata proposal looks good to me.

> Other issues which are unhelpful to data re-users include keys with
> missing documentation; redundant keys ("Key:openplaques_plaque" vs
> "Key:openplaques_id");

I have never seen these tags, but there are very few uses - this
example is probably really easy to consolidate into one tag.

The harder cases will - as discussed in recent threads on this list -
will remain in a state of productive controversy for a long time to
come! Sorry, data re-users, but that's wiki-life for you.

> ambiguous keys ("ref=1234" - ref in whose database?)

That's an interesting question. "ref" is widely used, and generally
used quite coherently, _but_ its meaning is contextual on other tags.
For example, "amenity=post_box" & "operator=Royal Mail" tells you
where to expect the ref to point. I wonder if "operator" sets the
context in many other cases? (I accept, of course, that many objects
aren't tagged with operator.)

> and the perennial problem of the lack of stable URIs for entities in OSM. I 
> have yet to solve that one...

OSM objects are not stable, same as Wikipedia articles. For Wikipedia
they provide partial stability through long-term historical "oldid"
links and redirects. I don't think tagging (i.e. this list) can solve
the permalink problem. It needs osm.org to provide a URL scheme that
allows people to link to a specific historical _version_ of an osm
object. We already provide direct links to changesets and to object
histories, so the data is all there.

Best
Dan

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Issues relating to URIs and tagging

[Andy Mabbett]

Hello everyone,

This is my first post to the list, which I've just joined, but I've
been a mapper for a few years and some of you might remember me as
compere at last year's State of the Map.

Yesterday, I met with the W3Cs'  "data on the web best practice"
working group. At their request, I gave a talk on the use of URIs
(particularly linked data URIs) and related tags,  in OSM.

I described, and we then discussed, how we tag entities in OSM, using
UIDs but not necessarily URLs, and issues facing data users who need
to resolve those UIDs back to URLs; for example:

openplaques_plaque = 1536

to:

   http://openplaques.org/plaques/1536

To that end, I've just modified [[Template:KeyDescription]] by adding
two parameters:

   
https://wiki.openstreetmap.org/w/index.php?title=Talk:Tag:historic%3Dmemorial&diff=prev&oldid=1010411

for "website" and "url_pattern"; see:

   https://wiki.openstreetmap.org/wiki/Key:openplaques_plaque

of an example of how they're intended to be used (the label display
needs tweaking). The model used there fails with Wikipedia links,
expressed as "en:Example", because the equivalent URL is
. Any suggestions for dealing
with that?

They were very impressed with the inclusion of Wikidata IDs

   

The sooner we move that from "Talk:Proposed_features/" to "Key:", the better.

Other issues which are unhelpful to data re-users include keys with
missing documentation; redundant keys ("Key:openplaques_plaque" vs
"Key:openplaques_id"); ambiguous keys ("ref=1234" - ref in whose
database?) and the perennial problem of the lack of stable URIs for
entities in OSM. I have yet to solve that one...

-- 
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging