Just a(nother) short input for the definition of recommended properties in section 5 - I would suggest to rephrase the description as follows:
Recommended property: a receiver MUST be able to process the information for that property; A sender MUST provide the information for that property in case it is available at the sending IT-System.
This may allow a better/clearer differentiation, especially between recommended and optional properties.
Additionally, to my mind, the section's last sentence seems a bit unclear to me ("How or even whethter the information is used is entirely at the discretion of the application at the receiver's end.").
Does this mean, that it is sufficient for an application to be able to parse that data, or should it at least be stored? Maybe we should be more precise on this...
Comments
Dominik,
(1) I I am not sure that the addition you propose "...at the sending IT system" makes it clearer. The sentence now intends to say that the sender should send it if it's there. For optional properties there is no obligation on the sender to provide it, even if it is there.
(2) the last sentence indeed says that nothing is implied about what the receiver does with the data. The issue is that the Application Profile intends to limit the requirements on the communicating systems to what is necessary for the exchange of data; it does not put requirements on the applications that go beyond the exchange of data.
Thanks for the feedback,
(1) Well, then recommended and optional properties do practically mean the same: "you can, but you don't have to" - so in this case I don't see any necessity for defining recommended properties anyhow, as they only add an additional layer of complexity to the concept as a whole (2-level- vs. 3-level-granularity)...
(2) The term/requirement "processing" - which is an important part of every single category's definition whithin this section - most probably already implies that incoming data is somehow handled at the receiver-side, but it is still not clear what processing includes in detail. Maybe we should substitute the last paragraph (Note:...) with a definition/clarification of what processing means in the given context (as you already mentioned, without introducing any limitations; so maybe at least explicitly say what it NOT means).
A first try:
In the given context, the term "processing" means accepting incoming data and transparently providing these data to applications and services. It does neither imply nor prescribe what applications and services finally have to do with the data (parse, convert, store, make searchable, display to users, etc.).
Dominik,
(1) there is a difference between recommended and optional:
Recommended: the informantion must be provided if it is there
Optional: the information does not have to be provided, even if it is there
(2) your addition "and transparently providing these data to appications and services" puts an explicit requirement on what a receiver should do. The current text tries not to do that, but I am happy if the Working Group agrees that such a requirements should be part of the application profile. I'll create an issue for the meeting on Thursday with your suggested text.
Resolved at meeting 18 July 2013, see report at https://joinup.ec.europa.eu/document/dcat-application-profile-wg-virtual-meeting-2013-07-18.
Resolution implemented in draft 0.04 at https://joinup.ec.europa.eu/document/dcat-application-profile-data-portals-europe-draft-final-text.