Re: adding hypermedia to spatial data best practices

Can you point to any best practice examples of how to use such patterns,
and cope with communities of practice using their private top-level
ontologies?  FYI the Hydro domain working group is looking at delivering a
formal OWL ontology for hydrological relationships, and the upper ontology
issue is the main hurdle, and we have not been able to identify a workable
practice, let alone one with a degree of acceptance. This would be a great
outcome for a SDW thread in a testbed, and we have some Use Cases to
support it.

Attached is a draft Use Case from the hydro domain - its unclear what the
commenting mechanism is.  Having read the meeting minutes I think you guys
have been skirting around these sort of cases, and this provides some
specific examples of how to bind the issues of existing communities of
practice, upper ontology dilemmas, use of spatial web services and the
potential value of a web of data where large data sets are involved.

any comments on the Use Case before I submit it, and any advice as to how
and where it should be submitted would be appreciated.  Dave Blodgett from
the USGS has indicated an interest in providing concrete scenarios and data
examples for testing these ideas.


Regards
Rob Atkinson

On Fri, 31 Jul 2015 at 04:15 Krzysztof Janowicz <janowicz@ucsb.edu> wrote:

> Hi,
>
>
> In linked data, the meaning of links is always explicit and discoverable--
> that is the fundamental reason for the use of formal vocabularies. This
> also applies to owl:sameAs and rdf:seeAlso, although quite purposefully,
> rdfs:seeAlso has rather weak semantics. On the other hand, owl:sameAs has
> very tight semantics, but is very commonly used in a way that violates
> those semantics.
>
>
> Agreed, but let's not forget that only a very few of them such as
> owl:sameAs and rdfs:subProperty have a formal semantics. This makes a big
> compared to seeAlso and many popular SKOS relations.
>
>
> I doubt we can do much about the latter in the broader linked data world,
> unfortunately.
>
>
> Maybe we can; our work and recommendations will have a broad visibility.
>
>
>
> Curious as to how we might be able to "late-bind" to upper ontologies, and
> dissapointed there isnt a Use Case proposed that deals with two bodies of
> data implemented as RDF using different upper ontology choices. It seems to
> be this is something we really dont have a good solution to talk to yet. I
> could try to write such a Use Case, but i'll probably get the terminology
> all wrong and offend everyone (again).
>
>
> IMHO, patterns largely replace the need for upper ontologies and I would
> rather not define alignments to such top-level ontologies anymore.
>
> Best,
> Krzysztof
>
>
>
> On 07/30/2015 12:00 AM, Rob Atkinson wrote:
>
>
> I would agree there is a need to actually verify the "goodness" of some
> "best practices" - rather than just assert that utopia is coming.
> We need to walk semantics, not talk it, now. When something that is
> convincing to us, and can be shown to be tractable to developers is
> available, then the talk can resume.
> I dont think we need to throw out formal ontologies to get convenient JSON
> data - we should use the ontologies behind the scenes to make sure we dont
> get an infinite number of incompatible json renderings of the same data!
> Likewise, we should not throw out existing data models and standards
> governance when building those ontologies. In many cases we simply cant.
> Curious as to how we might be able to "late-bind" to upper ontologies, and
> dissapointed there isnt a Use Case proposed that deals with two bodies of
> data implemented as RDF using different upper ontology choices. It seems to
> be this is something we really dont have a good solution to talk to yet. I
> could try to write such a Use Case, but i'll probably get the terminology
> all wrong and offend everyone (again).
>
>
>
> On Thu, 30 Jul 2015 at 15:39 <Simon.Cox@csiro.au> <Simon.Cox@csiro.au>
> wrote:
>
>> Don’t get me wrong – precise link semantics is important. That’s why I
>> prefer time:hasTRS and geom:hasCRS to dct:conformsTo (the latter was
>> suggested on a dcat list in the last week).
>>
>>
>>
>> Maybe it’s the people I’ve been meeting recently, but I’m finding it
>> still necessary to establish the more basic principles (fine-grained
>> well-managed URIs, hypertext). Mention of RDF and semantic web technologies
>> too esoteric for most web developers, who only know JSON. Depending on the
>> audience, a softly-softly approach is essential, so we must calibrate our
>> discourse overall so we don’t overwhelm them until they are ready. We
>> should practice amongst ourselves, and not gratuitously talk semantics
>> until it is specifically required.
>>
>>
>>
>> I’m basically supporting Erik’s position – let’s make sure hypertext is
>> on the table first.
>>
>>
>>
>> Simon
>>
>>
>>
>> *From:* Rob Atkinson [mailto:rob@metalinkage.com.au]
>> *Sent:* Thursday, 30 July 2015 1:38 PM
>> *To:* Kerry Taylor <Kerry.Taylor@acm.org>; Rob Atkinson <
>> rob@metalinkage.com.au>
>> *Cc:* Cox, Simon (L&W, Highett) <Simon.Cox@csiro.au> <Simon.Cox@csiro.au>;
>> dret@berkeley.edu; jeremy.tandy@gmail.com; public-sdw-comments@w3.org;
>> eparsons@google.com
>>
>>
>> *Subject:* Re: adding hypermedia to spatial data best practices
>>
>>
>>
>> Do agree - i will submit a Use Case from the Hydrology domain where the
>> link semantics are critical, and not supported by an existing vocabulary.
>>
>>
>>
>> my thinking is that best practices relate to the use of RDF because we
>> can have flexibility, and make things explicit, but then we need to choose
>> one or all of:
>>
>> 1) strong but generalised semantics - for example spatial relationships
>>
>> 2) strong and domain-specific semantics required to process data in the
>> context of the domain - for example a relationship between a building and a
>> property, or between a hydrological catchment and an upstream catchment
>>
>> 3) weak semantics (where human mediation is probably required - but i
>> suppose deeper discovery of resources could be envisioned)
>>
>>
>>
>> hopefully a best practice can discuss the pros and cons of each of these,
>> provide examples and importantly shed some light on the practicalities of
>> governance of such vocabularies.  If we can indeed  fit this neatly into
>> the existing 5-star system it should provide a greater sense of how and why
>> "linked data" applies to geospatial information, and we can then perhaps
>> look at the specific case of hypermedia in this context - is it a weak
>> semantics for the link - or is it in fact supposed to support some
>> automated traversal, and if so what is required to do so.
>>
>>
>>
>> Rob
>>
>>
>>
>>
>>
>>
>>
>> On Thu, 30 Jul 2015 at 12:55 Kerry Taylor <Kerry.Taylor@acm.org> wrote:
>>
>> All,
>>
>> In linked data, the meaning of links is always explicit and
>> discoverable-- that is the fundamental reason for the use of formal
>> vocabularies. This also applies to owl:sameAs and rdf:seeAlso, although
>> quite purposefully, rdfs:seeAlso has rather weak semantics. On the other
>> hand, owl:sameAs has very tight semantics, but is very commonly used in a
>> way that violates those semantics. I doubt we can do much about the latter
>> in the broader linked data world, unfortunately.
>>
>>
>>
>> What we *can* do in this group is to advise on using linking  vocabulary
>> that is well-defined and, if we cannot find such vocabulary already,  to
>> create and define whatever is missing in the spatial space( did I really
>> write that?).   I did not see much in our use cases that suggests new
>> vocabulary is needed, except perhaps in the area of informal spatial
>> relations, where there is no geometry and maybe even very fuzzy
>> location.  I hope that our best practice advice will serve to reduce
>> confusion and encourage publishers to respect the intended semantics of the
>> vocabulary we advise.
>>
>>
>>
>> I admit to confusion about what 'hyperlinks' and related 'hypermedia'
>> means in this discussion. Is it about links between remote resources only?
>> Or about links within "media" like video, interactive maps etc ( stuff that
>> is not text or data).? In any case linked data is all about typed links ,
>> ie links with meaning, whether internal or remote.
>>
>> The fifth star does not change the meaning of the links at all,  it only
>> asks publishers to explicitly include some links to remote resources
>>
>>
>>
>> -Kerry
>>
>>
>>
>>
>> On 29 Jul 2015, at 3:38 pm, Rob Atkinson <rob@metalinkage.com.au> wrote:
>>
>> Personally, I think the relationship between "data" and "hyperlinking"
>> needs some greater care.  In a self-contained database, relationships are a
>> first-class concern - however there is a prevalence in the linked data
>> world of using ad-hoc approaches to generating hyperlinks - for example
>> using owl:sameAs to link to an interactive mapping application via
>> geographical coordinates. using very general link semantics "rdf:seeAlso"
>> for links to related data is another common pattern. The lack of a
>> demonstrably good practice is fairly hard to reconcile with any potential
>> to be able to use such links in any automated fashion, so the development
>> of best practice discussion and exemplar resources is an important step to
>> take. fortunately, the Linked Data web is still tiny compared to the
>> problem space, so there is not a huge amount invested in sub-optimal
>> approaches.
>>
>>
>>
>> I think a "star" that matters is missing - which is to make the meaning
>> of hyperlinks explicit and discoverable - this is far more useful than
>> putting the data into RDF per se, but one could argue thats the underlying
>> intent of using RDF, in that such links have URIs for link predicates - and
>> there is an implication regarding what those URIs should resolve to.  Maybe
>> there is some good practice out there somewhere of how to hyperlink without
>> losing information or adding more noise to the system we could point to -
>> but I haven't seen one in the geospatial domain.
>>
>>
>>
>> Rob Atkinson
>>
>>
>>
>>
>>
>> On Wed, 29 Jul 2015 at 11:11 <Simon.Cox@csiro.au> wrote:
>>
>> Hmm. That's interesting that you mention the coupling of 'specific model'
>> with 'linked data'. We must be careful about bringing the 5th-star into
>> play too soon. Linked data relies first on (i) stable, resolvable URIs,
>> (ii) open formats, and (iii) hyperlinks, so let's make sure that message
>> gets across first and is not buried in premature focus on semantics.
>>
>> -----Original Message-----
>> From: Erik Wilde [mailto:dret@berkeley.edu]
>> Sent: Wednesday, 29 July 2015 9:53 AM
>> To: Jeremy Tandy; public-sdw-comments@w3.org
>> Cc: Ed Parsons
>> Subject: Re: adding hypermedia to spatial data best practices
>>
>> hello jeremy.
>>
>> On 2015-07-27 02:44, Jeremy Tandy wrote:
>> > As one of the editors for the Best Practice doc, I will read through
>> > the two resources you cite in the hope that there will be less for me
>> > to write :-) ... seriously though, I will review and match your work
>> > against our formative requirements. Holiday season is upon us so rate
>> > of progress might be a little slow ...
>>
>> no worries. and seriously from my side, i'd love to get feedback and even
>> requests for more detailed content for both resources. i see a lo0t on
>> confusion in the spectrum between linked data (which mandates a specific
>> model that not everybody necessarily wants to use) and no guidance in which
>> case the hypermedia aspect (imho the biggest value proposition of the web
>> by far, when combined with REST's uniform interface constraint) often gets
>> forgotten. thus my attempt to talk about "web data" that focuses on what
>> makes the web valuable, without prescribing a specific path to realize that
>> value.
>>
>> thanks and cheers,
>>
>> dret.
>>
>> --
>> erik wilde | mailto:dret@berkeley.edu  -  tel:+1-510-2061079
>> <+1-510-2061079> |
>>             | UC Berkeley  -  School of Information (ISchool) |
>>             | http://dret.net/netdret http://twitter.com/dret |
>>
>>
>
> --
> Krzysztof Janowicz
>
> Geography Department, University of California, Santa Barbara
> 4830 Ellison Hall, Santa Barbara, CA 93106-4060
>
> Email: jano@geog.ucsb.edu
> Webpage: http://geog.ucsb.edu/~jano/
> Semantic Web Journal: http://www.semantic-web-journal.net
>
>