- 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