W3C home > Mailing lists > Public > public-sdw-wg@w3.org > September 2016

Re: Clarification required: BP6 "use HTTP URIs for spatial things"

From: Krzysztof Janowicz <janowicz@ucsb.edu>
Date: Thu, 1 Sep 2016 20:20:15 -0700
To: Jeremy Tandy <jeremy.tandy@gmail.com>, Rob Atkinson <rob@metalinkage.com.au>, Joshua Lieberman <jlieberman@tumblingwalls.com>, Frans Knibbe <frans.knibbe@geodan.nl>
Cc: SDW WG Public List <public-sdw-wg@w3.org>
Message-ID: <c33ba7c1-24aa-eb4b-6ae2-18690f46979c@ucsb.edu>
> Yes. I'll admit to not following the 'reification' bit of your 
> discussion completely, but this is how I see things working in 
> practice. The user agent (client) identifies the Resource that they 
> want (using the URI) and provides a bit of context for their 
> preferences (commonly language and format). The server then determines 
> what is the best information payload that it can provide in response 
> ... and if the URI identified a physical entity such as Eddystone 
> Lighthouse then obviously the HTTP response has to be an information 
> resource describing Eddystone Lighthouse - we don't yet have the Star 
> Trek teleporter technology to return concrete, steel and other 
> physical atoms!
>

This link is very useful: https://www.w3.org/TR/swbp-vocab-pub/.




On 09/01/2016 08:44 AM, Jeremy Tandy wrote:
> Hi Rob - thanks for illustrating your concerns.
>
> You've already voted +1 for using "indirect identifiers" for spatial 
> things which helps me split out some of the issues you raise.
>
> I think your concerns are about how URIs are actually resolved in 
> practice. Clemens raised similar concerns in his earlier email [1].
>
> > URI + some client-defined context  -> a resource that the server 
> believes meets the context requirements
>
> Yes. I'll admit to not following the 'reification' bit of your 
> discussion completely, but this is how I see things working in 
> practice. The user agent (client) identifies the Resource that they 
> want (using the URI) and provides a bit of context for their 
> preferences (commonly language and format). The server then determines 
> what is the best information payload that it can provide in response 
> ... and if the URI identified a physical entity such as Eddystone 
> Lighthouse then obviously the HTTP response has to be an information 
> resource describing Eddystone Lighthouse - we don't yet have the Star 
> Trek teleporter technology to return concrete, steel and other 
> physical atoms!
>
> FWIW, the report from Geonovum's Geo4web-testbed Topic 3 provides some 
> useful commentary on content negotiation strategies [2]
>
> > So - if we have two FeatureTypes (Vert.Obstruction) and (Nav..) then 
> we have two scenarios we need to cover:
> >
> > 1) U -> {R1, R2)
> > 2) U1 -> R1, U2 -> R2, U1 = U2
>
> In case #1 you raise valid concerns about the limitations of content 
> negotiation. These concerns were also identified in Geo4web-testbed 
> Topic 4: "Content negotiation based on media types insufficient" [3]. 
> It says that content negotiation is "unable to support selection of 
> different schemas (e.g. schema.org <http://schema.org> for the search 
> engines vs DCAT for governmental data portals)".
>
> In your stated example, how does one ask for a particular 
> representation; R1 or R2?
>
> BTW: I think that this is similar to the motivation that drives Erik 
> Wilde's "profile" Link Relation Type proposal (RFC 6906) [4]
>
> Imagine I'm using the Google Knowledge Graph ID for Eddystone 
> Lighthouse <https://g.co/kg/m/013qr8> how could I say "please tell me 
> about Eddystone Lighthouse seen as a vertical obstruction" (rather 
> than as a maritime navigation aid) because that's what my application 
> needs.
>
> The Linked Data API (LDA) provides a solution in the form of "views" 
> [5]. One can configure an LDA server to expose named views; these are 
> accessed using a URL query parameter (e.g. "?_view="myNamedView"). The 
> LDA server uses a SPARQL Construct statement to select only those 
> properties that are relevant to the named view when creating the HTTP 
> response.
>
> What I don't see in the LDA is any canonical mechanism to advertise or 
> describe the set of named views available from a particular server so 
> that a client application knows what they can request - but it's 
> possible I missed this. I think that you described these as "reified 
> bindings of U to R1...n".
>
> >In summary - as an implementer who now understands the probIem I have 
> a small number of questions:
> >
> > 1) in the latter case is BP to declare U1 owl:sameAs U2?  If not - 
> what is the predicate ?
>
> I think <owl:sameAs> is correct.
>
> > 2) what is the appropriate predicate for the  U predicate R1 ?
>
> Taking the practice from LDA, they (or at least Epimorpics' "ELDA" 
> implementation [6]) use <foaf:isPrimaryTopicOf>, so for my lighthouse 
> example, I might state:
>
> <https://g.co/kg/m/013qr8> foaf:isPrimaryTopicOf 
> <https://g.co/kg/m/013qr8?_view=vertical-obstruction>
>
> And there's the inverse <foaf:primaryTopic> if you want to assert in 
> the other direction.
>
> (I'm a bit rusty on the Linked Data API - I hope I got that right!)
>
> > 3) How do I share the context (i.e. those reified bindings of U to 
> R1...n) so a client can understand them
>
> I think that this is an area where best practice doesn't exist - and 
> accordingly we should flag this as a potential interoperability bear-trap.
>
> Jeremy
>
> PS: I think that this discussion is highly relevant to the BP doc, but 
> suspect that it better fits in §10.6 Spatial Data Access [7] rather 
> than within the BP about identifiers.
>
> [1]: https://lists.w3.org/Archives/Public/public-sdw-wg/2016Aug/0152.html
> [2]: https://github.com/geo4web-testbed/topic3/wiki/Content-negotiation
> [3]: http://geo4web-testbed.github.io/topic4/#h.n0gkernttzw0
> [4]: https://tools.ietf.org/html/rfc6906
> [5]: 
> https://github.com/UKGovLD/linked-data-api/blob/wiki/API_Viewing_Resources.md#specialised-viewers 
>
> [6]: http://www.epimorphics.com/web/tools/elda.html
> [7]: http://w3c.github.io/sdw/bp/#bp-exposing-via-api
>
> On Wed, 31 Aug 2016 at 23:24 Rob Atkinson <rob@metalinkage.com.au 
> <mailto:rob@metalinkage.com.au>> wrote:
>
>
>     Important we have this in depth discussion and reach consensus -
>     because its impossible to expect a wider audience to arrive at a
>     usefully common view without guidance.
>
>     This stuff is out there, so its not a theoretical discussion. but
>     some of the practices conflate things in a way that makes data
>     hard to integrate.
>
>     There are a couple of practical implications I havent seen fully
>     addressed, yet would need to be highlighted IMHO:
>
>      One mechanism in widespread use is that the URI for the 'thing'
>      redirects to a URL for a resource about the thing.  Lets call
>      these U & R.   What is important to recognise here is that the
>     relationship between U and R is mediated by conneg... In the case
>     of the UK Linked Data example, it may be further mediated by
>     additonal parameters within the Web architecture.
>
>     So the information content is always URI + some client-defined
>     context  -> a resource that the server believes meets the context
>     requirements.
>
>     At the very least U -> { R1, R2,R3...}
>
>     -> can be seen as some type of property relationship - so this
>     behaviour can be automated or also stated in a useful way
>
>     U hasRepresentation R1
>
>     or perhaps reified
>
>     { subject U, object R1, predicate hasRepresentation, type
>     aFeatureType, label "X', dct:hasFormat "image/svg" }
>
>     The reified case makes it obvious that the "client defined
>     context" can be matched to the properties of the relationship -
>     however this logic is just as likely to be implemented in the
>     conneg or API layer, thats a contract between client and server
>     which is part of the broader Web architecture - for now let us
>     focus on whether the functionality required can be met by the
>     available information...
>
>     now if  U1 -> R and U2 -> R then both U1 and U2 may have the same
>     set of properties in this case
>
>     X owl:SameAs Y  states that the properties of X apply to Y and
>     vice versa. There are other implications here as well
>
>     he value constraintowl:hasValue
>     <http://www.w3.org/TR/2004/REC-owl-semantics-20040210/#owl_hasValue>is
>     a built-in OWL property that links a restriction class to a value
>     V, which can be either anindividual
>     <https://www.w3.org/TR/owl-ref/#Individual>or adata value
>     <https://www.w3.org/TR/owl-ref/#Datatype>. A restriction
>     containing a|owl:hasValue|constraint describes a class of all
>     individuals for which the property concerned has at least one
>     value/semantically/equal to V (it may have other values as well).
>
>     NOTE: for datatypes "semantically equal" means that the lexical
>     representation of the literals maps to the same value. For
>     individuals it means that they either have the same URI reference
>     or are defined as being the same individual (seeowl:sameAs
>     <https://www.w3.org/TR/owl-ref/#sameAs-def>).
>
>     So I beleive they key thing here is to provide guidance to those
>     unfamiliar with the semantics underpinnings to not break things
>     and given them a simple way forward.
>
>     So - if we have two FeatureTypes (Vert.Obstruction) and (Nav..)
>     then we have two scenarios we need to cover:
>
>     1) U -> {R1, R2)
>     2) U1 -> R1, U2 -> R2, U1 = U2
>
>     In summary - as an implementer who now understands the probIem I
>     have a small number of questions:
>
>     1) in the latter case is BP to declare U1 owl:sameAs U2?  If not -
>     what is the predicate ?
>
>     2) what is the appropriate predicate for the  U predicate R1 ?
>
>     3) How do I share the context (i.e. those reified bindings of U to
>     R1...n) so a client can understand them
>
>     If we cannot nail down the terms to use now, then I believe we
>     need to state in the BP that a mechanism needs to be chosen to
>     address these specific concerns according to the principles of
>     re-use - but I also suggest we flag this as a critical "must
>     solve" issue for the communities we would suggest pointing users to.
>
>     Rob
>
>
>     On Thu, 1 Sep 2016 at 03:13 Krzysztof Janowicz <janowicz@ucsb.edu
>     <mailto:janowicz@ucsb.edu>> wrote:
>
>         Thanks for the clarification.
>
>
>         On 08/31/2016 09:22 AM, Jeremy Tandy wrote:
>>         @josh
>>
>>         > Is the triangle spatial data or a graphic with drawing
>>         instructions that assumes a certain technology? If 100 people
>>         print out the SVG, there is really nothing to indicate that
>>         the underlying entity is the same on each piece of paper,
>>         just that the same instructions were used, unless we want to
>>         get into trademark issues.
>>
>>         This seems to be getting away from the main topic. Unless you
>>         object, can I pull us back?
>>
>>         @Krzysztof
>>
>>         Apologies if my terminology is confusing.
>>
>>         I was trying to say that <owl:sameAs> indicates that two
>>         identifiers (URIs, in this case
>>         <http://example.com/sar/features/vo/EDY> and
>>         <http://example.org/maritime/navaid/2650253>) refer to the
>>         same entity (Eddystone Lighthouse). You said it much better
>>         than me.
>>
>>         The term "representation" was drawn from @josh's email text;
>>         in which he meant "Eddystone Lighthouse seen as a vertical
>>         obstruction" and "Eddystone Lighthouse seen as a maritime
>>         navigation aid".
>>
>>         >there is no need for such a class [whose members are both
>>         vertical obstructions and maritime navigation aids] (which
>>         you can define if you really want to, but it could lead to a
>>         combinatorial explosion)
>>
>>         I agree. This is what I've seen with Linked Data
>>         implementations - which means that "sameRealWorldEntityAs" is
>>         not required.
>>
>>         Hmmm. I hope I'm not confusing myself and everyone else.
>>
>>         Jeremy
>>
>>         On Wed, 31 Aug 2016 at 17:02 Joshua Lieberman
>>         <jlieberman@tumblingwalls.com
>>         <mailto:jlieberman@tumblingwalls.com>> wrote:
>>
>>>             On Aug 31, 2016, at 10:20 AM, Frans Knibbe
>>>             <frans.knibbe@geodan.nl <mailto:frans.knibbe@geodan.nl>>
>>>             wrote:
>>>
>>>
>>>
>>>             On 31 August 2016 at 13:42, Joshua Lieberman
>>>             <jlieberman@tumblingwalls.com
>>>             <mailto:jlieberman@tumblingwalls.com>> wrote:
>>>
>>>                 If we are asserting that spatial data on the Web is
>>>                 "always" feature data that represents a real world
>>>                 entity, then yes, we don't have the general Web "is
>>>                 it or isn't it physical" ambiguity and can assume
>>>                 that a feature data identifier also and indirectly
>>>                 identifies the feature.
>>>
>>>
>>>             I hope we can broaden that assumption, that the
>>>             assertion still holds even if we are not talking about
>>>             feature data representing real world entities.
>>>
>>>             Let's look at a border case: I am drawing a triangle in
>>>             Inkscape and I save it as a *.svg file. I publish the
>>>             file on the web, so it has a URI. Now I would say the
>>>             triangle is a spatial thing (not sure if it counts as a
>>>             real world entity, but I hope we can leave the idea of
>>>             'real world' out of definitions anyway). The SVG object
>>>             in the file is the geometry describing the spatial
>>>             thing. I think that only if we understand the SVG file
>>>             to be the spatial thing we get into trouble. I might
>>>             want to state that the file has a certain size and that
>>>             the triangle has a certain area. It would be funny if I
>>>             used the same URI for both statements. So I would need
>>>             to have a different URI for my triangle. Could that be all?
>>
>>             Is the triangle spatial data or a graphic with drawing
>>             instructions that assumes a certain technology? If 100
>>             people print out the SVG, there is really nothing to
>>             indicate that the underlying entity is the same on each
>>             piece of paper, just that the same instructions were
>>             used, unless we want to get into trademark issues.
>>
>>>                 That still leaves a gap in expressing whether two
>>>                 feature data entities represent the same real world
>>>                 entity. Perhaps we need a "sameFeatureAs" predicate
>>>                 to address this.
>>>
>>>
>>>             Yes, that is what the Subject equality
>>>             <http://w3c.github.io/sdw/UseCases/SDWUseCasesAndRequirements.html#SubjectEquality>
>>>             requirement is about. So the BP document is expected to
>>>             say something about that.
>>>
>>>             Regards,
>>>             Frans
>>>
>>>
>>>                 Josh
>>>
>>>                 Joshua Lieberman, Ph.D.
>>>                 Principal, Tumbling Walls Consultancy
>>>                 Tel/Direct: +1 617-431-6431 <tel:%2B1%20617-431-6431>
>>>                 jlieberman@tumblingwalls.com
>>>                 <mailto:jlieberman@tumblingwalls.com>
>>>
>>>                 On Aug 31, 2016, at 07:29, Frans Knibbe
>>>                 <frans.knibbe@geodan.nl
>>>                 <mailto:frans.knibbe@geodan.nl>> wrote:
>>>
>>>>                 Hello,
>>>>
>>>>                 As stated before, I don't think the httpRange-14
>>>>                 problem exists in our domain of discourse. I think
>>>>                 (and hope) that confusion can only occur when the
>>>>                 things that are described are digital things, or
>>>>                 things that can be transmitted over a computer
>>>>                 network, like web pages or mail boxes. It seems to
>>>>                 me that spatial things are never that type of
>>>>                 thing. Therefore there is no reason to take
>>>>                 precautions against possible confusion.
>>>>
>>>>                 That probably means +1.
>>>>
>>>>                 Greetings,
>>>>                 Frans
>>>>
>>>>
>>>>                 On 31 August 2016 at 09:50, Jeremy Tandy
>>>>                 <jeremy.tandy@gmail.com
>>>>                 <mailto:jeremy.tandy@gmail.com>> wrote:
>>>>
>>>>                     Thanks Rob & Clemens ...
>>>>
>>>>                     On Wed, 31 Aug 2016 at 08:30, Clemens Portele
>>>>                     <portele@interactive-instruments.de
>>>>                     <mailto:portele@interactive-instruments.de>> wrote:
>>>>
>>>>                         +1
>>>>
>>>>
>>>>                         On 30 August 2016 at 10:10:26, Jeremy Tandy
>>>>                         (jeremy.tandy@gmail.com
>>>>                         <mailto:jeremy.tandy@gmail.com>) wrote:
>>>>
>>>>>                         Hi. It would be good to close this issue
>>>>>                         out & include our collective
>>>>>                         recommendation in the BP doc working draft.
>>>>>
>>>>>                         PROPOSAL: SDW working group recommends use
>>>>>                         of "indirect identifiers" for spatial things
>>>>>
>>>>>                         ... I'll start the voting.
>>>>>
>>>>>                         +1
>>>>>
>>>>>                         Jeremy
>>>>>
>>>>>                         (BTW, to make sense of the PROPOSAL you'll
>>>>>                         need to read the email thread)
>>>>>
>>>>>                         On Fri, 26 Aug 2016 at 10:12 Linda van den
>>>>>                         Brink <l.vandenbrink@geonovum.nl
>>>>>                         <mailto:l.vandenbrink@geonovum.nl>> wrote:
>>>>>
>>>>>                             So… do we agree we can recommend
>>>>>                             indirect identifiers, or do we try to
>>>>>                             fix the issue with getting the correct
>>>>>                             identifier as Rob describes?
>>>>>
>>>>>
>>>>>                             While waiting for this I’ve updated
>>>>>                             the issue and the text referring to
>>>>>                             the issue in BP6.
>>>>>
>>>>>
>>>>>                             *Van:* Rob Atkinson
>>>>>                             [mailto:rob@metalinkage.com.au
>>>>>                             <mailto:rob@metalinkage.com.au>]
>>>>>                             *Verzonden:* woensdag 24 augustus 2016
>>>>>                             13:56
>>>>>                             *Aan:* Jeremy Tandy; Phil Archer;
>>>>>                             Linda van den Brink; Bill Roberts
>>>>>
>>>>>
>>>>>                             *CC:* SDW WG Public List
>>>>>
>>>>>                             *Onderwerp:* Re: Clarification
>>>>>                             required: BP6 "use HTTP URIs for
>>>>>                             spatial things"
>>>>>
>>>>>
>>>>>                             Hi
>>>>>
>>>>>
>>>>>                             Agree this is a real concern - people
>>>>>                             cant be blamed for doing the obvious,
>>>>>                             if dumb, thing..
>>>>>
>>>>>
>>>>>                             I think we should take note of best
>>>>>                             practice in the HTML world - which is
>>>>>                             often to include a citable link to a
>>>>>                             resource in the rendered view.  Or a
>>>>>                             "share" or something similar. We can
>>>>>                             also put fairly explicit annotation in
>>>>>                             machine-readable code - stating that
>>>>>                             the resource is about the URI - and
>>>>>                             even notes saying when citing this
>>>>>                             resource use the URI....
>>>>>
>>>>>
>>>>>                             I'd also like to see browsers evolve
>>>>>                             to offer you the original link or the
>>>>>                             redirected when cutting and pasting -
>>>>>                             how hard can it be!
>>>>>
>>>>>
>>>>>                             Maybe we can get Ed to ask around
>>>>>                             Google Chrome team for suggestions on
>>>>>                             how best to handle this :-)
>>>>>
>>>>>
>>>>>                             Rob
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>                             On Wed, 24 Aug 2016 at 18:27 Jeremy
>>>>>                             Tandy <jeremy.tandy@gmail.com
>>>>>                             <mailto:jeremy.tandy@gmail.com>> wrote:
>>>>>
>>>>>                                 Yes, I think so ... And we should
>>>>>                                 do so if we are recommending
>>>>>                                 "indirect identification".
>>>>>
>>>>>                                 Jeremy
>>>>>
>>>>>                                 On Wed, 24 Aug 2016 at 09:24, Phil
>>>>>                                 Archer <phila@w3.org
>>>>>                                 <mailto:phila@w3.org>> wrote:
>>>>>
>>>>>                                     Bill's comments also made me
>>>>>                                     think about some of the
>>>>>                                     classic arguments,
>>>>>                                     such as that a lake doesn't
>>>>>                                     have a last updated date and
>>>>>                                     isn't 435KB
>>>>>                                     big. Which are true, however,
>>>>>                                     that kind of metadata
>>>>>                                     generally comes from
>>>>>                                     the server, i.e. the HTTP
>>>>>                                     layer. That's an over
>>>>>                                     simplification but the
>>>>>                                     point is that it is relatively
>>>>>                                     easy to avoid deliberately
>>>>>                                     creating
>>>>>                                     misleading metadata - metadata
>>>>>                                     about the doc rather than the
>>>>>                                     thing it
>>>>>                                     describes - and it's also
>>>>>                                     generally easy to avoid
>>>>>                                     looking for that metadata.
>>>>>
>>>>>                                     Is there scope for some BP
>>>>>                                     advice there?
>>>>>
>>>>>                                     Phil.
>>>>>
>>>>>                                     On 24/08/2016 08:25, Jeremy
>>>>>                                     Tandy wrote:
>>>>>                                     > Thanks Linda. More clear
>>>>>                                     examples where being "correct"
>>>>>                                     (in terms of
>>>>>                                     > avoiding uri collisions by
>>>>>                                     using two distinct uris) is
>>>>>                                     making things worse
>>>>>                                     > because users take the wrong
>>>>>                                     one!
>>>>>                                     >
>>>>>                                     > So, as a WG, are we content
>>>>>                                     to recommend this "indirect
>>>>>                                     identification"
>>>>>                                     > pattern where thing & info
>>>>>                                     resource identifiers are
>>>>>                                     conflated?
>>>>>                                     >
>>>>>                                     > Bill has added some good
>>>>>                                     points about how to avoid
>>>>>                                     impacts of uri
>>>>>                                     > collision- by using the
>>>>>                                     (dataset) metadata to talk
>>>>>                                     about licenses and
>>>>>                                     > creators for the information ...
>>>>>                                     > On Wed, 24 Aug 2016 at
>>>>>                                     07:52, Linda van den Brink
>>>>>                                     <l.vandenbrink@geonovum.nl
>>>>>                                     <mailto:l.vandenbrink@geonovum.nl>>
>>>>>                                     > wrote:
>>>>>                                     >
>>>>>                                     >> Experience from the
>>>>>                                     Netherlands: we have the
>>>>>                                     id/doc pattern in our URI
>>>>>                                     >> strategy, based on the Cool
>>>>>                                     URIs note [8] and the ISA
>>>>>                                     study on persistent
>>>>>                                     >> identifiers [9].
>>>>>                                     >>
>>>>>                                     >>
>>>>>                                     >>
>>>>>                                     >> That being said, same as
>>>>>                                     Bill I also notice data users
>>>>>                                     getting confused
>>>>>                                     >> and generally using the
>>>>>                                     /doc/  URI as that is the one
>>>>>                                     they can copy from
>>>>>                                     >> their browser address bar.
>>>>>                                     This is not only casual
>>>>>                                     confusion but also ends
>>>>>                                     >> up in published information
>>>>>                                     resources.
>>>>>                                     >>
>>>>>                                     >>
>>>>>                                     >>
>>>>>                                     >> You see this, for example,
>>>>>                                     all over the CB-NL which is a
>>>>>                                     vocabulary for
>>>>>                                     >> the building sector and
>>>>>                                     contains links to other Dutch
>>>>>                                     standards such as
>>>>>                                     >> IMGeo, an information model
>>>>>                                     and vocabulary for large scale
>>>>>                                     topography. E.g.
>>>>>                                     >> the CB-NL concept of
>>>>>                                     ‘Gebouw’ (Building) [10] 
>>>>>                                     links to two IMGeo concepts
>>>>>                                     >> ‘Pand’ (building part) and
>>>>>                                     ‘Overig Bouwwerk’ (other
>>>>>                                     construction) using
>>>>>                                     >> their /doc/ URIs. If you
>>>>>                                     click on Pand (which doesn’t
>>>>>                                     have its own landing
>>>>>                                     >> page in CB-NL so I can’t
>>>>>                                     include the link) you will see
>>>>>                                     it includes the
>>>>>                                     >> /doc/  URI as the
>>>>>                                     identifier of Pand.
>>>>>                                     >>
>>>>>                                     >>
>>>>>                                     >>
>>>>>                                     >> This is an example where it
>>>>>                                     occurs in vocabularies, but I
>>>>>                                     also see it
>>>>>                                     >> happen with identifiers for
>>>>>                                     data instances.
>>>>>                                     >>
>>>>>                                     >>
>>>>>                                     >>
>>>>>                                     >> [8]:
>>>>>                                     https://www.w3.org/TR/cooluris/
>>>>>                                     >>
>>>>>                                     >> [9]:
>>>>>                                     >>
>>>>>                                     https://joinup.ec.europa.eu/sites/default/files/D7.1.3%20-%20Study%20on%20persistent%20URIs_0.pdf
>>>>>                                     >> 10:
>>>>>                                     http://ont.cbnl.org/cb/def/Gebouw
>>>>>                                     >>
>>>>>                                     >>
>>>>>                                     >>
>>>>>                                     >> Linda
>>>>>                                     >>
>>>>>                                     >>
>>>>>                                     >>
>>>>>                                     >> *Van:* Jeremy Tandy
>>>>>                                     [mailto:jeremy.tandy@gmail.com
>>>>>                                     <mailto:jeremy.tandy@gmail.com>]
>>>>>                                     >> *Verzonden:* dinsdag 23
>>>>>                                     augustus 2016 20:57
>>>>>                                     >> *Aan:* Bill Roberts
>>>>>                                     >> *CC:* SDW WG Public List
>>>>>                                     >> *Onderwerp:* Re:
>>>>>                                     Clarification required: BP6
>>>>>                                     "use HTTP URIs for spatial
>>>>>                                     >> things"
>>>>>                                     >>
>>>>>                                     >>
>>>>>                                     >>
>>>>>                                     >> Thanks Bill. Sounds very
>>>>>                                     coherent ... I hoped for some
>>>>>                                     responses such as
>>>>>                                     >> this based on practical
>>>>>                                     experience. Jeremy
>>>>>                                     >>
>>>>>                                     >> On Tue, 23 Aug 2016 at
>>>>>                                     19:41, Bill Roberts
>>>>>                                     <bill@swirrl.com
>>>>>                                     <mailto:bill@swirrl.com>> wrote:
>>>>>                                     >>
>>>>>                                     >> ah Jeremy, you are a brave
>>>>>                                     man to poke the sleeping beast
>>>>>                                     of httpRange-14.
>>>>>                                     >>
>>>>>                                     >>
>>>>>                                     >>
>>>>>                                     >> But I'll get my thoughts in
>>>>>                                     early, then I can tune out of
>>>>>                                     the ensuing mail
>>>>>                                     >> avalanche :-)
>>>>>                                     >>
>>>>>                                     >>
>>>>>                                     >>
>>>>>                                     >> When publishing Linked Data
>>>>>                                     about places we (at Swirrl)
>>>>>                                     generally do the
>>>>>                                     >> id/doc fandango, but to be
>>>>>                                     honest I think data users
>>>>>                                     either don't notice,
>>>>>                                     >> or they get confused by
>>>>>                                     it.  In the applications we
>>>>>                                     are working with (and I
>>>>>                                     >> acknowledge that others may
>>>>>                                     have different applications
>>>>>                                     and different
>>>>>                                     >> experiences), it wouldn't
>>>>>                                     cause any problems to have a
>>>>>                                     single URI, the 'id'
>>>>>                                     >> URI if you like. We just
>>>>>                                     don't find a need to say
>>>>>                                     anything about the /doc/
>>>>>                                     >> URI. If we were starting
>>>>>                                     again, I'd probably ditch the
>>>>>                                     /doc/ and the 303
>>>>>                                     >> and rely on context and a
>>>>>                                     little bit of documentation to
>>>>>                                     make it clear what
>>>>>                                     >> we mean.
>>>>>                                     >>
>>>>>                                     >>
>>>>>                                     >>
>>>>>                                     >> The place where we find a
>>>>>                                     need to talk about creators
>>>>>                                     and licences and
>>>>>                                     >> modified dates is in
>>>>>                                     metadata about datasets where
>>>>>                                     a dataset might be a
>>>>>                                     >> collection of information
>>>>>                                     about a bunch of places - and
>>>>>                                     we treat datasets
>>>>>                                     >> as an 'information
>>>>>                                     resource'. If someone requests
>>>>>                                     a dataset URI we return a
>>>>>                                     >> status code of 200 and the
>>>>>                                     dataset metadata as the
>>>>>                                     response. That metadata
>>>>>                                     >> includes info on where to
>>>>>                                     get all the contents of the
>>>>>                                     dataset if you want
>>>>>                                     >> that.
>>>>>                                     >>
>>>>>                                     >>
>>>>>                                     >>
>>>>>                                     >> By the way, though it's
>>>>>                                     sensible and consistent, I
>>>>>                                     find that the implied
>>>>>                                     >> and parallel property stuff
>>>>>                                     makes it more rather than less
>>>>>                                     complicated.
>>>>>                                     >>
>>>>>                                     >>
>>>>>                                     >>
>>>>>                                     >> Bill
>>>>>                                     >>
>>>>>                                     >>
>>>>>                                     >>
>>>>>                                     >>
>>>>>                                     >>
>>>>>                                     >>
>>>>>                                     >>
>>>>>                                     >>
>>>>>                                     >>
>>>>>                                     >>
>>>>>                                     >>
>>>>>                                     >>
>>>>>                                     >>
>>>>>                                     >> On 23 August 2016 at 17:37,
>>>>>                                     Jeremy Tandy
>>>>>                                     <jeremy.tandy@gmail.com
>>>>>                                     <mailto:jeremy.tandy@gmail.com>>
>>>>>                                     wrote:
>>>>>                                     >>
>>>>>                                     >> All-
>>>>>                                     >>
>>>>>                                     >>
>>>>>                                     >>
>>>>>                                     >> Linda has done a great job
>>>>>                                     of consolidating the best
>>>>>                                     practices are use of
>>>>>                                     >> identifiers. We have just
>>>>>                                     one [1] now.
>>>>>                                     >>
>>>>>                                     >>
>>>>>                                     >>
>>>>>                                     >> Reading though just now, it
>>>>>                                     occurred to me that there's
>>>>>                                     still an open
>>>>>                                     >> issue about identifier
>>>>>                                     assignment ...
>>>>>                                     >>
>>>>>                                     >>
>>>>>                                     >>
>>>>>                                     >> W3C's Architecture of the
>>>>>                                     World Wide Web constraint
>>>>>                                     "URIs identify a
>>>>>                                     >> single resource" [2]
>>>>>                                     asserts "Assign distinct URIs
>>>>>                                     to distinct resources"
>>>>>                                     >> in order to avoid URI
>>>>>                                     collisions [2a] which "often
>>>>>                                     imposes a cost in
>>>>>                                     >> communication due to the
>>>>>                                     effort required to resolve
>>>>>                                     ambiguities".
>>>>>                                     >> Discussions from earlier
>>>>>                                     years in UK Gov Linked Data
>>>>>                                     working group (and
>>>>>                                     >> elsewhere) concluded that
>>>>>                                     the "real world thing" and
>>>>>                                     "information resource
>>>>>                                     >> that describes the real
>>>>>                                     world thing" are separate
>>>>>                                     resources. I think this
>>>>>                                     >> is based on a (purist?)
>>>>>                                     view when working with RDF of
>>>>>                                     needing to be totally
>>>>>                                     >> clear on "what's the
>>>>>                                     subject" of each triple ...
>>>>>                                     the thing or the document.
>>>>>                                     >> This manifests as URIs with
>>>>>                                     `id` or `doc` included
>>>>>                                     somewhere to distinguish
>>>>>                                     >> between the resources and
>>>>>                                     some RDF triples to clarify
>>>>>                                     that the doc resource
>>>>>                                     >> is talking about the thing
>>>>>                                     resource etc..
>>>>>                                     >>
>>>>>                                     >>
>>>>>                                     >>
>>>>>                                     >> (dangerously close to
>>>>>                                     "httpRange-14" [3] here ...
>>>>>                                     let's avoid that bear
>>>>>                                     >> trap)
>>>>>                                     >>
>>>>>                                     >>
>>>>>                                     >>
>>>>>                                     >> Jeni Tennison's "URLs in
>>>>>                                     Data Primer" draft TAG note
>>>>>                                     captures this
>>>>>                                     >> practice in §5.3
>>>>>                                     "Publishing data" [4]:
>>>>>                                     >>
>>>>>                                     >>
>>>>>                                     >>
>>>>>                                     >> ```
>>>>>                                     >>
>>>>>                                     >> Publishers can help enable
>>>>>                                     more accurate merging of data
>>>>>                                     from different
>>>>>                                     >> sites if they support URLs
>>>>>                                     for each entity
>>>>>                                     >>
>>>>>                                     <https://www.w3.org/TR/urls-in-data/#dfn-entity>
>>>>>                                     they or other sites may
>>>>>                                     >> wish to describe, separate
>>>>>                                     from the landing pages
>>>>>                                     >>
>>>>>                                     <https://www.w3.org/TR/urls-in-data/#dfn-landing-page>
>>>>>                                     or records
>>>>>                                     >>
>>>>>                                     <https://www.w3.org/TR/urls-in-data/#dfn-record>
>>>>>                                     that they publish.
>>>>>                                     >>
>>>>>                                     >> ```
>>>>>                                     >>
>>>>>                                     >>
>>>>>                                     >>
>>>>>                                     >> Yet Architecture of the
>>>>>                                     World Wide Web §2.2.3
>>>>>                                     "Indirect identification"
>>>>>                                     >> [5] notes that:
>>>>>                                     >>
>>>>>                                     >>
>>>>>                                     >>
>>>>>                                     >> ```
>>>>>                                     >>
>>>>>                                     >> To say that the URI
>>>>>                                     "mailto:nadia@example.com
>>>>>                                     <mailto:nadia@example.com>"
>>>>>                                     identifies both an
>>>>>                                     >> Internet mailbox and Nadia,
>>>>>                                     the person, introduces a URI
>>>>>                                     collision.
>>>>>                                     >> However, we can use the URI
>>>>>                                     to indirectly identify Nadia.
>>>>>                                     Identifiers are
>>>>>                                     >> commonly used in this way.
>>>>>                                     >>
>>>>>                                     >> ```
>>>>>                                     >>
>>>>>                                     >>
>>>>>                                     >>
>>>>>                                     >> This is consistent with
>>>>>                                     what I recall TimBL saying at
>>>>>                                     TPAC-2015 in regards
>>>>>                                     >> to Vcard; come the finish,
>>>>>                                     no one really cares to
>>>>>                                     distinguish between the
>>>>>                                     >> thing and its associated
>>>>>                                     information resource.
>>>>>                                     >>
>>>>>                                     >>
>>>>>                                     >>
>>>>>                                     >> ... And in most cases, one
>>>>>                                     can use context to determine
>>>>>                                     whether a
>>>>>                                     >> statement concerns the
>>>>>                                     thing or the information
>>>>>                                     resource. In those cases
>>>>>                                     >> where you can't, "URLs in
>>>>>                                     Data Primer" suggests some
>>>>>                                     mechanisms to mitigate
>>>>>                                     >> such confusion [6][7].
>>>>>                                     >>
>>>>>                                     >>
>>>>>                                     >>
>>>>>                                     >> I think that in our SDW WG
>>>>>                                     discussion we have concluded
>>>>>                                     that we _are_
>>>>>                                     >> content to use "indirect
>>>>>                                     identification" - e.g. that we
>>>>>                                     use URIs that
>>>>>                                     >> conflate the thing and
>>>>>                                     document resource.
>>>>>                                     >>
>>>>>                                     >>
>>>>>                                     >>
>>>>>                                     >> Please can we confirm this?
>>>>>                                     Assuming that indirect
>>>>>                                     identification is
>>>>>                                     >> "approved" as best
>>>>>                                     practice, then it seems
>>>>>                                     prudent to add a note to the BP
>>>>>                                     >> document saying "don't
>>>>>                                     worry about distinguishing
>>>>>                                     between thing and
>>>>>                                     >> resource; indirect
>>>>>                                     identification is fine" (etc.)
>>>>>                                     >>
>>>>>                                     >>
>>>>>                                     >>
>>>>>                                     >> Thanks, Jeremy
>>>>>                                     >>
>>>>>                                     >>
>>>>>                                     >>
>>>>>                                     >> [1]:
>>>>>                                     http://w3c.github.io/sdw/bp/#globally-unique-ids
>>>>>                                     >>
>>>>>                                     >> [2]:
>>>>>                                     https://www.w3.org/TR/webarch/#pr-uri-collision
>>>>>                                     >>
>>>>>                                     >> [2a]:
>>>>>                                     https://www.w3.org/TR/webarch/#URI-collision
>>>>>                                     >>
>>>>>                                     >> [3]:
>>>>>                                     https://www.w3.org/2001/tag/group/track/issues/14
>>>>>                                     >>
>>>>>                                     >> [4]:
>>>>>                                     https://www.w3.org/TR/urls-in-data/#publishing-data
>>>>>                                     >>
>>>>>                                     >> [5]:
>>>>>                                     https://www.w3.org/TR/webarch/#indirect-identification
>>>>>                                     >>
>>>>>                                     >
>>>>>


-- 
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
Received on Friday, 2 September 2016 03:20:50 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:31:25 UTC