search

w3c / dxwg

Data Catalog Vocabulary (DCAT)
https://w3c.github.io/dxwg/dcat/
Other
149 stars 47 forks source link

Proposal for the structure of the "Guidance for Application Profiles" document #196

Closed larsgsvensson closed 5 years ago

larsgsvensson commented 6 years ago

The document Guidance for Application Profiles currently has only three sections and very little text. I propose the following structure (to be extended as we go):

Comments and counter-proposals are most welcome.

kcoyle commented 6 years ago

Lars, to me this description appears to satisfy the content negotiation aspect of profiles, but the approved requirements for profiles go beyond this to include defining the vocabulary and the vocabulary usage rules. How far we go in terms of defining the actual content of a profile is on our agenda for the third F2F. We will put your proposal here on the agenda in the proposals discussion.

aisaac commented 6 years ago

I agree with @kcoyle the description is quite technical and focused on the bare minimum. On the other hand, maybe this is the way to go. Starting basic and/or technical, and then adding more details as we go, for example in the 'textual description intended for humans'.

By the way there was a call where we discussed the scope of the profile guidance in more detail, some months ago. I don't remember precisely when, but I do remember I was happy with the outcome :-) @kcoyle @larsgsvensson @rob-metalinkage does it ring a bell?

aisaac commented 6 years ago

I have spent a lot of time to browse through past call minutes, and found discussion on organizing the profile work and deliverables especially at: https://www.w3.org/2017/11/28-dxwg-minutes https://www.w3.org/2018/01/09-dxwg-minutes (this one has a lot of discussion) https://www.w3.org/2018/01/16-dxwg-minutes https://www.w3.org/2018/01/30-dxwg-minutes

Most often we've mentioned profile guidance and content negotiation as two deliverables, but it's more opinions than a formal decision, and in the Jan 30 there is a vague mention of "postponing" doing both at the same time. Or have I missed anything?

andrea-perego commented 6 years ago

A couple of comments:

  1. In the "Definitions" section, it may be worth starting with semantically broadest notion, and then to add the other relevant ones, narrowing down recursively the first definition. Said that, it is still unclear to me whether schema is or not broader than profile etc.

  2. About section "Profile description": as I said in http://lists.w3.org/Archives/Public/public-dxwg-wg/2018May/0144.html , I would suggest using different terms for profile metadata (title, description, etc.) and for the (in)formal definition of the profile (using XML Schema, SHACL, etc. or a simple human-targeted document). I tentatively used "profile description" for the former, and "profile definition" for the latter. Making an analogy with DCAT, the profile description is the dataset, whereas the profile definition(s) correspond to the distribution(s). This is also the pattern used in ADMS - the corresponding classes are adms:Asset and adms:AssetDistribution, respectively.

larsgsvensson commented 6 years ago

@andrea-perego

In the "Definitions" section, it may be worth starting with semantically broadest notion, and then to add the other relevant ones, narrowing down recursively the first definition. Said that, it is still unclear to me whether schema is or not broader than profile etc.

I don't know if it makes sense to say that schema is broader than profile or not. To me they are different things... And I think it's easier to discuss those things if we have some actual content.

I tentatively used "profile description" for the former (i. e. profile metadata), and "profile definition" for the latter (i. e. (in)formal definition of the profile).

It seems that your "profile desciption" is equivalent to my "profile" and that your "profile definition" is equivalent to my "schema". Does that make sense?

andrea-perego commented 6 years ago

@larsgsvensson dixit:

It seems that your "profile desciption" is equivalent to my "profile" and that your "profile definition" is equivalent to my "schema". Does that make sense?

Yes, but I'm not sure we are all using the notion of "schema" with the same meaning (I'm coming back to this in a moment).

My comment was triggered by the impression that the "Profile description" section is just about what I called "profile description" [sic!]. So, maybe an option could be to have an overall section "Profiles", starting by saying that a profile consists of a description and a definition, and then devoting 2 subsections to them.

About the notion of "schema", I am not very comfortable with it for a number of reasons. We said that a profile can be defined just with a human-targeted document, whereas "schema" usually reminds of something machine-actionable. Moreover, "schema" is so widely used that using it with a more specific meaning (in the scope of profiles) may lead to confusion. Finally, it may be worth taking into account that some communities use the expression "application schema" exactly in the sense of application profile - see, e.g., the GML case (which, BTW, we can include as an example of non-RDF-centric approach to application profiles) - quoting:

Geography Markup Language (GML) provides the basis for domain- or community-specific "application schemas", which in turn support data interoperability within a community of interest. Application schemas are normally designed using ISO 19103 (Geographic information -- Conceptual schema language) [1] conformant UML, and then the GML Application created by following the rules given in Annex E of ISO 19136.

I think we need to have a term to denote the artifact that defines a profile (irrespective of whether it is machine-actionable or not). If we do have the need of denoting the subset of "profile definitions" which are machine-actionable and we want to use "schema", then I suggest we always qualify it as "profile schema", to make it clear the scope of it (which is actually what is usually done - e.g., relational schema, XML schema, RDF schema).

aisaac commented 6 years ago

The discussion is happening in many places :-) As written in https://lists.w3.org/Archives/Public/public-dxwg-wg/2018May/0292.html I'm not keen on using 'definition'. I prefer 'representation' (as it was also used in https://github.com/w3c/dxwg/issues/75) or even 'encoding' (as in my suggestion for F2F3 at https://docs.google.com/drawings/d/1dHkpwKwUwMgS1RqSCTPO3uOoRiY_qNk0z5bhXJlYi4Y)

andrea-perego commented 6 years ago

Thanks, @aisaac . Happy to replace "definition" with a more suitable term. However, I'm concerned about "representation" / "encoding", as this is likely to rule out profiles "defined" only in a human-readable document.

aisaac commented 6 years ago

@andrea-perego good point. For me I have no problem refering to human-readable documents as 'human-readable representations' (vs machine-processable representations) or considering that HTML is an 'encoding' for such human-readable documents on the web. But maybe I'm too biased?

rob-metalinkage commented 6 years ago

I like the structure and scope proposed.

I think it will be useful to state the requirements for explicit types of cosntraints - but then all we can do is show examples of how different "schema" might support them.

It is late in the day, and while possibly we could propose and extension to SHACL or SHEX to cover key cases, we can also simply state that profiles SHOULD define such constraints, even if the only options today are to do this in text or use a non-canonical constraint language. The DC work on constraints may emerge to fill this gap - but we'd need some concrete proposals on solutions soon to include an implementation recommendation .

andrea-perego commented 6 years ago

@aisaac , I'm pretty comfortable with this use of "representation" (but it would be important we make it clear). I'm still concerned about "encoding" - that can also be used for the format / media type.

aisaac commented 6 years ago

@andrea-perego yes I think you're touching on the point that made me wonder about the separation between in my diagram at https://docs.google.com/drawings/d/1dHkpwKwUwMgS1RqSCTPO3uOoRiY_qNk0z5bhXJlYi4Y/ between my "Description/Specification /Expression" (corresponding to your "definition" or the "representation" that we're talking about) and my "Profile Description Encoding". So now I'm comforted in the separation and I won't use "encoding" for "representation/definition". Maybe I'm going to push again "expression" or "specification", though ;-)

aisaac commented 6 years ago

Just a note to say that my conversation with @andrea-perego here may badly collide with the one at https://github.com/w3c/dxwg/issues/195 ;-)

andrea-perego commented 6 years ago

@rob-metalinkage , I was making a comment along your lines during the last f2f, suggesting to include in the profile guidance document a matrix of languages and what they can be used for doing what (defining a profile, validation, form generation). I started a very first draft here: https://docs.google.com/spreadsheets/d/1Zty4jTzhG0_1xoJlDOMq1XeHelIwVP2-STw6_-_ZxR4/edit?usp=sharing

This matrix can be complemented with those constraints that we decide to include in the profile guidance document (to say which languages can express which constraints). Said that, I wonder how much the need of having such constraints is bound to the requirements of a profile. Looking at the existing profiles, I see more constraints that MAY be included, whereas the SHOULD could be limited to a bit more than profile dependencies.

kcoyle commented 6 years ago

Note that we created an outline for the guidance document (rather ad hoc and brain-stormy) at F2F3.

https://docs.google.com/document/d/15OfNXU9AJ-cZysc7uYP-Gks5dDa8n2B5IN6rWa3kRpo/edit#heading=h.cuvn3apl2413

kcoyle commented 6 years ago

Also #242 has other outlines.

nicholascar commented 5 years ago

Please close - main structure both discussed elsewhere and now established in doc

aisaac commented 5 years ago

Agreed. #242 is more recent.