- From: Rob Atkinson <rob@metalinkage.com.au>
- Date: Fri, 02 Sep 2016 22:13:35 +0000
- To: Rob Atkinson <rob@metalinkage.com.au>, janowicz@ucsb.edu, Frans Knibbe <frans.knibbe@geodan.nl>
- Cc: Joshua Lieberman <jlieberman@tumblingwalls.com>, Jeremy Tandy <jeremy.tandy@gmail.com>, SDW WG Public List <public-sdw-wg@w3.org>
- Message-ID: <CACfF9Lx+fEEuWjX8f0gYTt4g6SxQcwWu6gkmU+HE_f6f9EKWKw@mail.gmail.com>
@jeremy RE SIRF and LDA SIRF really just looked at the LDA implementation and explored how it would need to work in a federated environment with typically locally scoped and non-unique naming. At this stage, the underlying concerns motivating that are being addressed individually, and we dont need to worry about its status. I dont think there are widely adopted best practices - however there are widespread inadequate practices hence the need for a WG. i think its a useful step forward if the BP can address with an example how URI naming should be done, and note that there is an unmet _requirement_ for discovering and accessing multiple representations using a canonical approach On Sat, 3 Sep 2016 at 08:04 Rob Atkinson <rob@metalinkage.com.au> wrote: > > A few things - this is a rich discussion and we have identified several > parts (which is probably why the original issue was hard to pin down) > > I'm glad we have coaxed one elephant out - the sameAs semantics issue. > For me this is the litmus test whether a URL can be used as a URI for a > thing or not. > > (and this is where one of the issues about SIRF Jeremy raised comes in - > but I dont think we need to worry about specific approach, rather the > criteria for whether a URI is a good one for identification purposes. I > think we simply make a strong statement that you dont use a URL as a URI if > it is not stable and it does not make sense to use owl:sameAs. > This pretty much rules out any direct URL to a single representation: > > consider two resources with URIs R1 and R2 > > R1 ns:dateEdited 12/1/2001 > > R2 ns:dateEdited 6/6/2006 > > R1 owl:sameAs R2 then leads to ambiguity regarding the value of the > functional property ns:dateEdited > > however > > U1 --303--> R1 > U2 --303--> R2 > > can (and should be) represented as > U1 ns:hasRepresentation R1 > U2 ns:hasRepresentation R2 > > U1 owl:sameAS U2 > entails > U1 ns:hasRepresentation R1, R2 > > which doesnt make any stupid statements about the properties. It also > allows us to make useful metadata statements about R1, R2 as required. > > Whilst this is a general concern, we see issues of identification > stability, multiple representations, non-unique naming being significant to > spatial data and I think we can and should therefore extend the general > DWBP with an example using spatial representations and provide a more > concrete best practice. > > > > > > > > > On Sat, 3 Sep 2016 at 00:40 Krzysztof Janowicz <janowicz@ucsb.edu> wrote: > >> I am no expert on the matter, but several sources tell me that if <A> >> <owl:sameAs> <B>, then all statements that can be made about A will also be >> true for B, and vice versa. It seems that the lighthouse example breaks at >> that point. For example, in Jeremy's example one of the lighthouse >> representations has a height of 41 m. It is likely that that statement will >> be false for the representation of the lighthouse as a ruin. >> >> Can we be sure that if we recommend using owl:sameAs to assert that two >> resources are really the same thing, everyone and everything is aware of >> the logical consequences? >> >> >> This is exactly the key point. If A owl:sameAs B than A and B signify the >> same entity and thus every *statement* about A is a statement about B. It >> works well with Jeremy's example. The fact that the ruin no longer is 41m >> tall is an example of the need for spatiotemporal scoping of predicates not >> a shortcoming of owl:sameAs. Also, keep in mind that RDF statements have >> nothing to do with facts or truth; they are just sets of statements. This >> is were the power of RDF comes from. >> >> Best, >> Krzysztof >> >> >> >> >> On 09/02/2016 02:20 AM, Frans Knibbe wrote: >> >> >> On 1 September 2016 at 23:42, Krzysztof Janowicz <janowicz@ucsb.edu> >> wrote: >> >>> >>> Hi, >>> >>> So as representations, these are not “owl:sameAs”. >>> >>> >>> >>> Just for clarification. owl:sameAs is only concerned with the mapping of >>> IRIs to (real world) entities and not 'representations' (leaving aside the >>> fact that everything is a representation in some sense). I.e., it is about >>> 'identity'. To give an extreme example, a URI may refer to the Eddystone >>> Lighthouse which may be classified as /Lighthouse/ in some repository. >>> Another URI established 50 years from now can still refer to this >>> particular (4th) lighthouse and classify it as a /Ruin/. Another 50 years >>> into the future, there may be yet another URI that refers to the fact that >>> at some stage there was a ruin here of the 4th lighthouse called Eddystone >>> while there is nothing physical left of it, and, thus, it is neither >>> classified as /Ruin/ nor /Lighthouse/. In fact, we do not even need to >>> introduce the concept of "real world" here as we can also establish a >>> sameAs relation between two URIs that point to Zeus. Please note that this >>> is different from establish a sameAs link between a particular statue of >>> Zeus in a particular museum and Zeus as the god of thunder. Finally, the >>> purpose of establishing sameAs links is typically data fusion/conflation >>> (no matter whether this is done ad-hoc, manually, or (offline) >>> computationally) . >>> >> >> I am no expert on the matter, but several sources tell me that if <A> >> <owl:sameAs> <B>, then all statements that can be made about A will also be >> true for B, and vice versa. It seems that the lighthouse example breaks at >> that point. For example, in Jeremy's example one of the lighthouse >> representations has a height of 41 m. It is likely that that statement will >> be false for the representation of the lighthouse as a ruin. >> >> Can we be sure that if we recommend using owl:sameAs to assert that two >> resources are really the same thing, everyone and everything is aware of >> the logical consequences? >> >> Regards, >> Frans >> >> >> >>> >>> Best, >>> Jano >>> >>> >>> On 08/31/2016 06:38 AM, Joshua Lieberman 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> >>> 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> >>> <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> 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 <%2B1%20617-431-6431> >>>> jlieberman@tumblingwalls.com >>>> >>>> On Aug 31, 2016, at 07:29, Frans Knibbe <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> >>>> wrote: >>>> >>>>> Thanks Rob & Clemens ... >>>>> >>>>> On Wed, 31 Aug 2016 at 08:30, Clemens Portele < >>>>> portele@interactive-instruments.de> wrote: >>>>> >>>>>> +1 >>>>>> >>>>>> >>>>>> On 30 August 2016 at 10:10:26, Jeremy Tandy (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> 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] >>>>>>> *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> >>>>>>> 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> 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> >>>>>>> > 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] >>>>>>> >> *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> >>>>>>> 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> >>>>>>> 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" 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 >>>>>>> >> >>>>>>> >>>>>>>
Received on Friday, 2 September 2016 22:14:22 UTC