search

opengeospatial / poi

OGC Points of Interest Encoding Specification
Apache License 2.0
21 stars 28 forks source link

Should we define linkages between POI databases with an API instead of the link property? #27

Closed isc-rsingh closed 3 years ago

robatkinson commented 10 years ago

link is a very generalised concept. it will be overloaded with many types of links to many types of resources.

There are two ways to mitigate this: 1) make the link function handled by an API, so that it resolves to a list of links with categorisation, metadata etc. 2) force standardisation onto the form and purpose of links, probably requiring a microformat (non-opaque URLs you can parse to determine what type of link it is

The external API also has standardisation challenges. you could define a standardised single usage semantic for the link property, and use an API link to discover others. this is however a complex problem whether its inside the spec or outside, and i think its too complicated to resolve inside at this stage, so I would argue for an API and push the problem to a separate domain. Its not limited to POI either, so anything you do will be reinventing a general wheel if you internalise the problem.

In the SIRF project we have had to define a standardised view for this, and thats about all we had to standardise outside the use of other available standards. This is implemented by making it necessary to resolve URI?_view=alternates to this view (a very lightweight implementation of the Linked Data API syntax, using the IANA "alternate" definition.)

isc-rsingh commented 10 years ago

One of the original use cases was that this could be implemented with text files on a web server. If link was implemented with an API, would that exclude this use case?

robatkinson commented 10 years ago

so that is a text file per feature?

If so, i think we'd be fine considering

1) you already have multi-valued attributes, so assuming the text file can support some structure 2) If the structure supports open-world models - i.e. we can combine graphs...then 3) ....we can combine links, foaf, other metadata using the same set of mechanisms 4) and we can still do content negotiation based on a request for the links graph, to hook the API to the URI and default back to the text file if no specific view is specified.