- From: Krzysztof Janowicz <janowicz@ucsb.edu>
- Date: Thu, 22 Oct 2015 08:28:15 -0700
- To: Ed Parsons <eparsons@google.com>, Andreas Harth <harth@kit.edu>, public-sdw-wg@w3.org
- Message-ID: <5629008F.7020907@ucsb.edu>
Hi, > So... Can we imagine situations where a "thing" does not have an > associated "feature" ? > > Perhaps when we deal with the vague colloquial places ? > as features are abstractions / representations, I would argue that most "things" out there do not have "features". If the question is whether certain things cannot have features at all, it becomes more complicated. There are probably some good arguments that can be made on the grounds of human cognition, state of knowledge, and limits of what can be observed. Best, Krzysztof On 10/22/2015 04:30 AM, Ed Parsons wrote: > > So... Can we imagine situations where a "thing" does not have an > associated "feature" ? > > Perhaps when we deal with the vague colloquial places ? > > Ed > > > On Thu, 22 Oct 2015 12:16 Andreas Harth <harth@kit.edu > <mailto:harth@kit.edu>> wrote: > > Hi, > > why do you call an information resource/graph a "feature"? > > They way you use that terminology does not have anything to do > with spatial data. > > In your terminology, we would have: > > * http://harth.org/andreas/foaf.rdf#ah - identifying the thing/me > as a person > * http://harth.org/andreas/foaf.rdf - identifying the feature (?) > > Calling an information resource (in the Linked Data sense)/graph/ > RDF document a "Feature" is a bad idea. > > In NeoGeo, we use "Feature" for the spatial thing [1]. My impression > was that GeoSPARQL did something similar. I don't have access to the > definition of "GFI_Feature" of ISO 19156:2011 though. > > So the following classes would be roughly equivalent (namespaces via > prefix.cc): > * spatial:Feature > * geosparql:Feature > * dcterms:Location > * wgs84:SpatialThing > > Cheers, > Andreas. > > [1] http://geovocab.org/spatial#Feature > > On 10/22/2015 11:39, Simon.Cox@csiro.au wrote: > > >> Does that mean that if I want to express this in RDF, I need > three > > URIs? One for the real-world-thing, one for the feature and one > for the > > feature representation? > > > > ØHopefully you're a little less confused. In my mind we have > just two URIs: > > > > oURI identifying 'Thing' > > > > oURI identifying 'description of Thing' / 'Feature' / 'graph' > > > > It is also OK to have distinct URIs for the concrete > > representation/serialization/format of the feature. > > > > Conventionally this is often the URI for the feature with a > suffix like > > .rdf, .xml, .ttl appended (as an alternative to http conneg). > > > > e.g. > > > > http://places.net/thing/eddystone-lighthouse is a URI denoting a > thing > > in the world > > > > http://example.org/feature/eddystone-lighthouse is the URI for a > feature > > > > http://example.org/feature/eddystone-lighthouse.xml > > http://example.org/feature/eddystone-lighthouse.ttl are URIs for > > different serializations of the feature, so > > > > http://example.org/feature/eddystone-lighthouse foaf:primaryTopic > > http://places.net/thing/eddystone-lighthouse . > > > > http://example.org/feature/eddystone-lighthouse prv:serializedBy > > http://example.org/feature/eddystone-lighthouse.xml > > > > http://example.org/feature/eddystone-lighthouse.xml dct:hasFormat > > http://example.org/feature/eddystone-lighthouse.ttl . > > > > However, to a dumb URI consumer, which has no conception of > ‘suffix’, > > these are different URIs. > > > > Simon > > > > *From:*Jeremy Tandy [mailto:jeremy.tandy@gmail.com > <mailto:jeremy.tandy@gmail.com>] > > *Sent:* Thursday, 22 October 2015 8:30 PM > > *To:* Svensson, Lars <L.Svensson@dnb.de > <mailto:L.Svensson@dnb.de>>; Joshua Lieberman > > <jlieberman@tumblingwalls.com <mailto:jlieberman@tumblingwalls.com>> > > *Cc:* public-sdw-wg@w3.org <mailto:public-sdw-wg@w3.org> > > *Subject:* Re: Does 'Feature' = 'Real World Thing'? > > > > All- many thanks again for contributions to this topic! I think > that we > > have a resolution- or at least sufficient resolution for us to > move forward. > > > > @Clemens ... you said: > > > > > there is no concept that would support using the same > identifier for > > both features [...]. A feature instance is of exactly one > feature type, > > it cannot be of the feature type "light house" from application > schema A > > and "vertical obstruction" of application schema B. > > > > I think that this relates to the frame-based _information_ modelling > > approach used for creating Application Schema. And yes- this is > > different to the approach taken with RDF. > > > > @Simon ... based on going back to the spec, you conclude: > > > > > the term ‘Feature’ clearly refers to the abstraction, > information, > > data. [... So we must] Use ‘Thing’ for the real-world (including > > fictional) thing, and ‘feature’ for an information object that > describes > > it, according to some viewpoint. > > > > > regarding Jeremy’s ‘what is the subject’ question, a case > could be > > made for using a URI for the real-world thing as the subject in RDF > > statements in all cases, regardless of the model or > ‘feature-type’ in > > use, while the set of statements relating to a specific viewpoint > > (feature-type) comprises a graph. The URI for a graph identifies the > > ‘feature’, while the URI for a thing in the world can be subject of > > statements from all viewpoints. > > > > +1 from me. This is the conclusion that I had also reached ... > > > > 1. We identify the real-world (including fictional) Thing. > > 2. We identify a collection of statements (e.g. a graph) that > describe > > the Thing according to a given perspective; the Feature. The > Thing > > is the subject of the statements. > > > > This works for me. > > > > Regarding point (2) it's worth noting that (at least from my > pov) it is > > best practice for Application Schema to be solely concerned with the > > conceptual model (the 'universe of discourse'); attributes of > the Thing > > that are deemed important in the application domain. That said, > I often > > see Application Schema with Feature Types that conflate the > 'Thing' and > > 'Feature' (aka information resource) subjects so that the > collection of > > properties defined by the Feature Type are a mixture of those > that talk > > about the 'Thing' (e.g. height; an instance might assert height > = 37ft > > ... this is clearly about the 'Thing') and those that are > metadata about > > the 'Feature' (information object) itself (e.g. creation date, last > > update time, license, owner, maintainer etc.). This makes it very > > difficult to merge data from such instances of those Feature Types > > because the subject isn't clear. > > > > [OK- if that passed you by, don't worry] > > > > @Josh ... you said: > > > > > We can happen to recognize two things that have close the same > > spatial extent (and temporal extent). That doesn’t make them the > same > > “thing”. [...] We learn something by interpreting the > collocation, just > > as layering features in a map brings insight. > > > > Indeed. Collocation is a useful indicator but, by itself, is often > > insufficient to determine 'sameness'. > > > > If we apply Simon's proposal that the 'Thing' is the subject of the > > statements in the Feature, two (or more) Features may use the same > > 'Thing' as their subject. This is an explicit assertion of > sameness and > > is achieved either by both Features using the same identifier > for their > > subject, or by using the 'sameAs' assertion to say that the two > > identifiers actually refer to the same Thing. These are very strong > > assertions, not to be taken lightly. > > > > Regarding the reconciliation of data that is apparently talking > about > > the same thing, Ed previously said "here be dragons" [1]. > > > > @Lars ... > > > > > Does that mean that if I want to express this in RDF, I need > three > > URIs? One for the real-world-thing, one for the feature and one > for the > > feature representation? > > > > Hopefully you're a little less confused. In my mind we have just > two URIs: > > > > * URI identifying 'Thing' > > * URI identifying 'description of Thing' / 'Feature' / 'graph' > > > > Why two URIs? Why can't we just have one? It's clear that we > have two > > resources: the 'Thing' and 'description of Thing'. The Web > Architecture > > [2] (that we agreed forms a foundational aspect of our best > practice) > > states: > > > > */Constraint: URIs Identify a Single Resource/* > > > > Assign distinct URIs to distinct resources. > > > > Furthermore, the need to treat 'Thing' and 'description of Thing' as > > disjoint resources is the subject of W3C URLs in Data Primer [3]. > > 'Feature' is synonymous with the term 'Record' [4] defined therein. > > > > Section 4 'Documenting Properties' [5] notes that: > > > > "A data format that mixes properties about [...] records and > properties > > about the things those [...] records describe is not necessarily > > ambiguous: all that's required for developers to understand what the > > properties actually apply to is for the meaning of the property > to be > > documented." > > > > This is exactly the situation we have with many existing (GML) > > Application Schema. URLs in Data proposes how to declare which > property > > is which type. Section 5.3 'Publishing Data' [6] says that: > > > > "Publishers can help enable more accurate merging of data from > different > > sites if they support URLs for each entity > > <http://www.w3.org/TR/urls-in-data/#dfn-entity> they or other > sites may > > wish to describe, separate from the [...]records > > <http://www.w3.org/TR/urls-in-data/#dfn-record> that they publish." > > > > So it's best two have 2 URIs; one for each of Thing and Feature. > > > > Jeremy > > > > [1]: > http://lists.w3.org/Archives/Public/public-sdw-wg/2015Sep/0059.html > > > > [2]: http://www.w3.org/TR/webarch/#id-resources > > > > [3]: http://www.w3.org/TR/urls-in-data/ > > > > [4]: http://www.w3.org/TR/urls-in-data/#dfn-record > > > > [5]: http://www.w3.org/TR/urls-in-data/#documenting-properties > > > > [6]: http://www.w3.org/TR/urls-in-data/#publishing-data > > > > On Thu, 22 Oct 2015 at 07:37 Svensson, Lars <L.Svensson@dnb.de > <mailto:L.Svensson@dnb.de> > > <mailto:L.Svensson@dnb.de <mailto:L.Svensson@dnb.de>>> wrote: > > > > On Wednesday, October 21, 2015 10:38 PM, Joshua Lieberman wrote: > > [...] > > > > [Clemens] > > > > But first of all, the feature is an information object > > describing a real-world > > > thing. > > > > > > That's consistent with the definition of Spatial Object in > > INSPIRE. Restated: > > > • Feature != Real-World Thing > > > • Feature = Information Resource that _describes_ > Real-World Thing > > > @Josh, @Simon: can you confirm this meets your expectations? > > > > [Josh] > > > Almost. There are two feature statements needed to get > from the > > world to > > > spatial data: > > > > > > 1. Feature = discernment of a type of Real-World Thing (as > > distinct from Not > > > Thing) > > > 2. Feature Data = representation of a Feature (as an > information > > resource) > > > > Does that mean that if I want to express this in RDF, I need > three > > URIs? One for the real-world-thing, one for the feature and > one for > > the feature representation? > > > > Best, > > > > Lars (who starts to feel confused...) > > > > > -- > > *Ed Parsons* > Geospatial Technologist, Google > > Google Voice +44 (0)20 7881 4501 > www.edparsons.com <http://www.edparsons.com> @edparsons > -- 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 Thursday, 22 October 2015 15:28:49 UTC