profileDesc and the Guidance document #242
Comments
|
So the only thing required for a profile would be a URI? |
|
@agreiner said:
I tend to agree that the URI is only mandatory requirement for a profile. For the rest (profile metadata and (in)formal definitions of a profile), these are very much related to the specific use scenarios. The SHOULD can be considered as "recommended", but possibly also as "conditional" (i.e., "mandatory" if the requirements of a use scenario need it). E.g., in a scenario where profiles need to be published and made discoverable (in a specific registry, catalogue or Web site), a subset of profile metadata may be considered as mandatory. Likewise, profile definitions/representations may be mandatory when a use scenario require, e.g., support for validation. In any case, it would be important to explain in the guidance document "why" we may need profile metadata and profile definitions/representations. |
|
The URI identifies the profile document and doesn't say anything about the content of the profile. I think that the guidance deliverable should cover both the document addressability and the function of the profile. I don't know if we'll use MUST/MAY/etc in the guidance document, or if it will make better sense to talk in terms of common aspects and functionality, as Andrea says above. I would consider the inclusion of the metadata terms to be used to be essential to a profile - I can't imagine what a profile could be without that. |
|
I fully agree with what's above, if my reading of it is correct. A profile guidance document should seek to make mostly recommendations at this stage, and metadata on profile describe in something like ProfileDesc would be a key part of it. Which is a point for having ProfileDesc folded in the Profile Guidance document one way or another. |
|
@kcoyle is this issue trying to formally https://docs.google.com/document/d/13hV2tJ6Kg2Hfe7e1BowY5QfCIweH9GxSCFQV1aWtOPg/edit?disco=AAAABxg2QNM ? If yes then we could include the discussion there, in this issue. Anyway for now my take is that it's fine having both the Profile Guidance and the Profile Description folded in one same deliverable. Considering the discussion above, they probably share the same fate. I see some points about maintenance issue, which may make me change my mind later. But for the moment I see that even if they are separate, any change to the Profile Description would require changing the Profile Guidance (as anyway the latter is going to have to include extensive examples of usage of the former). So the value of separating them may not be very high. |
|
The scope of profiledesc is not limited to DCAT so there a slight risk that packaging it into DCAT guidance will taint it. But let's look at it down the track to determine if re-factoring is warranted and how easy that would be. |
|
+1 a profile just needs a URI it only needs to be dereferenceable if there is a need to understand it, or some aspects of it, for example to perform validation, form generation or conformance with more general profiles. (If we write a piece of software which hard-codes all the assumptions and only needs to recognise the profile, then it isnt necessary to dereference, and the software writer can possibly use a text description). I dont think we should care about this trivial case in the guidance, but it does apply to negotiation. The key thing to remember is that profiledesc is explicitly motivated as a means to meet the requirements of profile guidance that cannot be easily satisfied by any other identified vocabulary. So - there are a few choices
Option 2) is the best given the scope, but revisiting 5 may be the easiest and most appropriate from a process perspective. The cases I have seen where we can implement profiledesc will be able implement DCAT profiles anyway, so we end up with profiles as intrinsically catalogued resources, which is not incompatible with the need to have stable URIs for these things. |
|
@dr-shorthair The Guidance document is not DCAT Guidance, it is explicitly guidance for application profiles in general. |
|
@rob-metalinkage You say: "The key thing to remember is that profiledesc is explicitly motivated as a means to meet the requirements of profile guidance that cannot be easily satisfied by any other identified vocabulary." We still have not clearly identified those requirements, and we need to do so in order to justify the creation of profileDesc under our charter. We must discuss the draft requirements we have and determine whether they are in scope and where they are best satisfied. |
|
@rob-metalinkage The list of choices, 1-5 above, is important. Here are some comments:
|
|
Among the options proposed (thanks @rob-metalinkage !) I'm still in favour of 4. It's easier to handle for us right now. And we can still decide to separate later, depending on progress and adoption of ProfileDesc. Re. @kcoyle 's point on 4 about ProfileDesc not being 'technology neutral', this is indeed something to consider. But in fact I'm going to seize the opportunity to make a point I wanted to make: I think we should treat ProfileDesc as a Data Model, perhaps one back by RDF model, but not a 'pure' RDF ontology file. That wouldn't prevent us to create an RDF ontology, and have this be the main representation. But we should be completely ready to have Description of Profiles in XML, non-LD JSON, etc. |
|
@aisaac I like your suggestion that we treat it as a data model, without specifying a particular technology. That could mean that we define concepts in the text, and the RDF ontology could be a note showing one implementation (I think that implementations can be a note; need to check). The bulk, then, of what we provide would be to show the motivation for needing a profile description (DCAT-AP and Europeana are great examples). Then we have to decide between "should" and "may" but the fact is that we have few instances of profiles that use a description to date, so "may" might be appropriate for now because we are introducing something new. If it is taken up as an actual W3C effort then it could rise to "should" level. |
|
Peter suggests Core Public Service Vocabulary AP ( https://ec.europa.eu/isa2/solutions/core-public-service-vocabulary-application-profile-cpsv-ap_en ). Thanks. |
|
I also agree with @aisaac that we should be technology-neutral. And I also would point out that (to me) the URI identifies the profile as a |
|
So here is where I'm confused: if we write a spec that says all you need to have a profile is a URI, then absolutely everything on the web is potentially a profile. If we think a machine-readable form of a profile is a necessity, and the only guarantee we make for a programmer is that the thing has a URI, we haven't really offered the programmer anything useful to code against. I'm still not sure that a machine-readable profile needs to be anything other than a schema, though. That's what I'm hoping some real use cases can clarify. What do we want profiles to do that a schema doesn't already do? |
|
@agreiner I agree that saying that it only needs a URI is not sufficient for the resource to be a profile. It's like saying that it only needs an http URL to be a web page, but never defining HTML so that web pages can be created. Early on in this group there was what felt to me to be a consensus that defining a standard schema for a profile was beyond our abilities or time frame. However, the guidance document should provide a strong definition of what makes a "schema" or a "document" a profile. It's the content, just like the content of a PDF can be a curriculum vitae, a doctoral dissertation, a technical report, etc. We have recognizable document types based on their content. To me, a profile has a certain content and particular purposes. That is what we need to cover in the guidance. As for having a schema, Dublin Core has the beginnings of this, and I have started work in the Dublin Core area which will hopefully become a work item for that group. It includes a vocabulary for defining simple (i.e. core) profiles. |
|
If we take the view proposed by @aisaac and @larsgsvensson of providing a model rather than an ontology, it seems that the outline would look like:
(Note: I'm not sure about saying in the profile guidance that a profile SHOULD have a description because that is something new that we will be recommending but none of our existing profiles have them. I would see the profile description as being RECOMMENDED but applying mainly to future development.) |
|
We could emulate the PROV methods by having a Profiles/Profiling model (PROV-DM: conceptual model rather than data mode perhaps?) and then normative implementations in different technologies such as profileDesc as an ontology (like PROV-O) that adhere to the conceptual model and others, if people are interested in making them. |
|
I think I like @nicholascar's proposal, though the PROV DM is perhaps too complex for my taste - and probably beyond what this WG can do. But certainly we should seek to identify the primitives of a model for profiles. To answer @agreiner ’s point, I think we should add to the last post by @kcoyle an item that says: A profile MUST be based on some existing data standard(s). |
|
@aisaac " A profile MUST be based on some existing data standard(s)." What I worry about is that we'll be asked to define "existing data standard" and some people will want "It's gotta be W3C or ISO..." and others will be "My institution decided this, so it's a standard." The Dublin Core approach is that a profile must use terms defined somewhere, without saying where, how, or what is considered a valid term to use. Can we be that vague? |
|
@kcoyle I don't know. I thought our definition was using "standard". Anyway, whatever we name it, a standard MUST be based on something :-) |
|
@larsgsvensson said:
Well, we have the example of DCAT (and ADMS), where we have a resource ( |
|
@kcoyle @andrea-perego next time I'm lazy just correct me without further ado ;-) Indeed our agreed definition (https://www.w3.org/2017/dxwg/wiki/ProfileContext#Draft_common_definition_for_.22profile.22) says "specification" so there's no discussion to be had! @andrea-perego I believe that your analogy is analogous to the one that lead me to my earlier diagram (https://docs.google.com/drawings/d/1dHkpwKwUwMgS1RqSCTPO3uOoRiY_qNk0z5bhXJlYi4Y/) so I agree ;-) |
|
I've thought more about this, and here is an outline that is based on some metadata profiles that I am familiar with. Although none of our use cases specifies the need for administrative data, we can probably assume that it is, if not required, at least a good idea. This outline separates into two separate sections the expression of the profile itself, and information about the profile (meta information). What goes where is up for discussion, but this seems to me to break the profile description into sections that would make sense to the reader: what is a profile? how do I make it available? (publishing), how is it administered?, what needs to be said about its context? All of this could be managed in a single profile document, or there could be separate documents that are linked. If done as a single document then a profile is self-describing, which may have some advantages for sharing across platforms (e.g. for profiles that are not in RDF or that cannot link to external documents reliably). Introduction (non-normative)
Profile publication (normative)
Examples (non-normative) Administrative and descriptive metadata (normative)
Example(s) (non-normative) Bibliography |
|
I do have a question (or suggestion) about the metadata side of things... a lot of this is standard "cataloguing" - and would be covered by the DCAT move to an abstract dcat:Resource so wondering if we shouldnt push this into a more general statement about using available descriptive metadata
This tends to support the alignment of profileDesc with DCAT - which could be pointed as a recommended way to use DCAT to meet these goals. |
|
@rob-metalinkage It isn't clear to me yet if we'll be recommending any ontologies to fulfill these functions. That's one of the big decisions that needs to be made as the guidance document develops. Given our time frame, however, I suspect that the document will remain at the level of a conceptual model, and may be a support document for future W3C work (which I think is needed). |
|
Thanks @kcoyle I like this new outline. There are a lot of similarities with what we had agreed on earlier, and the differences provide some added value, clearly. The only downside I see is with the definitions. I think we can't avoid puting our definition for profile upfront. On the other hand, we could put the other definitions at the end of the document, and have hyperlinks to them in earlier parts of the text. This way they wouldn't stand in the flow. |
|
From @kcoyle :
|
This document seeks to reflect the structure suggested by Karen at #242 (comment). It also tries to re-use as much as possible the material edited by Nick at https://w3c.github.io/dxwg/profiles/ (on Sept 15 2018).
- splitting the long list of requirements/recommendations (MUST/SHOULD/MAY) from #435 (comment) and #242 (comment) into various sections where they can be better contextualised and explained (as consistent bits) to readers - acknowledging that these recommendations did not fit well as intro material and giving more space in the introduction so that the discussion on types and examples of profiles (#435 (comment)) can 'breathe' better. - provide finer-grained introduction (and better alignment) to other relevant DXWG work (the Profiles Ontology and Profile Negotiation) - put a placeholder for a conceptual model to which the rest can be naturally attached, and for which the Profiles Ontology would provide a straight implementation as a vocabulary. - exploit the notion of role as first introduced in the Profiles Ontology as an interesting pattern to represent the functions that (expressions/components of) profiles can play, as sketched in #435.
nicholascar
added
profile-guidance
profiles-vocabulary
nicholascar
removed
the
profiles-vocabulary
There are two possible approaches we can take to integrating profileDesc into our second deliverable. First would be a small-ish modification to the outline proposed by Lars. A W3C-structured document would exist as a separate item, not on recommendation track. (I'm not sure what options there are for a non-recommendation ontology, but I believe they do exist.)
In the other option, profileDesc is the main normative content of the Guidance document. This could be seen to fit the definition of the Guidance deliverable, which is:
A definition of what is meant by an application profile and an explanation of one or more methods for publishing and sharing them.
One could read this as meeting this outline:
* A profile MUST have URI (or an IRI?) identifying it. The URI SHOULD be an http URI
* A profile SHOULD have a title
* A profile SHOULD have a textual description intended for humans
* A profile's description MAY be expressed using a formal model we define (such as @rob-metalinkage 's proposal)
* A profile document SHOULD link to schemas implementing the profile it describes
The text was updated successfully, but these errors were encountered: