Difference between revisions of "IDS01"

From Data on the Web Best Practices
Jump to: navigation, search
(Unique IDs)
(Group discussion)
Line 6: Line 6:
 
== Description ==
 
== Description ==
 
== Group discussion ==
 
== Group discussion ==
 +
 +
[See this page of working group notes https://www.w3.org/2013/dwbp/wiki/Data_on_the_Web_URI_Best_Practices]
 +
 +
From Andy Mabbett's talk on OpenStreetMap at our Face-to-face in London:
 +
// This may be too much for this section
 +
 +
* OpenStreetMap tags essentially form triples (attributes of nodes). Not expressed that way though.
 +
* Reference external sites
 +
** (like openplaques_plaque = 1563).  Not referenced with a URL; they'd like to.  http://openplaques.org/plaques/1563
 +
** english_heritage_ref 468884.  The URL could go to a text-based article or images.
 +
*** key:english_heritage_ref isn't defined.  The community may have minted their own key (english_heritage_number, for example).  Some editing tool will autosuggest existing keys, but not all, and users can ignore them.
 +
** Do include the URL to a website, but not necessarily structured data.
 +
** Store wikidata value
 +
*** key:wikidata isn't documented.  It's still new, and the community hasn't agreed that it should be used. Small community and slow consensus process.
 +
** store reference terms to build a wikipedia page, but don't explicitly build it because
 +
*** it's long,
 +
*** b) there are more than one wikipedia URL per article (http, https, etc.)
 +
* People are reluctant;  they don't understand why they should.  Volunteers think entering the number into a table is enough.  We could run a script to replace the data with a URL, or we could make the fact that the data is part of a URL more clear on the (human readable) wiki.)
 +
* Subkeys:  wikipedia:architect.  or wikidata:architect.
 +
* Community conflicts:  members in different parts of the world will mint different terms meaning the same thing.  They slowly come together and conflict.
 +
* Unique reference number per node (in this case, for the way) is in the URL.  http://openstreetmap.org/way/32892093
 +
* Tree. (node 2642471054) Attribute: Ref = 0141.  Whose ref is that?  In this case, it's a local council reference.  No URL to be made there — nothing to link to.
 +
* When a node is replaced with a new node or new data, there is no way to know what happened to the old node.  (Building destroyed?  Data was just there in error?)  Old one just returns an HTTP 200 error.
 +
 
== Background references ==
 
== Background references ==
 
== Reference implementations ==
 
== Reference implementations ==

Revision as of 22:11, 10 April 2014

Title

Unique IDs

Description

Group discussion

[See this page of working group notes https://www.w3.org/2013/dwbp/wiki/Data_on_the_Web_URI_Best_Practices]

From Andy Mabbett's talk on OpenStreetMap at our Face-to-face in London: // This may be too much for this section

  • OpenStreetMap tags essentially form triples (attributes of nodes). Not expressed that way though.
  • Reference external sites
    • (like openplaques_plaque = 1563). Not referenced with a URL; they'd like to. http://openplaques.org/plaques/1563
    • english_heritage_ref 468884. The URL could go to a text-based article or images.
      • key:english_heritage_ref isn't defined. The community may have minted their own key (english_heritage_number, for example). Some editing tool will autosuggest existing keys, but not all, and users can ignore them.
    • Do include the URL to a website, but not necessarily structured data.
    • Store wikidata value
      • key:wikidata isn't documented. It's still new, and the community hasn't agreed that it should be used. Small community and slow consensus process.
    • store reference terms to build a wikipedia page, but don't explicitly build it because
      • it's long,
      • b) there are more than one wikipedia URL per article (http, https, etc.)
  • People are reluctant; they don't understand why they should. Volunteers think entering the number into a table is enough. We could run a script to replace the data with a URL, or we could make the fact that the data is part of a URL more clear on the (human readable) wiki.)
  • Subkeys: wikipedia:architect. or wikidata:architect.
  • Community conflicts: members in different parts of the world will mint different terms meaning the same thing. They slowly come together and conflict.
  • Unique reference number per node (in this case, for the way) is in the URL. http://openstreetmap.org/way/32892093
  • Tree. (node 2642471054) Attribute: Ref = 0141. Whose ref is that? In this case, it's a local council reference. No URL to be made there — nothing to link to.
  • When a node is replaced with a new node or new data, there is no way to know what happened to the old node. (Building destroyed? Data was just there in error?) Old one just returns an HTTP 200 error.

Background references

Reference implementations