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:26:00 -0700
To: Rob Atkinson <rob@metalinkage.com.au>, 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: <578c2d59-b868-4d2b-775c-abbdc2da8e8b@ucsb.edu>
> we need to make a very clear statement that geo "Features" are things 
> that have comparable URIs - but instances of "FeatureTypes" are 
> representations that are related. These representations are properties 
> of the Feature that may be combined using  using owl:sameAs between 
> the Features, but not the representation (FeatureType) instances

I have to admit that I do not understand what this means. Can somebody 
clarify it? What is a 'comparable' URI? What does it mean for 
'representations' to be 'related'? Aren't instances of FeatureType(s) 
features?




On 09/01/2016 03:06 PM, Rob Atkinson wrote:
>
> Circling in on a resolution here I hope :-)
>
> from what I am seeing -
>
> we need to make a very clear statement that geo "Features" are things 
> that have comparable URIs - but instances of "FeatureTypes" are 
> representations that are related. These representations are properties 
> of the Feature that may be combined using  using owl:sameAs between 
> the Features, but not the representation (FeatureType) instances
>
> There is practice 'in the wild" to use foaf as a vocabulary for the 
> relationship.  Do we recommend this, or leave it free.  Do we specify 
> that whatever relationship is used is a subProperty of 
> foaf:primaryTopicOf  ?
>
> And finally, there is probably no established best practice for 
> providing discovery of available bindings - and we should flag this as 
> something that should be addressed - a missing BP against requirements
>
> There is evidence its at least feasible conforming to the vocabuary 
> reuse BP -   for example a graph based mainly on VoiD can be made 
> available as an extra representation using the IANA "alternates" 
> relationshp  c.f. in the SIRF project 
> (http://environment.data.gov.au/water/id/catchment/100862?_view=alternates&_format=html - 
> notwithstanding that the resources are woefully maintained now :-( 
> Very sad as there was even a link checker that exploited this view 
> available! )
>
> Rob
>
> On Fri, 2 Sep 2016 at 07:42 Krzysztof Janowicz <janowicz@ucsb.edu 
> <mailto: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) .
>
>     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 <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"
>>>>>


-- 
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:26:33 UTC

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