[OHM] Linked Data

Fri Mar 27 20:16:51 UTC 2015

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 <albin.post at gmail.com> 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 todd.d.robbins at gmail.com <
> todd.d.robbins at gmail.com>:
>
>> 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 <albin.post at gmail.com>
>> 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 <sk53.osm at gmail.com>:
>>>
>>>> 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 <albin.post at gmail.com> 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
>>>>> Historic at openstreetmap.org
>>>>> https://lists.openstreetmap.org/listinfo/historic
>>>>>
>>>>>
>>>>
>>>
>>> _______________________________________________
>>> Historic mailing list
>>> Historic at openstreetmap.org
>>> 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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/historic/attachments/20150327/c18b4e57/attachment.html>