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 namespace article <https://wiki.openstreetmap.org/wiki/Namespace> again.
On Fri, Mar 27, 2015 at 1:12 PM, Albin Larsson <[email protected]> wrote: > 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> >> > > -- 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
