Closed isc-rsingh closed 3 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?
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.
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.)