Response to INSPIRE Metadata Draft - Revision history

Wiki-JoWalsh: /* General esponses that are harder to "fit" but should be offered. */

2007-03-30T18:13:23Z

General esponses that are harder to "fit" but should be offered.

Wiki-JoWalsh: /* Responses that are hard to "fit" but should be offered. */

2007-03-30T15:06:28Z

Responses that are hard to "fit" but should be offered.

Wiki-JoWalsh: /* Responses */ ian's standalone suggestions

2007-03-30T14:59:21Z

Responses: ian's standalone suggestions

Wiki-JoWalsh: another batch of jan's suggestions

2007-03-30T14:34:49Z

another batch of jan's suggestions

Wiki-JoWalsh at 21:48, 28 March 2007

2007-03-28T21:48:53Z

Wiki-JoWalsh: added another batch. needs one more pass.

2007-03-28T21:48:20Z

added another batch. needs one more pass.

Wiki-JoWalsh at 18:26, 28 March 2007

2007-03-28T18:26:06Z

Wiki-JoWalsh: /* Responses */

2007-03-27T01:27:59Z

Responses

Wiki-JoWalsh: this is a start but is only 1/3 the way through the points

2007-03-27T01:11:31Z

this is a start but is only 1/3 the way through the points

Wiki-JoWalsh at 22:19, 26 March 2007

2007-03-26T22:19:21Z

@@ Line 102: / Line 102: @@
 |}
-== General esponses that are harder to "fit" but should be offered. ==
+== General responses that are harder to "fit" but should be offered. ==
 {|
@@ Line 110: / Line 110: @@
 | 5.3.2 || || T || 5.2.2. Talks about what I would expect to see from a temporal reference, but 5.3.2 maps temporal reference on to "One of the dates of publication, last revision or creation of the resource". These three elements are already well defined by Dublin Core attributes... Maybe I've misunderstood whats implied by table 1 in 5.3.2. Also, similar issues to the spatial access point arise (With structured data, as opposed to text queries). In some UK datasets, periods such as "Neolithic" can be used instead of an ISO 19108 Date Time. (I seen note 11 under 5.3.4 talks about this, which is good. Whats important is that regardless of the outcome of the study, the IR are extensible enough to cope with the eventual decision). I'd consider seperate access points for controlled vocabulary time period and structured temporal data. This seems a specific example where the abstract IR model needs to go beyond what is defined in the A2 binding || What is indicated by a Temporal Reference should be consistent between 5.2.2 and 5.3.2, or clearer examples offered in the Annexes.
 |-
-| A || || T || I'm interested in what the expected semantics of resource language are on retrieval of language-neutral data sets.... Should a result record not be selected because the user specified "Nor" as the search language, but resources matching other criteria (Geo Extent for example) do match. Normally in Info Retrieval this is a no-brainer, of course it shouldn't, but I'm a bit less certain when we talk about result records that aren't primarily "Text" based. (Actually, this is a slightly wider concern about Annex A and those "CharacterString" elements... In IEEE LOM for example we have "LangString" element that has a "Lang" attribute. That community chose to allow language variants of a resource to be expressed within one record by allowing an element to hold all language variants, for example
+| A || || T || What are the expected semantics of resource language are on retrieval of language-neutral data sets.... Should a result record not be selected because the user specified "Nor" as the search language, but resources matching other criteria (Geo Extent for example) do match. Normally in Info Retrieval the answer is "no", but this is less clear when result records aren't primarily "Text" based. (Actually, this is a slightly wider concern about Annex A and those "CharacterString" elements... In IEEE LOM for example we have "LangString" element that has a "Lang" attribute. That community chose to allow language variants of a resource to be expressed within one record by allowing an element to hold all language variants. The presence of a "Lang" attribute at the "Dataset" level might mean the intention is to support multi-language datasets by having several dataset records, one for each language, which is OK, but possibly not optimal for datasets that aren't prmarily language based. If this is the case, is the "CharacterString" element in Annex A just redundant payload?) || Add a treatment in Annex I that describes the specifics of search across multi-language elements; reconsider the expression of multilanguage CharacterStrings in the light of information retrieval best practise (see comment on this change)

@@ Line 102: / Line 102: @@
 |}
-== Responses that are hard to "fit" but should be offered. ==
+== General esponses that are harder to "fit" but should be offered. ==
 {|

← Older revision		Revision as of 14:59, 30 March 2007
Line 101:		Line 101:
	\|4.1 \|\| Note 6, Paragraph 2 \|\| T \|\| "Services, including web services, are routinely measured in terms of availability and performance. These parameters are easily quantified and users can easily agree on their value: services that are available more often (seeking the elusive 99.9% "up-time") are more desirable than services that are available less often, and services that provide faster response time are more desirable than similar services that are slower to respond.". This is not exact. When a user wants to use a service he must know more than about availability and speed of the service. For example cost, quality of used geodata, used algorithms, quality of used algorithms, possibility of chaining, quality of self-description of the process, development, update, security, type of call (synchronous x asynchronous). \|\| Expand the description of service quality to include a more useful metric than uptime and response speed.		\|4.1 \|\| Note 6, Paragraph 2 \|\| T \|\| "Services, including web services, are routinely measured in terms of availability and performance. These parameters are easily quantified and users can easily agree on their value: services that are available more often (seeking the elusive 99.9% "up-time") are more desirable than services that are available less often, and services that provide faster response time are more desirable than similar services that are slower to respond.". This is not exact. When a user wants to use a service he must know more than about availability and speed of the service. For example cost, quality of used geodata, used algorithms, quality of used algorithms, possibility of chaining, quality of self-description of the process, development, update, security, type of call (synchronous x asynchronous). \|\| Expand the description of service quality to include a more useful metric than uptime and response speed.
	\|}		\|}
		+
		+	== Responses that are hard to "fit" but should be offered. ==
		+
		+	{\|
		+	\|-
		+	\| 5.2 \|\| \|\| T \|\| Section 5.2 "Discovery metadata elements" starts to set out a list of concepts seen to be (The document hints at, but does not directly say) core to the discovery process. Section 5.3 then sets out "Abstract discovery metadata element set". I guess the implication is that the concepts laid out in 5.2 are in some way even more abstract than those set out in 5.3. The document really isn't clear about what the abstract model is, or what it is for, before it starts enumerating the concepts. Your later comment about being tied to web services is spot on also here, I'm really not sure "Service type version", "Operation name" and "Distributed computing platform" belong in an abstract discovery model (The probably do belong in some result record schema). These three attributes seem to belong specifically to a particular service binding (Or as already said, to a very specific kind of returned result record). What I'd really like to see is a much clearer statement of what the purpose of the abstract discovery model is. Hopefully, once that is tightly defined, it should become easier to decide what lies inside the boundary of the abstract model, and what belongs in the domain of specific realisations of the abstract model. In the information retrieval community generally, it's considered really important to have a seperate abstract model for discovery (The search access points) and then bind that model on to as many backend schemas as needed.. this decoupling is seen as best practice in the information retrival domain, and most of my concerns here are that because of the apparent 1:1 mapping between the abstract model and the implementation. This is the approach taken in the [[Z3950 GEO profile] http://www.blueangeltech.com/standards/GeoProfile/geo22.htm] \|\| Add an explanation, or a reference to coverage in the discovery services draft, of the abstract discovery model.
		+	\|-
		+	\| 5.3.2 \|\| \|\| T \|\| 5.2.2. Talks about what I would expect to see from a temporal reference, but 5.3.2 maps temporal reference on to "One of the dates of publication, last revision or creation of the resource". These three elements are already well defined by Dublin Core attributes... Maybe I've misunderstood whats implied by table 1 in 5.3.2. Also, similar issues to the spatial access point arise (With structured data, as opposed to text queries). In some UK datasets, periods such as "Neolithic" can be used instead of an ISO 19108 Date Time. (I seen note 11 under 5.3.4 talks about this, which is good. Whats important is that regardless of the outcome of the study, the IR are extensible enough to cope with the eventual decision). I'd consider seperate access points for controlled vocabulary time period and structured temporal data. This seems a specific example where the abstract IR model needs to go beyond what is defined in the A2 binding \|\| What is indicated by a Temporal Reference should be consistent between 5.2.2 and 5.3.2, or clearer examples offered in the Annexes.
		+	\|-
		+	\| A \|\| \|\| T \|\| I'm interested in what the expected semantics of resource language are on retrieval of language-neutral data sets.... Should a result record not be selected because the user specified "Nor" as the search language, but resources matching other criteria (Geo Extent for example) do match. Normally in Info Retrieval this is a no-brainer, of course it shouldn't, but I'm a bit less certain when we talk about result records that aren't primarily "Text" based. (Actually, this is a slightly wider concern about Annex A and those "CharacterString" elements... In IEEE LOM for example we have "LangString" element that has a "Lang" attribute. That community chose to allow language variants of a resource to be expressed within one record by allowing an element to hold all language variants, for example
		+
		+	<title>
		+	<langstring lang="En">Hello</langstring>
		+	<langstring lang="Dk">Hej</langstring>
		+	</title>
		+
		+	The presence of a "Lang" attribute at the "Dataset" level might mean the intention is to support multi-language datasets by having several dataset records, one for each language, which is OK, but possibly not optimal for datasets that aren't prmarily language based. If this is the case, is the "CharacterString" element in Annex A just redundant payload?) \|\| Add a treatment in Annex I that describes the specifics of search across multi-language elements; reconsider the expression of multilanguage CharacterStrings in the light of information retrieval best practise (see comment on this change)

@@ Line 88: / Line 88: @@
 |-
 | 5.1 || Paragraph 9 || T || "The discovery metadata elements are defined at an abstract level in order to make the Implementing Rules independent of ...". If there is no specified encoding or mapping into different common standard implementations, there is likely to be so much variance in encoding of metadata, as to cause new classes of problems (meta-mapping between different slightly discrepant models) while not solving the ones we face now. The usability of metadata in search engine applications. There is such a thing as too futureproof. || Hard to suggest a concrete change as this is a deep conceptual issue.
+|-
 |}

@@ Line 86: / Line 86: @@
 |-
 | B.6 || || T || Keywords are just as useful for discovering and filtering services as they are for data sets and series. If mandatory for data sets, should also be mandatory for services. || Obligation/condition should change either M mandatory, or C (mandatory for datasets, dataset series, and services )
 | 5.1 || Paragraph 9 || T || "The discovery metadata elements are defined at an abstract level in order to make the Implementing Rules independent of ...". If there is no specified encoding or mapping into different common standard implementations, there is likely to be so much variance in encoding of metadata, as to cause new classes of problems (meta-mapping between different slightly discrepant models) while not solving the ones we face now. The usability of metadata in search engine applications. There is such a thing as too futureproof. || Hard to suggest a concrete change as this is a deep conceptual issue.
 |}

@@ Line 62: / Line 62: @@
 |-
 | 5.2.3 || Paragraph 1 || T || A geographic extent may be in three dimensions and for some applications ( geology, meteorology, climatology ) vertical extent is crucial.   Would be nice to understand (have examples of) specification of interior/exterioir polygons. Servers only supporting minimal bounding boxes can gracefully degrade (Since it's easy to calculate a MBR from a polygon) whilst allowing other servers to retain the full richness of polygons. The IR should not simply specify a bounding box but should outline the many alternatives. || Change 'bounding box' to read 'bounding box, polygon or 3 dimensional set of polygons' ''(better wording)?''
 |}

← Older revision		Revision as of 18:26, 28 March 2007
Line 19:		Line 19:

	-- [[User:JoWalsh\|Jo]] 26-03		-- [[User:JoWalsh\|Jo]] 26-03
		+
		+	Just to mention i am doing another batch this evening and will upload them either later or first thing a.m.
		+	Meanwhile the JRC replaced the spreadsheet template with one that works, which is great.
		+
		+	-- [[User:JoWalsh\|Jo]] 28-03

	= Participants =		= Participants =

@@ Line 55: / Line 55: @@
 |-
 | 6.3 || Paragraph 13 || G || A provider may take a broad view of what consitutes "very fine grained" in order to exempt themselves from exposing insight into the detail and structure of a data set. || More detailed description of what contitutes "very fine grained", and detail of what metadata is subject to exemption for components of a highly detailed data set, is required.
 |}

@@ Line 16: / Line 16: @@
   Chapter, section or clause no. | Paragraph/Figure/Table | Type of comment | Comment justification for change) | Proposed change
-So i am working on integrating Ian's and Jan's comments and reconnecting mine to chapter, verse and clause. I planned to put it all into the Excel template this evening, then i discovered that the template doesn't work properly in OpenOffice. So i'm just going to dump a pipe-delimited version of what is collated into this wiki page for others to see, and worry about getting it into the proper format later in the week :/ I realise it makes sense to do that anyway because there is a lot to do in terms of structuring to get as much directly connected to the draft as possible...
+So i am working on integrating Ian's and Jan's comments and reconnecting mine to chapter, verse and clause. I planned to put it all into the Excel template this evening, then i discovered that the template doesn't work properly in OpenOffice. So i'm just going to dump a pipe-delimited version of what is collated into this wiki page for others to see, and worry about getting it into the proper format later in the week :/ I realise it makes sense to do that anyway because there is a lot to do in terms of structuring to get as much directly connected to the draft as possible... What is there now is only a start. :/
 -- [[User:JoWalsh|Jo]] 26-03
@@ Line 32: / Line 32: @@
 Note: these will be automatically re-sorted by chapter, clause etc order when they are submitted so there's no priority ordering and not much point in number ordering...
-|test|foo|bar|baz|
+{| border="1" valign="top"