<div dir="ltr">Awesome! This makes a lot of sense to me and there's a lot to chew on. Thank you for breaking it down. Time to study the <a href="https://wiki.openstreetmap.org/wiki/Namespace">namespace article</a> again.</div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Mar 27, 2015 at 1:12 PM, Albin Larsson <span dir="ltr"><<a href="mailto:albin.post@gmail.com" target="_blank">albin.post@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Explaining my <span style="font-size:12.8000001907349px">approach:</span><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">ohm:</span></div><div><span style="font-size:12.8000001907349px">This is to make sure that it never gets confused with tags in OSM, I think all custom tags should have this namespace. OHM uses the same software as OSM for APIs, database, even frontend there for we should protect each project. We using the same editing software, data will end up in the wrong place... But yes it could be removed.</span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">uri</span></div><div><span style="font-size:12.8000001907349px">A relation using this approach will always be a URI, also it makes sense to have all relations under at least one common tag. But it could be removed, but it would be easier to query with a common uri tag...</span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">relation</span></div><div><span style="font-size:12.8000001907349px">This one is the core, I made up a few, that would make sense for OHM. This one can't be removed(and we have no reason to do so).</span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">platform</span></div><div><span style="font-size:12.8000001907349px">To get/parse data we need to know what it looks like, different platforms has different APIs and data models. The sooner we tell the developers what platform they should query for a specific relation the better. Just a URI does not make sense as many URIs are just id numbers.</span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">format</span></div><div><span style="font-size:12.8000001907349px">Sending a HTTP request to a URL would give us the format but lets say that an object in OHM has 200 URLs linked. Would we send 200 HTTP request to get the format so we can see which ones we can support? Some URL format would tell us(<a href="http://kulturarvsdata.se/shm/object/xml/974121" target="_blank">http://kulturarvsdata.se/shm/object/xml/974121</a> is xml) but not all does... </span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">It's about both be nice to developers and mappers, this approach can be used by both. </span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">Platform specific RDF namespaces such as EDM would work for platforms that are big with linked data, such as SOCH, but for all other platforms? Having one solution working for all platforms is a advantage.</span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">We should of curse care about RDF and platform specific RDF namespaces, but the way to do it is maybe through middleman libraries/services(LdRequest->requestParsing->Overpass->RdfParsing->RdfResponse)? This way we could support common LD platforms and non LD ones. such a service could be self hosted or available as a API.</span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">The</span> relation/platforms/format should be documented, and such documentation could be available in RDF format(and any other LD format). It would even be a great idea to set up a OHM RDF namespace to be able to provide RDF output.</div><div><br></div><div>OHM can't wait for all other platforms to do linked data, this approach allows OHM to do linked data now with any open platform.</div><div><br></div><div>//</div><div>Albin</div><div><span style="font-size:12.8000001907349px"><br></span></div><img width="0" height="0" src="https://mailtrack.io/trace/mail/d96ef367b315fd932ba8598660763cccc3c6738a.png"></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">2015-03-27 19:00 GMT+01:00 <a href="mailto:todd.d.robbins@gmail.com" target="_blank">todd.d.robbins@gmail.com</a> <span dir="ltr"><<a href="mailto:todd.d.robbins@gmail.com" target="_blank">todd.d.robbins@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Thanks for the response Albin. I'm curious about the <font face="monospace, monospace">relation/platforms/format</font> pattern of namespacing. First of all, why is the the <font face="monospace, monospace">ohm</font> custom key (e.g. <font face="monospace, monospace">ohm:uri:is_described_by</font>) necessary if the data is within OHM? Is this to identify the data if it is imported to OSM, for instance? Also, are the relations in <font face="monospace, monospace">relation/platforms/format</font> something we at OHM are defining or are you referring to a specific ontology? I want to be sure I'm understanding the approach as best as I can.<div><br></div><div>Again, this is an exciting topic and thank you for breaking the ground!</div></div><div class="gmail_extra"><div><div><br><div class="gmail_quote">On Fri, Mar 27, 2015 at 7:50 AM, Albin Larsson <span dir="ltr"><<a href="mailto:albin.post@gmail.com" target="_blank">albin.post@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">As a respond to your comment Tod, not all platforms has such a data model, for example OHM/OSM does not. There for its's hard to be flexible enough with RDF namespaces, also documentation and simplicity counts...  <div><br></div><div>But we should provide a RDF/JSONLD/... documentation the tags used(relation/platforms/format).</div><div><br></div><div><div>//</div><span><font color="#888888"><div>Albin</div><div>     </div></font></span></div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">2015-03-27 14:33 GMT+01:00 SK53 <span dir="ltr"><<a href="mailto:sk53.osm@gmail.com" target="_blank">sk53.osm@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>Very interesting indeed, and I think your ideas really highlight aspects of the likely depth of tagging we are likely to end up with in a richly developed area of OHM. <br><br></div>It also convinces me that there is mileage in my idea of splitting out metatags from tags describing the object itself.<br><br></div>Jerry<br></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div>On 27 March 2015 at 12:57, Albin Larsson <span dir="ltr"><<a href="mailto:albin.post@gmail.com" target="_blank">albin.post@gmail.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div dir="ltr">My thoughts on linked data in OpenHistoricalMap and how I do it:<div><br><div><a href="http://abbe98.github.io/blog/2015/03/26/mapping-the-past-with-linked-data-in-openhistoricalmap/" target="_blank">http://abbe98.github.io/blog/2015/03/26/mapping-the-past-with-linked-data-in-openhistoricalmap/</a></div><div><br></div><div>Feedback, ideas, thoughts?</div><div> </div></div><div>//</div><div>Albin</div><img height="0" width="0"></div>
<br></div></div><span>_______________________________________________<br>
Historic mailing list<br>
<a href="mailto:Historic@openstreetmap.org" target="_blank">Historic@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/historic" target="_blank">https://lists.openstreetmap.org/listinfo/historic</a><br>
<br></span></blockquote></div><br></div>
</blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
Historic mailing list<br>
<a href="mailto:Historic@openstreetmap.org" target="_blank">Historic@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/historic" target="_blank">https://lists.openstreetmap.org/listinfo/historic</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div></div></div><span>-- <br><div><div dir="ltr"><span style="font-family:arial;font-size:small">Tod Robbins</span><div style="font-family:arial;font-size:small"><font color="#666666" face="arial, sans-serif">Digital Asset Manager, MLIS</font></div><div style="font-family:arial;font-size:small"><span style="font-family:arial,sans-serif;font-size:13px"><font color="#666666"><a href="http://todrobbins.com/" style="color:rgb(17,85,204)" target="_blank">todrobbins.com</a> | <a href="http://www.twitter.com/#!/todrobbins" style="color:rgb(17,85,204)" target="_blank">@todrobbins</a></font></span></div></div></div>
</span></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><span style="font-family:arial;font-size:small">Tod Robbins</span><div style="font-family:arial;font-size:small"><font color="#666666" face="arial, sans-serif">Digital Asset Manager, MLIS</font></div><div style="font-family:arial;font-size:small"><span style="font-family:arial,sans-serif;font-size:13px"><font color="#666666"><a href="http://todrobbins.com/" style="color:rgb(17,85,204)" target="_blank">todrobbins.com</a> | <a href="http://www.twitter.com/#!/todrobbins" style="color:rgb(17,85,204)" target="_blank">@todrobbins</a></font></span></div></div></div>
</div>