-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add definition of application profile #7
Comments
Hi, @nichtich, yes, thanks, this is something we definitely need to do. I have added a link to the W3C DCAT page on the Related Projects wiki page that gathered up some definitions that might be useful. That group decided on "A named set of constraints on one or more identified base specifications or other profiles, 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." That sentence is a bit thick and would probably be more readable if written as more than one sentence. We also may not wish to follow this example, but it is there for our contemplation. |
Thanks! I'd cut this down to the core of an application profile as "a set of constraints on one or more base specifications" (application profiles are special cases of specifications). The additional "to accomplish a particular function" may be relevant to distinguish application profiles from arbitrary profiles, but I think this more depends on point of view. |
Since 1999, "application profile" has most commonly been defined in the DC community as a variation on:
At the time it was felt that namespaces (only) define, while profiles (only) reuse, and it was considered good practice to document a profile separately from its underlying namespaces. Most APs in the DC style, DCAT included, still basically fit this definition, even if the vocabularies are not always presented in separate documents. The idea that one profile could extend another profile was introduced, in the DC context, in 2006, though it was felt that trying to nail down a notion of dependence between profiles too formally would be a can of worms.
The DXWG definition only really makes sense if "constraint" is defined in the broadest possible sense. For example, one could argue that any given statement is a constraint on the set of all possible statements but, while defensible philosophically, such a high level of abstraction is not actually very helpful. More helpful, in my opinion, is the distinction made in the DSP draft (2008), where "templates are used to express structures" and "constraints are used to limit those structures". To take an example from Mikael's DSP syntax:
This example specifies a template for statements using If in DXWG terms, everything in a profile is a constraint, then the entire statement template above, plus its enclosing description template, would be considered constraints. And if a profile, in DXWG PROF terms, is the sum of its relevant PDF, HTML, TTL, SHACL, ShEx, and Schematron files, encompassing everything from namespace documents to user guides, then I guess these also express sets of constraints? Bottom line: it feels reductive to define profiles only in terms of constraints. I would prefer that we stick with a definition closer to Heery and Patel 2000 - or come up with a definition that introduces an abstract (i.e., not ShEx- or SHACL-specific) notion of shape. |
If I am designing a profile to release LOD, in general terms I want to express what properties I use, their ranges and domains in the profile (taking into account the ranges and domains defined in the respective schemas), types (which I may include in ranges) and other things such as cardinality. |
Just to clarify: when I mention "data made available by others", I refer to data coming from multiple sources that I do not control. This means dealing with data conformant to potentially different application profiles. |
Here's another definition of "application profile": An application profile is a document that specifies how metadata elements from existing data models, possibly including locally defined additions, are combined and reused for a particular application. It can be expressed as a technical document, a machine-readable schema or just a consistently applied informal set of conventions. From: Osma Suominen, Nina Hyvönen. "From MARC silos to Linked Data silos?" https://doi.org/10.5282/o-bib/2017H2S1-13 |
@kcoyle The definition above is worth another look. Maybe close this because the discussion has moved elsewhere? |
Defined in TAPvocabulary.md as:
|
Can we make it more clear that an application profile should reuse terms from existing vocabularies? |
Good idea, Phil. How about:
|
That's better. |
I miss an introductory definition of "application profile". In my understanding it's a "schema that restricts an existing schema or model" but this is based on my terminology of "schema" and "model".
The text was updated successfully, but these errors were encountered: