In his email to the WG Clemens says:

The LD-BP reference makes this very RDF dependent. Is there a need / justification for this? Are we saying that RDF is the only recommended way to publish data and models on the Web? I know some will say "yes", but if we target web developers I would guess that many do not care about RDF vocabularies and maybe they prefer a Swagger document (just to pick an example)?

I'm inclined to agree. Reading the draft best practices, two sentences jar:

"The intended users of the SDI are experts in the geospatial domain." - definitely not the case with the WMS/View Service part (which is why the paper can make the comment about a 'spatial picture infrastructure' - that's the most user friendly bit..

"the Linked Data approach is most appropriate for publishing and using spatial data on the Web" - although at least here there is immediately a note implying that this is only the case for web developers. And even then, I know plenty who have no interest in Linked Data.

Like you, I am keen to move beyond pictures to meaningful information. Concentrating solely on linked data is already putting web developer colleagues off from being involved in this group.

if there is a justification for making this very RDF dependent, then this must be made explicit. my view is that the WG is doing themselves as well as the spatial data community a disservice by (so far) turning this into a "Best Practices for Spatial RDF Data on the Web" document. #229 also raised this point a little while ago, and i am curious to see responses over there or here.

Did a small rewrite. Maybe this is enough to reduce the RDF focus?

Added this text:
"Depending on the format you use, the semantics may already be described in some form. For example, in GeoJSON this description is present in the [[GeoJSON]] specification. When using JSON it is possible to add semantics using a JSON-LD @context. For providing semantics to search engines, using schema.org is the way to go, as explained in BP 3: Make your data indexable by search engines.
In a linked data setting, the attributes of a spatial thing can be described using existing vocabularies [..]."

On 2016-08-18 01:57, Linda van den Brink wrote:

"Depending on the format you use, the semantics may already be described
in some form. For example, in GeoJSON this description is present in the
[[GeoJSON]] specification. When using JSON it is possible to add
semantics using a JSON-LD @context https://github.com/context. For
providing semantics to search engines, using schema.org is the way to
go, as explained in BP 3: Make your data indexable by search engines.
In a linked data setting, the attributes of a spatial thing can be
described using existing vocabularies [..]."

i take issue with this general assumption that "semantics" are awarded
when using RDF. that only is the case when the RDF vocabulary used is
either shared, or is grounded in shared vocabularies. and for either of
these cases, the very same is true for non-RDF vocabularies. to me,
trying to cast this document as something that favors one specific
technology makes it unnecessarily biased, and hurts its usefulness for
the larger web.

any document claiming to be about "data on the web" should be fiercely
nonpartisan when it comes to technology choices beyond web architecture.
i haven't looked at the overall document recently, but when i did a
while ago, there were many places where the document would require
cleanup from clear bias.

http://dret.github.io/webdata/

I agree with Erik here. It is true that a certain kind of semantics are made possible by use of RDF-based technology. But whether that is actually realised depends on a few more steps than merely using an RDF-friendly serialization. We need to be careful that the claim around semantics is not premature. Maybe this tweak to Linda's formulation is a little more accurate:

"Depending on the format you use, support for some semantics may already be available. For example, for data in GeoJSON the description of the spatial semantics is in the [GeoJSON] specification. When using JSON it is also possible to link to semantics defined in some RDF vocabulary using a JSON-LD @context. To provide semantics to search engines, using schema.org is the way to go, as explained in BP 3: Make your data indexable by search engines."

In the newly drafted section on Linked Data, we've tried to indicate that our focus is linked data not (only) RDF and that there are many technology solutions that can be applied.

In a nut shell, I think that our recommended formats need to support Web Linking (see RFC5988), where each link contains:

1. context URI (the source or origin)
2. link relation type
3. target URI
4. (optionally) target attributes

Item (2) covers semantics of links; a user or software agent should be able to find the definition of a given link type. Similarly, we need to be able to define the type of the resources themselves and the semantics of properties with literal values.

That said, the majority of examples in the BP doc have a RDF flavour which is tending to distort our aspiration to avoid technology bias.

Would an example implemented in XML/GML help? I can offer OS OpenNames. It's not necessarily the best example, because the GML isn't directly available on the web (except as a giant Zip file!), but it may be useful to illustrate how the concept of linked data needn't be RDF.

Also, I'm quite happy (on behalf of OS) if people have suggestions for improving the encoding (although it may take us some time to implement them). What we've done so far is inspired by INSPIRE.

Details at https://data.gov.uk/dataset/os-open-names. Sample snippet:

<names:NamedPlace gml:id="osgb4000000023473828">
      <gml:identifier codeSpace="http://inspire.jrc.ec.europa.eu/ids">http://data.ordnancesurvey.co.uk/id/4000000023473828</gml:identifier>
...
      <names:inPostcodeDistrict xlink:title="SN8" xlink:href="http://data.ordnancesurvey.co.uk/id/postcodedistrict/SN8"/>
      <names:inPopulatedPlace xlink:title="Buttermere" xlink:role="http://www.ordnancesurvey.co.uk/xml/codelists/localtype.xml#hamlet" xlink:href="http://data.ordnancesurvey.co.uk/id/4000000074567820"/>
      <names:inCounty xlink:title="Wiltshire" xlink:role="http://data.ordnancesurvey.co.uk/ontology/admingeo/UnitaryAuthority" xlink:href="http://data.ordnancesurvey.co.uk/id/7000000000043925"/>
      <names:inEuropeanRegion xlink:title="South West" xlink:href="http://data.ordnancesurvey.co.uk/id/7000000000041427"/>
      <names:inCountry xlink:title="England" xlink:href="http://data.ordnancesurvey.co.uk/id/country/england"/>
</names:NamedPlace>

or is that not what you meant at all, Jeremy?

Hi @PeterParslow ... I updated your comment to show the snippet as a code block (and stop GH interpreting it as markdown).

Yes- we need examples such as these ...

It would be good to have examples that can be fitted into the flooding scenario that we're using in the BP document to bring some consistency.

One other place where the focus on RDF is present is the Abstract. Rewrite needed.

So, places to review and possibly amend are:

• The abstract
• 9. Linked Data section
• BP7 because LD-BP is referenced there as well - perhaps not needed.
• 12.5 Spatial data vocabularies
• 12.7 Linking spatial data

Resolved to amend the abstract. We think the other sections are balanced enough and not advocating RDF as the only linked data solution.