- From: Krzysztof Janowicz <janowicz@ucsb.edu>
- Date: Thu, 22 Oct 2015 09:06:48 -0700
- To: Jeremy Tandy <jeremy.tandy@gmail.com>, Ed Parsons <eparsons@google.com>, Andreas Harth <harth@kit.edu>, public-sdw-wg@w3.org
- Message-ID: <56290998.4020009@ucsb.edu>
> So I think this means that Features (= 'description of Things') don't > exist until we create them. Creating them requires that we discern > them. This may not always be possible. Figuring out the conditions of > what _is_ possible feels like it's outside our scope (thankfully). Exactly. In addition, it points to the fact that there are multiple ways to 'construct' features for things and thus many different features can highlight different aspects of (or viewpoints on) what is the same (or appears to be the same) thing. Best, Krzysztof On 10/22/2015 08:58 AM, Jeremy Tandy wrote: > @Krzysztof ... > > So I think this means that Features (= 'description of Things') don't > exist until we create them. Creating them requires that we discern > them. This may not always be possible. Figuring out the conditions of > what _is_ possible feels like it's outside our scope (thankfully). > > Jeremy > > > On Thu, 22 Oct 2015 at 16:29, Krzysztof Janowicz <janowicz@ucsb.edu > <mailto:janowicz@ucsb.edu>> wrote: > > 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 >> <mailto: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 <mailto:jano@geog.ucsb.edu> > Webpage:http://geog.ucsb.edu/~jano/ <http://geog.ucsb.edu/%7Ejano/> > Semantic Web Journal:http://www.semantic-web-journal.net > -- 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 16:07:22 UTC