the term I have been using is 'service profile' - i.e. how a set of users expect a service to behave
Context matches the OGC generalisation of a WMS context. It sort of relates more to an invocation than a configuration though IMHO so, if you take the context to be the user-centric viewpoint of collections of resources which together are useful: a service profile supports one or more user contexts, consisting of a ordered set of invocations based on protocol bindings to presentations (eg styling or formats) of the result of operations (filters) against resources whew! complicated but at least its a consistent set of terms that don't seem too far from the status quo. With a WMS, the ordered set provides value by building a map from layers. In a WFS, its traversal of a nested graph of related features to answer a particular question or get specific data. WCS is arguable a special case of WFS with functions, with more interest in the value range than relationship between feature types. Rob On Tue, Jun 30, 2009 at 3:51 PM, Justin Deoliveira<jdeol...@opengeo.org> wrote: > I agree that the terminology "map" is confusing. I like the terminology > of "service" and "protocol" as it describes more accurately what the > technical entities actually are, although the term service is quite tied > to the idea of OGC services and I fear using it in this way would result > in even more confusion. > > You did bring up the term "context" to replace "map" which I kind of > liked as well. > > Jody Garnett wrote: >> So I finally sorted out the catalogue trinity last week in Perth - due >> to a good update on the Resource/Publishing split from Justin last >> week. >> >> I am still stuck on the naming of things but progress has been made ... >> - Workspace - basically folders for DataStores; no real significance >> in terms of publication of data >> - Maps - this defines how publication happens; the only thing >> significant in terms of publication of data >> - Profile - sets logging level and other application preferences/settings >> >> My earlier confusion came from thinking the above concepts were tied >> together (like you could publish the same map twice using different >> workspaces). Instead I find they are a trinity each seperated from the >> other that together form the geoserver configuration. >> >> With this in mind: >> - Maps are still a very difficult name - but they do each represent a >> public "GeoServer" with as many OGC services enabled as needed. >> - It would be *so* nice to refer to Map above as a "Service" and refer >> to enabling/disabling the various WMS/WFS/WCS things as "Protocols" >> enabled for that service. Out of all the naming ideas this one made >> the most sense; indeed once we step beyond OGC (with REST etc..>) it >> becomes even more clear. >> - The concept of a Map is is exactly what RobA was calling a "profile" >> (so that one could publish a profile for INSPIRE complete with the >> correct FeatureTypes; Styles and so on) which could be downloaded and >> added to your geoserver configuration. Backing this profile onto your >> own data would be the interesting part. >> - The current association of namespace to workspace was causing a lot >> of trouble for people; offering lots of opportunities for confusion. >> >> Jody >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> Geoserver-devel mailing list >> Geoserver-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/geoserver-devel > > > -- > Justin Deoliveira > OpenGeo - http://opengeo.org > Enterprise support for open source geospatial. > > ------------------------------------------------------------------------------ > _______________________________________________ > Geoserver-devel mailing list > Geoserver-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geoserver-devel > ------------------------------------------------------------------------------ _______________________________________________ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
