Explaining my approach: ohm: 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.
uri 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... relation 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). platform 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. format 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(http://kulturarvsdata.se/shm/object/xml/974121 is xml) but not all does... It's about both be nice to developers and mappers, this approach can be used by both. 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. 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. The 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. 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. // Albin 2015-03-27 19:00 GMT+01:00 [email protected] < [email protected]>: > Thanks for the response Albin. I'm curious about the > relation/platforms/format pattern of namespacing. First of all, why is > the the ohm custom key (e.g. ohm:uri:is_described_by) 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 relation/platforms/format 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. > > Again, this is an exciting topic and thank you for breaking the ground! > > On Fri, Mar 27, 2015 at 7:50 AM, Albin Larsson <[email protected]> > wrote: > >> 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... >> >> But we should provide a RDF/JSONLD/... documentation the tags >> used(relation/platforms/format). >> >> // >> Albin >> >> >> 2015-03-27 14:33 GMT+01:00 SK53 <[email protected]>: >> >>> 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. >>> >>> It also convinces me that there is mileage in my idea of splitting out >>> metatags from tags describing the object itself. >>> >>> Jerry >>> >>> On 27 March 2015 at 12:57, Albin Larsson <[email protected]> wrote: >>> >>>> My thoughts on linked data in OpenHistoricalMap and how I do it: >>>> >>>> >>>> http://abbe98.github.io/blog/2015/03/26/mapping-the-past-with-linked-data-in-openhistoricalmap/ >>>> >>>> Feedback, ideas, thoughts? >>>> >>>> // >>>> Albin >>>> >>>> _______________________________________________ >>>> Historic mailing list >>>> [email protected] >>>> https://lists.openstreetmap.org/listinfo/historic >>>> >>>> >>> >> >> _______________________________________________ >> Historic mailing list >> [email protected] >> https://lists.openstreetmap.org/listinfo/historic >> >> > > > -- > Tod Robbins > Digital Asset Manager, MLIS > todrobbins.com | @todrobbins <http://www.twitter.com/#!/todrobbins> >
_______________________________________________ Historic mailing list [email protected] https://lists.openstreetmap.org/listinfo/historic
