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

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

From: Krzysztof Janowicz <janowicz@ucsb.edu>
Date: Wed, 31 Aug 2016 09:00:34 -0700
To: Joshua Lieberman <jlieberman@tumblingwalls.com>, Jeremy Tandy <jeremy.tandy@gmail.com>
Cc: Frans Knibbe <frans.knibbe@geodan.nl>, SDW WG Public List <public-sdw-wg@w3.org>
Message-ID: <e77258b6-cd2c-8459-a4a7-d72f82f99306@ucsb.edu>
Hmm. I am not sure whether I understand the issue here. The lighthouse 
(in the real world) is an obstruction and it is a navigation aid. Thus 
some lighthouses are members of multiple sets, e.g., of the set of all 
navigation aids.

> What I have seen in Linked Data is that folks don't bother to identify 
> the _representation_, they identify the thing that is being 
> represented. So in the case that different authorities mint different 
> URIs for Eddystone Lighthouse (as indicated in my example), they 
> _both_ refer to Eddystone Lighthouse (not the representation) which 
> means that <owl:sameAs> is appropriate (e.g. both identifiers refer to 
> the same resource).

Can you clarify what you mean? owl:sameAs states that two *URIs* refer 
to the same *entity* (not classes). How does representation come into 
play here?

> My problem is that in RDF Schema [1], as far as I understand, classes 
> are all about sets and set membership.

Their *interpretations* are sets.

> That’s what I’ve indicated is a possibility, but someone has to define 
> a set which are lighthouses that are members of both other sets 
> (classes), and then it takes on both sets of accompanying attributes 
> and axioms, 

You mean explicitly? No, there is no need for such a class (which you 
can define if you really want to, but it could lead to a combinatorial 
explosion).

> The use of “sameRealWorldEntityAs” would give us a weaker, but clearer 
> assertion.

Sorry, can you explain this in more detail?

Best,
Krzysztof



On 08/31/2016 08:45 AM, Joshua Lieberman wrote:
>
>> On Aug 31, 2016, at 10:51 AM, Jeremy Tandy <jeremy.tandy@gmail.com 
>> <mailto:jeremy.tandy@gmail.com>> wrote:
>>
>> @josh- following brief discussion on the call and re-reading this 
>> just now I understand your point better.
>>
>> The "spatial things" are representations; for example, "the 
>> lighthouse in the real world seen as a vertical obstruction" and "the 
>> lighthouse in the real world seen as a maritime navigation aid" - and 
>> it takes some additional assessment to determine that the "lighthouse 
>> in the real world" for both is, in fact, the same lighthouse - this 
>> is what we've described as "reconciliation".
>>
>> My problem is that in RDF Schema [1], as far as I understand, classes 
>> are all about sets and set membership. So Eddystone lighthouse can be 
>> a member both classes because it has the requisite properties that 
>> qualify it as a "vertical obstruction" and a "maritime navigation 
>> aid". What I have seen in Linked Data is that folks don't bother to 
>> identify the _representation_, they identify the thing that is being 
>> represented. So in the case that different authorities mint different 
>> URIs for Eddystone Lighthouse (as indicated in my example), they 
>> _both_ refer to Eddystone Lighthouse (not the representation) which 
>> means that <owl:sameAs> is appropriate (e.g. both identifiers refer 
>> to the same resource).
>
> That’s what I’ve indicated is a possibility, but someone has to define 
> a set which are lighthouses that are members of both other sets 
> (classes), and then it takes on both sets of accompanying attributes 
> and axioms, which may or may not be consistent with each other. 
> owl:sameAs is ambiguous, so it isn’t clear that it can clearly mean 
> “different information resources and conceptualization, but same real 
> world entity”. The use of “sameRealWorldEntityAs” would give us a 
> weaker, but clearer assertion.
>
> This is only really an issue in special cases. In other cases the 
> discerned feature is the same, but two different classes may have been 
> defined and so both the indirect identity of the real world entity and 
> use of owl:sameAs is clear. It’s precisely the tendency of “folks” to 
> conflate everything together, data, geometry, concept, real world 
> thing, that works most of the time but gets into huge trouble once in 
> a while.
>
> Josh
>
>>
>> [ that makes sense to me, but I wonder if I'm the lone member of the 
>> RDF class that understands what I'm trying to say :-) ]
>>
>> If this doesn't make sense - or I'm just plain wrong, then let's have 
>> a call tomorrow ... skype, hangouts or what ever takes your fancy.
>>
>> @frans-
>>
>> > So I would need to have a different URI for my triangle [and my SVG 
>> file].
>>
>> Yes. I guess that the triangle might be 
>> <http://example.com/shapes/my-triangle> and the SVG file 
>> <http://example.com/shapes/my-triangle.svg>; some HTTP server config 
>> might be used to serve the SVG file when a user agent requests 
>> <http://example.com/shapes/my-triangle>.
>>
>> Regarding Req. 5.45 "subject equality" [2] ("There should be a 
>> recommended way to express that data based on different models are 
>> about the same real world spatial thing."), I think that both 
>> approaches would suffice. @josh's approach retains a little more 
>> indirection, mine seems to follow what I see in Linked Data practice.
>>
>> [1]: https://www.w3.org/TR/rdf-schema/
>> [2]: 
>> http://w3c.github.io/sdw/UseCases/SDWUseCasesAndRequirements.html#SubjectEquality 
>>
>>
>> On Wed, 31 Aug 2016 at 14:40 Joshua Lieberman 
>> <jlieberman@tumblingwalls.com <mailto:jlieberman@tumblingwalls.com>> 
>> wrote:
>>
>>     Jeremy,
>>
>>     So as representations, these are not “owl:sameAs”. We assume that
>>     as feature data, each refers to a real world entity, but we don’t
>>     assert that this VerticalObstruction is the same individual as
>>     this MaritimeNavigationAid. We just are suspecting or asserting
>>     that the same real world thing is being discerned in two
>>     different ways. Someone may define a lighthouse class as
>>     subclassing both, otherwise a slightly specialized relation (e.g.
>>     sdwgeo:sameRealWorldEntityAs) would be useful here.
>>
>>     Josh
>>
>>>     On Aug 31, 2016, at 8:41 AM, Jeremy Tandy
>>>     <jeremy.tandy@gmail.com <mailto:jeremy.tandy@gmail.com>> wrote:
>>>
>>>     > 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.
>>>
>>>     @josh - can we clarify my understanding please?
>>>
>>>     In the BP doc §4 "Spatial things, features and geometry" [1] I
>>>     use a lighthouse example, so I'll continue with that ...
>>>
>>>     We have one real lighthouse (Eddystone Lighthouse) that is
>>>     discerned as a different Type by different communities:
>>>     "VerticalObstruction" and "MaritimeNavigationAid". In ISO 19100
>>>     parlance, these are two distinct feature types. The two
>>>     "Features" might be encoded in GML as follows (forgive any
>>>     errors in my illustrative example):
>>>
>>>     <VerticalObstruction gml:id="a">
>>>     <gml:name>Eddystone</gml:name>
>>>         <gml:identifier
>>>     codeSpace="http://example.com/sar/features/vo/">EDY</gml:identifier
>>>     <http://example.com/sar/features/vo/%22%3EEDY%3C/gml:identifier>>
>>>         <geometry>
>>>             <gml:Point gml:id="a-p1" srsDimension="2"
>>>     srsName="EPSG:4326">
>>>     <gml:pos>50.184 -4.268</gml:pos>
>>>             </gml:Point>
>>>         </geometry>
>>>         <height uom="m">41</height>
>>>     </VerticalObstruction>
>>>
>>>     <MaritimeNavigationAid gml:id="b">
>>>         <gml:name>Eddystone Lighthouse</gml:name>
>>>         <gml:identifier
>>>     codeSpace="http://example.org/maritime/navaid/">2650253</gml:identifier>
>>>         <geo>
>>>             <gml:Point gml:id="b-p1" srsDimension="2"
>>>     srsName="EPSG:4326">
>>>     <gml:pos>50.2 -4.3</gml:pos>
>>>             </gml:Point>
>>>         </geo>
>>>     <lightCharacteristic>
>>>             ...
>>>     </lightCharacteristic>
>>>     </MaritimeNavigationAid>
>>>
>>>     So we have two Features (which we collectively have agreed are
>>>     "spatial things"), with identifiers
>>>     <http://example.com/sar/features/vo/EDY> and
>>>     <http://example.org/maritime/navaid/2650253>. Respectively, the
>>>     XML elements that describe these features are identified as "a"
>>>     and "b" using the @gml:id attribute.
>>>
>>>     If we are using "indirect identification" then _both_
>>>     <http://example.com/sar/features/vo/EDY> and
>>>     <http://example.org/maritime/navaid/2650253> are treated as
>>>     identifiers for the _real_ Eddystone Lighthouse; we simply don't
>>>     care to differentiate between the real world thing and the
>>>     information record. In which case, <owl:sameAs>  would seem
>>>     sufficient? The "height" and "lightCharacteristic" properties
>>>     are both applicable to the real Eddystone Lighthouse. Some
>>>     judgement would be required to decide which point geometry
>>>     ("geo" or "geometry" property) is considered "best".
>>>
>>>     The way I think about it, @gml:id is more like the identifier
>>>     for a named graph; a container for a set of properties ...
>>>
>>>     Am I missing something???
>>>
>>>     Jeremy
>>>
>>>
>>>     [1]:
>>>     http://w3c.github.io/sdw/bp/#spatial-things-features-and-geometry
>>>
>>>     On Wed, 31 Aug 2016 at 12: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. 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.
>>>
>>>         Josh
>>>
>>>         Joshua Lieberman, Ph.D.
>>>         Principal, Tumbling Walls Consultancy
>>>         Tel/Direct: +1 617-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
>>>>>                             >>
>>>>>                             >> [6]:
>>>>>                             https://www.w3.org/TR/urls-in-data/#documenting-properties
>>>>>                             >>
>>>>>                             >> [7]:
>>>>>                             https://www.w3.org/TR/urls-in-data/#authoring-specifications
>>>>>                             >>
>>>>>                             >>
>>>>>                             >>
>>>>>                             >>
>>>>>                             >
>>>>>
>>>>>                             --
>>>>>
>>>>>
>>>>>                             Phil Archer
>>>>>                             W3C Data Activity Lead
>>>>>                             http://www.w3.org/2013/data/
>>>>>
>>>>>                             http://philarcher.org
>>>>>                             <http://philarcher.org/>
>>>>>                             +44 (0)7887 767755
>>>>>                             <tel:%2B44%20%280%297887%20767755>
>>>>>                             @philarcher1
>>>>>
>>>>
>>
>


-- 
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 Wednesday, 31 August 2016 16:01:16 UTC

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