search

w3c / dxwg

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

Revisiting the definition of "profile" #963

Closed kcoyle closed 5 years ago

kcoyle commented 5 years ago

As per the meeting of June 25, 2019, this is an area for the discussion of the definition of "profile". Let's put each definition in a separate comment so people can up or down vote them.

kcoyle commented 5 years ago

The current definition:

A named set of constraints on one or more identified base specifications, including the identification of any implementing subclasses of datatypes, semantic interpretations, vocabularies, options and parameters of those base specifications necessary to accomplish a particular function.

kcoyle commented 5 years ago

A modification of the definition suggested by Antoine in this email. changing "on one or more" to "can be based on", resulting in:

"A named set of constraints which can be based on one or more identified base specifications, including the identification of any implementing subclasses of datatypes, semantic interpretations, vocabularies, options and parameters of those base specifications necessary to accomplish a particular function."

smrgeoinfo commented 5 years ago

A profile is a specification that applies additional constraints for validation of conformance targets to those defined in one or more base specifications. Resources that conform to a profile must conform to all provisions of the profile's base specifications.

Note-- without the conformance to base profiles provision, a profile is just another specification.

kcoyle commented 5 years ago

@agreiner Annette responded to Antoine's thoughts with an email that states that

"Profiling is about acknowledging a reuse. The threshold at which that acknowledgment is called for would be hard to define, but it seems to me that it is up to the creator of the spec or profile what level of acknowledgment they want to advertise. For example, I don't think that DCAT becomes a profile of vCard by including vCard elements. And I don't think we would want to advertise it as such, because we don't have the goal of creating a version of vCard that suits the needs of a specific community. I think it comes down to the intent."

tombaker commented 5 years ago 
data profile 

    A human- or machine-readable specification that
    clarifies, constrains, combines, excerpts,
    extends, or annotates one or more given data
    specifications.  

    A well-designed data profile provides
    information, useful for describing data in a
    given context, without semantically contradicting
    the data specifications on which it is based.

data specification

    A document, or family of related documents,
    possibly in alternative or complementary human-
    and machine-readable formats, that provide
    vocabularies or guidelines usable for describing
    data.

For further discussion, see https://lists.w3.org/Archives/Public/public-dxwg-wg/2019Jun/0144.html

tombaker commented 5 years ago

Karen suggests a slightly different wording at https://lists.w3.org/Archives/Public/public-dxwg-wg/2019Jun/0146.html - which would also be fine with me:

A human- or machine-readable specification that defines additional
constraints, conventions, or extensions over one or more given data
specifications.
pwin commented 5 years ago

Looking at the W3 site , aside from our work I see things like:

I think that the Antoine definition would describe the intent of these.

Elsewhere, outside of W3C, I see things like:

I think that these also fit with the Antoine's definition.

The docs for these mention that they are based on some prior standard and that this was done for a defined purpose [e.g. section 2 of https://github.com/tdwg/abcddna/blob/master/640-3005-1-SM.pdf

Section 1.1.2 of https://www.fgdc.gov/standards/projects/FGDC-standards-projects/metadata/biometadata/biodatap.pdf is usefully detailed:

This profile is intended to support the collection and processing of biological data. It is intended to be useable by all levels of government and the private sector. The profile was developed by defining information required by a prospective user to determine the availability of a set of biological data; to determine the fitness of a set of biological data for an intended use; to determine the means of accessing the set of biological data; and to successfully transfer the set of biological data. As such, the profile establishes the names of extended data elements and compound elements (groups of data elements) to be used for documenting biological data, the definitions of these extended compound elements and data elements, and information about the values to be provided for the data elements. The profile also describes any modifications to the optionality or repeatability of non-mandatory elements and any modifications to the domains of standard elements in the FGDC’s Content Standard for Digital Geospatial Metadata. The standard is not intended to reflect an implementation design. An implementation design requires adapting the structure and form of the profile to meet application requirements. The profile does not specify the means by which this information is organized in a computer system or in a data transfer, nor the means by which this information is transmitted, communicated, or presented to the user.

tombaker commented 5 years ago

Antoine suggests that the definition of "profile" be modified to read:

A named set of constraints, which can be based on one or more other identified specifications...

I think we are all in agreement that a profile typically constrains some other (base) specification(s) and we might even accept that a profile is not necessarily based on other specifications. However, this is not the part of the definition that is problematic.

The biggest problem lies with named set of constraints.

None of the examples cited by @pwin above, I would assert, can usefully and accurately be characterized as a "set of" anything, and certainly not as a "set of constraints", especially if the notion of "constraint" is not defined. The notion of a "named set" does not make the definition any better.

To test whether something a set, it should be possible to enumerate the members of that set. The Registered Organization Vocabulary, to take one example, has a list of namespaces used, "Status of this document", header metadata, change log, property and class definitions, usage guidance, Table of Contents, Acknowledgements, References, copyright notice, and the like. Is it helpful to call this a "set of constraints"?

"Set of" is the language of mathematics and computer science. An RDF graph can usefully be described as a set of triples. A Python dictionary can be described as a set of key:value pairs. But to reduce profiles to "sets of constraints" implies a mathematical rigor to the notion of profile that is quite inappropriate.

As for "constraint": if anything is a constraint, then nothing is a constraint. And if a constraint does not actually "constrain" something, then it fails the test of common sense.

Hence my definition (above) of "data profile" as a "specification" -- not a "set" -- that constrains, extends, or annotates a "data specification". This definition avoids the thorny question of how to usefully define "constraint". We can discuss whether a profile MUST refer to another data specification or MAY stand on its own, but that is a different discussion.

pwin commented 5 years ago

So, @tombaker , the challenge is that much of what was in my list above was from a different era, and that we need a development that looks forward to the increased use of profiles that are likely to have a certain amount of rigour based on set membership etc. If we had this approach in our minds at the start, things like licenses wouldn't be as difficult to work with as they currently are. So I think that we are needing to frame something that is (perhaps awkwardly) backwards compatible, but sets a sense of direction for future work.

dr-shorthair commented 5 years ago

@tombaker asked:

Is it helpful to call this a "set of constraints"?

Could they be enumerated in a checklist? If so, then 'set' is fine AFAICT, in fact it is a useful idea.

I understood that the goal of the profile-vocabulary was to help in expressing a profile more formally. Wouldn't this converge towards enumerating the set of concerns?

kcoyle commented 5 years ago

@dr-shorthair I'm not sure what exactly you are including in "they". If you look at DCAT-AP, which I assume we consider an application profile, then there is a significant portion of that document is cannot be ennumerated. There is introductory material, and the organization of the document includes the division of terms into categories, which would suggest that these are all subsets.

4 DCAT APPLICATION PROFILE PROPERTIES PER CLASS A quick reference table of properties per class is included in Annex I. 4.1 Catalogue 4.1.1 Mandatory properties for Catalogue

If you are only considering the terms themselves, outside of the document, then you may be referring to the RDF or SHACL files as "enumerations", but those are greatly reduced in content from the AP itself, even lacking the usage notes and categories of the PDF document. Could the enumeration contain everything in the AP? I dont' think we've shown that to be the case yet, although that is a worthy goal.

If we allow our definition to include APs that are expressed as documents, like DCAT-AP, then we cannot limit them to things that can be considered "sets" in the formal sense of that term, and the definition suggested by Antoine has an air of formality, so people would not be wrong to assume the mathematical sense of "set" rather than the very informal "any bunch of stuff".

kcoyle commented 5 years ago

@pwin You found one "profile" that was stated to be "an extension of" another. That is in contradiction to the definition that considers profiles to be "constraints". What fits better in the definition is the statement that a profile "defines additional constraints, conventions, or extensions " that comes from RFC 6906. Limiting to constraints - or I could say constraining our definition to constraints - leaves out a significant number of actual APs.

pwin commented 5 years ago

Yes @kcoyle . I wanted to find usage of the term 'in the wild' with examples that we might be able to use to clarify our thinking and also try to evidence the components of our definition. That example was from a US Federal source in 1998/9.

smrgeoinfo commented 5 years ago

The question that interests me is whether 'profile' should mean something that has implications for software implementations, or if it is a sort of qualitative statement something like 'a lot of what is this spec is adopted from pre-existing spec X (or specs X, Y, and Z)'.

There are pre-conditions to be software actionable-- the base spec has to define some software-testable conformance requirements. If it doesn't, then there is no machine-actionable way to validate resources for conformance to that spec, and there is no point trying to formalize what a profile of that spec is in a machine-actionable sense.

What I'm really interested in here is machine interoperability-- aggregators can harvest metadata conforming to some specification (or profile of a spec) so as to consistently index harvested metadata, present results to users, and offer value-added services based on the harvested metadata. Software applications can advertise the kind of input formats they need (a spec or profile of a spec), and datasets can declare a spec or profile of a spec they conform to, so that search applications can get the user from data discovery to data utilization with fewer clicks. I tried to provide some concrete examples of this in ID21 and ID22. ID2 and ID3 are also related.

pwin commented 5 years ago

@smrgeoinfo I think that software development should be a (perhaps significantly increasing) subset of the use cases for a 'profile'. This is why I think we need to be inclusive in our definition, but quickly move to some broad taxonomy of profile types that can then permit development of good practice documentation. There might also be a migration path that could be suggested between things which at present require quite a bit of human in the loop to other processes that make much more machine use. There are many examples of maturity model that we might use for this - here I'm thinking about interoperability maturity models as referenced in https://joinup.ec.europa.eu/collection/semantic-interoperability-community-semic/document/interoperability-maturity-model and interoperability reference architectures as described in https://ec.europa.eu/isa2/solutions/eira_en

smrgeoinfo commented 5 years ago

@pwin I think your suggestion that a taxonomy of profile types is what is needed. Perhaps this could be approached (partly) as a taxonomy of relationships between specifications. This is based on the view that a profile is just a kind of specification that has a particular relationship with one or more base specifications. Some possible relationships (just a start...)

The specification taxonomy would focus on aspects like 'does the spec provide machine actionable conformance tests', 'has clearly defined conformance requirements', 'provides guidance and recommendations but not testable conformance requirements'

andrea-perego commented 5 years ago

@smrgeoinfo , the relationships you outline look very similar to the ones defined in VOAF (http://purl.org/vocommons/voaf) - probably with the exception of the conformance aspect.

tombaker commented 5 years ago

@pwin @kcoyle We need not look back to a "different era" to find profiles that "extend" (one of the patterns enumerated above by @smrgeoinfo). The GeoDCAT-AP and StatDCAT-AP listed in Section 14 of DCAT clearly describe themselves as "extensions". If the German adaptation of DCAT-AP listed there is at all typical, the language and country adaptations are not just translations, but include both constraints and extensions ("Einschränkungen und Erweiterungen").

tombaker commented 5 years ago

@dr-shorthair

Tom: Is it helpful to call this a "set of constraints"? Simon: Could they be enumerated in a checklist? If so, then 'set' is fine AFAICT, in fact it is a useful idea.

I think you are asking whether "constraints" defined in profiles could be enumerated. If we had a coherent definition of "constraints" (which we do not), I'm sure this could quite trivially be done. But it is terribly reductive to characterize profiles as "sets of constraints" as if they were data structures like RDF graphs ("sets of triples") or Python dictionaries ("sets of key:value pairs"). If the PDF of a profile cannot be algorithmically processed as a set, and an ordinary user cannot immediately recognize its contents as constituting a set, it should not be called a set.

I understood that the goal of the profile-vocabulary was to help in expressing a profile more formally.

But is that really the goal of the profile vocabulary? Technologies such as ShEx, SHACL, Schematron, etc, really do help express a profile more formally. The draft Profiles Vocabulary, as I see it, merely aims at describing relationships within a cluster of documents.

larsgsvensson commented 5 years ago

@tombaker scripsit:

But it is terribly reductive to characterize profiles as "sets of constraints" as if they were data structures [...]

Would it help to call them "collections of constraints" or "lists of constraints" in order to get away from the mathematical notion of sets?

tombaker commented 5 years ago

@larsgsvensson wrote:

Would it help to call them "collections of constraints" or "lists of constraints" in order to get away from the mathematical notion of sets?

The problem is that profiles consist not just of constraints alone, but also of extensions and usage annotations. (I emphatically resist the notion that extensions and usage annotations can be characterized as "constraints". If constraints do not "constrain" something, they fail the test of common sense. If everything is potentially a constraint, then the term is effectively meaningless.) I cannot think of a single word that captures the range of things one might find in a profile.

The definition I proposed, or a variant thereof, gets around this problem by saying that a profile is a specification that "constrains, extends, or annotates" one or more data specifications. This definition defines the profile in terms of how it relates to other specifications, not in terms of the sets, lists, or collections of things it might contain.

tombaker commented 5 years ago

@smrgeoinfo @pwin I agree re: need for taxonomy along these lines. This is precisely the sort of analysis one would wish from a Guidance document. Indeed, Section 1.2 of the Guidance draft points in that direction.

rob-metalinkage commented 5 years ago

This is all getting rather convoluted - at this stage we dont need a taxonomy because we only need to deal with strict conformance - uses, or guided by or any other possible relationship may be described by some other process - its an open world - its not relevant to conneg.

Other rather obvious points: text in a document describing a profile is not the same as the profile - all specifications have background and informative information, and a set/list/collection/handbag of normative requirements - all that other stuff is metadata and annotations about the "thing". nothing in the definition does, or should, stop you from describing any aspect any way you like - thats just confusing the representation of the concept with the concept itself.

Usage annotations are just open-world view of the original specification - extensions however actually do constrain things if there is a requirement to use the extension to conform to the specification.

We simply dont have Use Cases around annotation, re-use, or publishing optional extension vocabularies - valid though they may be. It is true that existing profiles may also perform these roles w.r.t. to specifciations - but nothing stops them having multiple roles.

Feel free to suggest better wording, but dont introduce different requirements without following the agreed UCR discipline

tombaker commented 5 years ago

@rob-metalinkage

we dont need a taxonomy because we only need to deal with strict conformance

The taxonomy proposed by @smrgeoinfo nicely shows that different types of profile imply different notions of conformance. In such a context, what does "strict conformance" even mean?

Other rather obvious points: text in a document describing a profile is not the same as the profile

I think we can agree that DCAT-AP is a profile, correct? The various things in DCAT-AP, such as its text, are obviously not the same as the DCAT-AP.

thats just confusing the representation of the concept with the concept itself

I agree with Antoine's preference for "specification" over "document". While "document" implies a concrete instance of a profile, "specification" implies something more conceptual, which allows different representations to be grouped together (and which is what I think you are driving at with "concept"). This is why I use "specification" in the definition proposed above.

kcoyle commented 5 years ago

We simply dont have Use Cases around annotation, re-use, or publishing optional extension vocabularies - valid though they may be.

We do have:

6.12.1 Profile documentation [RPFDOCU]

A profile should have human-readable documentation that expresses for humans the main components of a profile, which can also be available as machine-readable resources (ontology or schema files, [SHACL] files, etc). This includes listing of elements in the profile, instructions and recommendations on how to use them, constraints that determine what data is valid according to the profile, etc.

6.11.1 Human-readable definitions [RPFHRDEF] 6.11.2 Global rules for descriptive content [RPGRDC] 6.11.9 User interface support [RPFUI]

aisaac commented 5 years ago

wow this discussion really goes into too many aspects: using "constraints" or not, "being based on something" or not, being a "set" or not... Maybe we should split and identify the different facets of the issue? ('m pessimistic about it, as every attempt to do this seems to lump again everything together. But maybe we can try...)

On these different aspects:

aisaac commented 5 years ago

And I disagree with the notion of taxonomy proposed by @smrgeoinfo . Not that the notions are meaningless, it's rather that it presents them as alternatives, while to me they can be combine (i.e. an extension is a form of constraint on the data too, see my comment above)

kcoyle commented 5 years ago

@smrgeoinfo Here's what we have in the very drafty draft of profile guidance for profile "types" :

1.3 Examples of profiles and related work

Profiles can take a number of forms and can have a variety of relationships to existing vocabularies, standards, and other profiles. We recognise this variety, but for the purposes of this document we are focusing on the most general forms of profiles and profiling. Although it is not possible to list all of the types of profiles, some illustrations of frequently-used profiles include:

profiles that are subsets of a larger vocabulary. These reduce the vocabulary terms of a broad data standard to a smaller number of terms that are useful for a particular community member or application. An example of this is BIBFRA.me, which is designed for library materials and defines both a core set of terms as well as profiles for specialized communities such as cataloging of rare materials or early printing trade. In this community, all profiles use only terms from a single vocabulary.

profiles that can both reduce and extend a base standard. These profiles are developed by members of a data-sharing community but for reasons of jurisdiction or specialization need to add terms beyond the base standard vocabulary in order to meet their needs. They may also omit terms from the base standard that are not relevant to their implementations. An example of this is data catalog vocabulary standard, DCAT, its primary profile, DCAT-AP, and the national variants (DCAT-AT-IT, DCAT-AP-NO, DCAT-AT-DE). While maintaining overall compatibility with the larger data catalog community, each of these profiles adds needed terms for the local variant. These profiles generally make use of terms from more than one namespace.

profiles that amend a base standard by inheriting or overriding values of that standard. The example here is of the Open Digital Rights Language (ODRL) which is a language to support rights in the use of digital content in publishing, distribution, and consumption of digital media. The ODRL language encodes a policy that has a core vocabulary that can be extended or overridden by individual instances called "profiles." profiles that use some vocabulary terms from multiple standards without having a strong relationship to any base standard. These profiles develop new groupings of existing terms as vocabularies and may define new terms as needed. An example of this is the Asset Description Metadata Schema (ADMS) vocabulary [vocab-adms]

aisaac commented 5 years ago

And I'd like to emphasize that @kcoyle 's "types" above are more exclusive than the other taxonomy. We've factored out notions like "use", "constrain" and "inherit" because all these type do these things, to some degree.

kcoyle commented 5 years ago

@aisaac As an English-speaker, extensions do not make sense as "constraints". Constrain really means to limit and is the opposite of expand or extend. This is why I favor listing contraints AND extensions in the definition. I understand how the dictionary definition could be used to include a profile with extensions, but it is going to be quite counter-intuitive to readers and will cause confusion. I see no problem with using both constrain and extend, which are easily understood.

aisaac commented 5 years ago

@kcoyle my problem is really that my extensions are constraints on the data. I think we're talking about "constraints/restriction over an existing specification" (your sense) and "constraints over data, independently on whether they are derived from an existing specification" (my sense). What word to use for my sense?

Maybe what I'm after is 'validation of conformance targets' as @smrgeoinfo has put it at https://github.com/w3c/dxwg/issues/963#issuecomment-506438552 but this looks quite complex an expression

aisaac commented 5 years ago

@tombaker for the record I've -1'ed your proposal at https://github.com/w3c/dxwg/issues/963#issuecomment-506650168 mostly because of the definition of data specification, which I find too document centric. And (probably as a result) then the definition of data profile is only in terms of machine- or human- readable doc, while I still would like a conceptual aspect (which you've correctly identified in other messages!)

tombaker commented 5 years ago

@aisaac I really like your distinction between specification and document, so if my definition can be improved to make that clearer, I'm happy. Instead of "family of documents", would reference to related "representations" be clearer?

aisaac commented 5 years ago

@tombaker this is better but I'm still hesitant - it depends on the final wording. I see the specification as something conceptual, a "hub" between representations/documents, so I'd prefer something that hints that a data specification has a family of representations, rather than is a family of representation (even though of course the representations are an essential part of the data specification). Similarly for your definition data profile, for me it's not about being human- or machine-readable, but rather about having human- or machine-readable representations (and btw I guess in Guidance we should say that there must be some human-readable representation, even partial, otherwise it's a strange spec...)

kcoyle commented 5 years ago

@smrgeoinfo Nothing in our definitions or the guidance document say that profiles CANNOT be actionable. Actionable profiles are one of the many possible kinds of profiles, and we have more than one use case that speaks to validation of data based on profiles. (5.41 Vocabulary constraints [ID41]) (5.37 Europeana profile ecosystem: representing, publishing and consuming application profiles of the Europeana Data Model (EDM) [ID37]), If your need is to have a profile that you can compute over, that is fine. We do, however, want to include profiles that are not written as actionable code, such as DCAT-AP and many others. We can hope that our future is one with standarized and actionable profiles, but we have a present and legacy that also needs to be accommodated. My feeling is that excluding those will overly narrow the community that will participate with us.

Note that I come from a humanities environment where the data is much less rigorous and other than search and display very little computation takes place. Profiles have been written documents, and only now is there some profiling based on RDF classes and properties.

kcoyle commented 5 years ago

but rather about having human- or machine-readable representations

+1 to representations, without saying more about what they are or their relation (could be from a single SHACL or ShEx document; could be separate).

? Do we exclude profiles without one or the other? Can we say "may have" to be inclusive?

kcoyle commented 5 years ago

RE: Constraints

@aisaac when you say:

my problem is really that my extensions are constraints on the data. I think we're talking about "constraints/restriction over an existing specification" (your sense) and "constraints over data, independently on whether they are derived from an existing specification

I suspect that we are tripping over the fact that we are sometimes talking about different things:

1) the profile in relation to an existing specification, where the profile can constrain or expand prior vocabularies 2) the profile in relation to the data it defines, where it the profile defines/constrains the data

So we should talk about these two separately in the definition. First, what the profile is in relation to other specifications, and then its role in defining/constraining the data for a use or application. If we make that clear then I think we may have solved the confusion we have about "constrain" - that a profile's purpose is the constrain some data, but it does so by being based on prior specifications and may limit or expand on those.

tombaker commented 5 years ago 
data profile 

    A data specification, with human- and/or
    machine-processable representations, that defines
    the content and structure of data used in a given
    context, often by constraining, extending, or
    annotating other data specifications.

data specification

    A specification, with human- and/or
    machine-processable representations, that
    provides vocabularies or guidelines for
    describing data.

This proposal, based on earlier proposals, as presented on the public-dxwg-wg list, tries to retain features that were upvoted by Lars, Riccardo, Peter, and Karen, while addressing several issues:

aisaac commented 5 years ago

Some comments on @tombaker 's definition (thanks! I like it better indeed):

smrgeoinfo commented 5 years ago

I don't see the value of calling something a profile if it doesn't constrain, extend, or annotate some other specifications-- in which case it would just be another specification as noted by @agreiner in the e-mail thread.

@tombaker 's definitions could reduce to

data specification A specification, with human- and/or machine-processable representations, that defines the content and structure of data used in a given context

data profile A data specification that constrains, extends, or annotates other data specifications.

With the understanding that a specification must be identifiable (named) to be useful. The name/identifier for either a data specification or data profile could be used for profile negotiation, or as the value for a 'dcat:conformsTo' property on a dcat:Resource or dcat:Distribution.

Annotate is interpreted to mean provide additional guidance or recommendations on usage to improve interoperability

tombaker commented 5 years ago

@smrgeoinfo

Annotate is interpreted to mean provide additional guidance or recommendations on usage to improve interoperability

Yes, that is what I meant. I like your reduction of my proposed definitions!

tombaker commented 5 years ago

@aisaac What does "named" actually add? Can we not take it for granted that a profile would have a name?

describing data is not prescriptive enough for me. I'd like more to keep "defines/constraints"

I agree, and that is indeed why I changed "describes" (from my earlier proposal) to "defines" - borrowed from Karen.

some of the enumeration of what's contained in a profile from the earlier definition would really help. I think we didn't add these for no reason, at the time!

When I dug a bit deeper, I found that the wording ("subclasses of datatypes, semantic interpretations, vocabularies, options and parameters... necessary to accomplish a particular function") was mostly borrowed from ISO 10000-1, which AFAICT was a software engineering standard. I questioned the notion of "sub-classes of datatypes" because datatypes are not classes, and I suspect that the original ISO standard actually was referring to software functions. I am also unclear what "parameters" refers to; does DCAT have parameters? That leaves vocabularies, semantic interpretations, and even options, which make more sense to me.

aisaac commented 5 years ago

@tombaker yes "defines" is better. And I am not claiming that we should keep all the enumeration of examples verbatim. But I think some enumeration helps.

@tombaker I'm keen on "named" because this paves the way for URIs. And it's a requirement we've identified, I believe.

@smrgeoinfo @tombaker yes replacing "annotating" by your suggested paraphrase would be very helpful. "Annotate" is perhaps the only word that's more ambiguous than "profile" in our context ;-)

@smrgeoinfo as I've said on the mailing list, can live with not calling "profile" the things/specs that are not derived from other things/specs.

agreiner commented 5 years ago

I like the reduced form of Tom's definitions

andrea-perego commented 5 years ago

+1 from me too. Maybe with a slight revision:

Data profile A data specification that constrains, extends, and/or annotates other data specifications.

I also wonder whether we should include "combine" for profiles based on multiple specifications:

Data profile A data specification that constrains, extends, combine, and/or annotates other data specifications.

rob-metalinkage commented 5 years ago

I dont think there is actually a consensus yet on what a profile is, so we cant vote for wording and expect a good outcome.

I have proposed a new UC which hopefully covers the concerns people have over things like "recomendations" in documents co-existing with testable requirements:

https://github.com/w3c/dxwg/issues/978

We may need to update examples to add identifiers for different "sets" within "documents", or define a convention that a conformance is strictly interpreted as conformance to the mandatory set of requirements, and that further description is necessary to handle cases of suggestion, optional re-use in an open world etc.

rob-metalinkage commented 5 years ago

ps - i think we are finding we cannot "take it for granted that a profile would have a name" - life would be easier if we could :-(

kcoyle commented 5 years ago

Copying email comments to github (my bad)

Karen said:

What is meant by "named"? Is a name the same as an identifier? The same as a title on a document?

Note that we have stated that for content negotiation the resource MUST have a web-based identifier (URI/IRI). When a profile is a document (e.g. PDF) then I would say that it SHOULD have an identifier, but if it doesn't it does not cease to be a profile.

Antoine replied:

I think at the level of a definition we can give ourselves a bit of slack, and only refine later (i.e. in our guidance document) what are the possible "names" or identifiers and what level of mandatoriness we expect.

By the way I think what you outline in the second paragraph does not conflict with what is in https://w3c.github.io/dxwg/profiles/ (either as rather clean text or very drafty notes).

kcoyle commented 5 years ago

@aisaac I would be fine with giving ourselves slack on names if it weren't that the primary statement that is made in the definition is "A named set ...." That's pretty definitive. If the definition read "A set ..." and in the document we talked about optional and preferred naming, I would feel better about it. But the definition opens with "named" in a way that would make later "slack" very hard to pull off.

aisaac commented 5 years ago

@kcoyle well my request for slack is for sorting out the detail later. I am fairly sure there is a need for a name, even though the type of name may be flexible (and I include "having a URI" among the options for "being named"). Otherwise how would you refer to the profile? I mean, having an anonymous profile sounds a bit pointless. All cases we have for profiles are somehow named.