Skip to content
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

Does "profile of" require all or some elements? #802

Open
kcoyle opened this Issue Mar 6, 2019 · 36 comments

Comments

Projects
None yet
7 participants
@kcoyle
Copy link
Contributor

commented Mar 6, 2019

From the Shex community: It is also unclear to us whether it is helpful to describe the relation of a profile to its underlying namespaces in terms of a relation of Profile to Standard. The standard-to-profile relation is characterized as one of general-to-specific, but when namespaces simply provide just a handful of their terms to a profile, it seems like a stretch to say that the profile is "profiling" each of the namespaces. https://lists.w3.org/Archives/Public/public-dxwg-comments/2019Feb/0001.html

@kcoyle

This comment has been minimized.

Copy link
Contributor Author

commented Mar 6, 2019

From the profgui meeting of Feb 28:

  1. "profile of"
    What conditions entail that one thing is a profile of another thing?
    a. - any use of elements (classes, properties), even if minimal (e.g.
    just use one DC term)[4 - Tom Bakers response]
    b. - use of all of the elements from a "base specification" and possibly
    add elements from another another specification and/or other constraints.
    c. - use of a "significant portion" of a base specification or other
    profile.
    d. - something is a profile of something else if the creator of the
    profile declares it as such

Note that if there is to be any formal inheritance then some of these
definitions would not be usable.

Related issues:
#486

https://lists.w3.org/Archives/Public/public-dxwg-wg/2019Mar/0014.html

@kcoyle

This comment has been minimized.

Copy link
Contributor Author

commented Mar 6, 2019

response from Lars:

a. is definitely too weak, d. feels a bit arbitrary. I tend to b. rather than c. even though I understand that there are corner cases where this can be hard. (When it comes to machine-processability I tend towards relatively strict definitions...).

https://lists.w3.org/Archives/Public/public-dxwg-wg/2019Mar/0079.html

@kcoyle

This comment has been minimized.

Copy link
Contributor Author

commented Mar 6, 2019

Response from Makx:

I agree with Lars that b. makes the most sense. For example, the European DCAT-AP mentions each and every property in DCAT-2014 with a usage note. A profile could state "don't use property x" but it should say something about all terms from the specification it is a profile of.

Makx

https://lists.w3.org/Archives/Public/public-dxwg-wg/2019Mar/0080.html

@smrgeoinfo

This comment has been minimized.

Copy link
Contributor

commented Mar 6, 2019

I like the approach that

  1. a profile is a specification that restricts one or more other specifications in some way.
  2. a specification consists of rules/conformance classes/constraints (choose your favorite terminology) that dictate how some particular data resource can be validated as conforming to the specification.
  3. A specification is an abstract concept. It is essentially like an FRBR work; there are various manifestations/expressions (maybe @kcoyle can clarify) of the specification as executable rules (shacl, shex, xsd, schematron.......). It's debatable whether these are 'representations' of the specification, or 'related resources'; either approach can work, choose one and be consistent.
  4. Data resources that conform to a profile will also validate according to the rules of all base specification for that profile.
  5. A profile may use elements from other specifications without inheriting all constraints from those specifications. These are not 'base specifications', they are 'related specifications' (or choose some other relationship terminology that you like). The profile must express any relevant rules for the use of these sort of elements, but that usage must be consistent with constraints from the source specification.

NOTE: edited 2019-03-11 based on subsequent comments by @kcoyle (constraints from related specs) and @makxdekkers (change 'artifact' to 'data resource')

@rob-metalinkage

This comment has been minimized.

Copy link
Contributor

commented Mar 6, 2019

@smrgeoinfo .. that is correct and well put.

I think that this might be worth adding into a section on conformance vs reuse.

Only tweak is to make sure people dont confuse artifacts in section 4 with the artifacts used to describe a profile itself.

@makxdekkers

This comment has been minimized.

Copy link
Contributor

commented Mar 7, 2019

It is better not to use words that have no clear meaning. 'Artifact' is such a word, basically a synonym for 'Thing'. It is much better to use a less ambiguous word. In the case of @smrgeoinfo's 'particular artifact' in point 2, something like 'data resource' (see my suggestion at #572 (comment)) or 'instance of a dataset description' could be used.

@kcoyle

This comment has been minimized.

Copy link
Contributor Author

commented Mar 7, 2019

@smrgeoinfo 's #5 seems to be a new concept. Up until now I believe that all use of elements (properties and/or classes) from other vocabularies or profiles implied conformance.

  1. "A profile may use elements from other specifications without inheriting conformance constraints from those specifications."

Also, when engaging in inheritance, how would you know which elements do not need to conform?

@smrgeoinfo

This comment has been minimized.

Copy link
Contributor

commented Mar 8, 2019

@makxdekkers thanks for that refinement.
@kcoyle the rest of 5 "The profile must express any relevant rules for the use of these sort of elements." is intended to answer that, but it need further thought. I would assume that any domain and range constraints from the original element definition would need to be honored, if they exist.

@kcoyle

This comment has been minimized.

Copy link
Contributor Author

commented Mar 8, 2019

Thanks, @smrgeoinfo. I'm still not sure which (if any) of the definitions on the extent of "profile of" your definition selects. The big question is whether "profile of" implies using an entire specification or something else. The ShEx community response from Tom Baker debated that any profile using a handful of, say, Dublin Core properties mixed in with other namespaces can be said to be a "profile of" Dublin Core. By that definition just about every vocabulary in the Linked Open Vocabularies is a profile of Dublin Core, as is DCAT. So can you say if any of the a.-d. definitions meet yours? Thanks.

@rob-metalinkage

This comment has been minimized.

Copy link
Contributor

commented Mar 8, 2019

Were are not talking about reuse or properties, only constraints that have conformance implications. Axioms of the base specification must be respected but option elements remain optional elements unless your profile adds constraints. AFAICT there is no concept "conforms to the whole specification" independent of "is consistent with all constraints". (formal xxioms are a special type of constraint)

@kcoyle

This comment has been minimized.

Copy link
Contributor Author

commented Mar 8, 2019

Rob, the question is different. I think you are responding to @smrgeoinfo 's #5, but above you seemed to agree with it. The question here is which of the options (a-d) laid out by the group do you see as being the meaning of "profile of"? We're trying to get consensus on this.

@smrgeoinfo

This comment has been minimized.

Copy link
Contributor

commented Mar 11, 2019

The problem I see is that meaning of 'use of' (in a-c above) is not clear enough to be testable. My interest is to assist client software to select representations of resources from various distributions documented in catalog records. I'm imagining that the metadata record will be able to declare that a distribution conformsTo some profile X, and this statement will be used by client applications to select a distribution that they can work with, the implication being that the representation offered meets certain requirements in terms of vocabularies used, required elements, syntax etc.

@kcoyle

This comment has been minimized.

Copy link
Contributor Author

commented Mar 11, 2019

@smrgeoinfo I agree that "use of" isn't clear. So if my profile states that it conforms to profileX, what do you expect that to mean in terms of actionability? What actions would you take? I think the trick is in your "meets certain requirements... etc." and we're trying to determine if there are requirements implied by profileOf. If there aren't then it isn't going to be actionable; if there are then it may not satisfy all of the needs that folks have. Can we dig down into those "certain requirements"?

@smrgeoinfo

This comment has been minimized.

Copy link
Contributor

commented Mar 11, 2019

Yes, the 'meets certain requirements' bit is the catch. Going back to the 1-5 points in a previous comment, those requirements would have to be asserted in the specification for the profile and any base specifications for that profile. If there are no requirements asserted by those specifications, then there isn't anything to conform to, in which case 'profileOf' has no testable implications. In that case, I suppose in rdf thinking 'profileOf' would mean 'uses some vocabulary (or elements?) from...' or something like that?

@kcoyle

This comment has been minimized.

Copy link
Contributor Author

commented Mar 11, 2019

That's the whole question here - PROF doesn't provide anything beyond "profileOf", and it has to have a definition. Defining it as "profileOf means X is a profile of Y" doesn't say anything. That's kind of like the Mr. Ed theme song: a horse is a horse of course. We're trying to get consensus on a meaning of profileOf when used in PROF. You seem comfortable with "uses some vocabulary" which seems to be choice a. Lars and Makx have opted for b. Point b is pretty restrictive, but it is testable, which a, c, and d are not. You can compare your profile with Y and have a yes/no answer.

@rob-metalinkage

This comment has been minimized.

Copy link
Contributor

commented Mar 11, 2019

A specification with no "conformance requirements" is a strange concept - even something like Dublin core has range declarations which are a constraint. If you narrow these, or narrow cardinality (i.e. make author mandatory) then profileOf is appropriate. These cases are all clear with the concept of constraints.

I think the "uses some vocabulary" phrase might actually be code for a more specific concept about "recommended usage where constraints are not testable". As far as I am concerned Profiles is silent about these - unless a community wants to elevate recommendations to a constraint: I can imagine a spec X (or community profile of it!) stating that more specialised profiles must "use the recommendations from X or provide an explicitly modelled alternative which a usage note stating why the recommendation wasnt considered appropriate". IMHO such a requirement is a constraint, and elevates recommendations to a constraint in this context. (this is partly why we removed Base Specification as a class - its more about the role something plays than something intrinsic to a specification.

Not all constraints are expressible formally - but Profiles is quite happy for you to have a guidance note only. At this stage there is no substantive change required, but some better guidance around scope not including general re-use has been indicated.

Definitions are already being addressed via a review #755 so the self-referential documentation style is being addressed elsewhere and this is no the place to reintroduce it. We must keep issues separate and linked if we are to make progress and avoid circular arguments.

@kcoyle

This comment has been minimized.

Copy link
Contributor Author

commented Mar 12, 2019

@rob-metalinkage We still need to know what "profileOf" means. Only then can we address how to write the defintion.

@rob-metalinkage

This comment has been minimized.

Copy link
Contributor

commented Mar 13, 2019

the object of a profileOf defines a set of constraints that must be met by resources conforming to the subject of the predicate, in addition to constraints directly defined by the subject profile.

@kcoyle

This comment has been minimized.

Copy link
Contributor Author

commented Mar 13, 2019

@rob-metalinkage What predicate? This is the first time it has been defined on the predicat, although that is logical. Is a profile a set of predicates? That would make this more clear. Can a profile be more than predicates?

Here's where I think the confusion comes in. "Profile" itself is being defined very broadly as a set of documents, some of which don't even have predicates. In fact, they may not be in RDF or in any other machine-actionable code. If profileOf is limited to machine-actionable schemas, then the definition of it needs to include that, and it needs to be clear that this is a different meaning of profile. If it is limited to schemas in RDF, then it needs to say that. Using the definition we have used for "profile", profileOf (adding "Of" to our defined "profile") can't mean anything related to processing of constraints. If it does mean conforming to constraints, then it has to be clear that it can only be used on resources that define constraints.

The problem that I see is that "profile" so broadly defined that basing any processing on "profile" is not meaningful. Other than discovery of resources, I don't think that "profile" is machine-actionable as it is defined. Actionability could be defined on certain resources but that would require having a defined set of resources that are actionable. I think that's at least a v. 1.1 use case, if not 2.0.

@rob-metalinkage

This comment has been minimized.

Copy link
Contributor

commented Mar 25, 2019

OK - the concept is so simple its hard to see why there is any debate, except for perhaps people trying to characterise generic re-use in OWA as some sort of profiling (it isnt).

So here it is in code, maybe that will help:

:aResource dct:conformsTo :Profile1 .
:Profile1 prof:isProfileOf :Profile2 .

entails:
:aResource dct:conformsTo :Profile2 .

we can add an OWL axiom to formalise this entailment - i think it would look like this

dct:conformsTo owl:PropertyAxiom ( dct:conformsTo prof:isProfileOf)

also note (because it seems to also be misunderstood or queried often enough):

:Profile1 a dct:Standard . (from dct:conformsTo range definition)
:Profile2 a dct:Standard (from isProfileOf range definition)

I will add this as a proposal to a new issue (#844 ) so it can be dealt with properly independently of the original question.

So the answer to the original question is "no", if you mean elements defined in the context of "underlying namespaces" but "yes" if you mean constraints on elements referenced indirectly through isProfileOf. So, it would be a stretch to characterise re-use as profiling but as that's not what we are saying we should close this issue.

Improved definitions and examples should address the issue.

Please vote to close this.

@agreiner

This comment has been minimized.

Copy link
Contributor

commented Mar 26, 2019

What happens when
:aResource dct:conformsTo :Profile1 .
:Profile1 prof:isProfileOf :Profile2 .
:Profile1 prof:isProfileOf :Profile3 .
and Profile2 and Profile3 disagree on one or more terms used in Profile1?
In that case, I don't think that :aResource dct:conformsTo :Profile1 implies that aResource dct:conformsTo :Profile2

@rob-metalinkage

This comment has been minimized.

Copy link
Contributor

commented Mar 26, 2019

If Profiles 2 and 3 are inconsistent then the statements are simply inconsistent - this is not a problem with the ontology - its a problem with the example. The implication is necessary because without it it is an essentially meaningless relation - and you could just use dct:relation or some other thing like skos:closeMatch. We are not modelling "closeness" in any way - only conformance inferences.

@agreiner

This comment has been minimized.

Copy link
Contributor

commented Mar 26, 2019

That would only be true if one cannot borrow terms from more than one source that do not agree on all terms used. But the whole point of using a second source would be to use terms that differ from the first one.

@nicholascar

This comment has been minimized.

Copy link
Contributor

commented Mar 26, 2019

@agreiner What you're asking for can't be solved by a vocabulary.

If Profile1 requires a particular property and Profile2 requires another, data could possibly be conformant with both, if they are not exclusive. If either Profile1 or Profile2 were exclusive, then something in the real-world couldn't conform to both of them. PROF's not getting in the way here but neither can it assist the users to overcome real-world conformances.

@kcoyle

This comment has been minimized.

Copy link
Contributor Author

commented Mar 26, 2019

While a vocabulary alone cannot solve these issues, I think the question is whether the community around the vocabulary shouldn't have a solution. In most vocabularies that I know there are things that the vocabulary alone cannot impose, but the intention of the community is clear. Naturally anyone can create bad data, but the intention of the vocabulary, and the reasons behind that, are known. Then a standard constraint application or language can be applied. I would interpret Annette's question as one to the community: what do you mean by this? what rules do you expect users to adhere to?

@agreiner

This comment has been minimized.

Copy link
Contributor

commented Mar 26, 2019

Let's take a more concrete example. Suppose you've been using DCAT 1.0 for a long time and now want to include APIs in your catalog. You make a profile of DCAT that also pulls in API descriptors from Schema.org's Data Catalog, so it's a profile of both DCAT and Schema.org. You cannot then assume that any dataset that is conformant to your profile is also conformant to schema.org.

@nicholascar

This comment has been minimized.

Copy link
Contributor

commented Mar 26, 2019

@agreiner you're doing this backwards! If you're the system designer and the one creating the profile, it's up to you to tell others what to expect. So if you said that your catalogue is using something that is a profile of DCAT and Schema.org then you are saying users can expect it to be conformant to both. If you have something that presents as a schema:Dataset then it should follow Schema.org's rules about datasets.

Since Schema.org has pretty loose domains and ranges, I guess you could use it without committing your dcat:Datasets to be schema:datasets but if you are using properties that do entail such classing, you should use the classes legally.

@kcoyle I agree that community rules around what profiling means should be present - this is the Guidance document right?

@agreiner

This comment has been minimized.

Copy link
Contributor

commented Mar 27, 2019

@nicholascar , you are assuming that a profile cannot be derived from more than one source unless the sources are conformant with each other in every respect. I think that limits the usefulness of profiles more than we want.

@kcoyle

This comment has been minimized.

Copy link
Contributor Author

commented Mar 27, 2019

Nick, the guidance document is a general document about profiles so it won't give details about PROF. If the PROF vocabulary is going to be useful it probably needs a guidance document or user guide of its own to explain better to people what everything means. Sometimes people do this in a primer.

I agree with @agreiner that conformance to profiles and vocabularies used is tricky and possibly not realistic. It has seemed to me always that conformance to terms works but conformance to entire profiles is much more difficult.

@rob-metalinkage

This comment has been minimized.

Copy link
Contributor

commented Mar 27, 2019

wow... there has never been any suggestion that some concept of partial conformance to a specification was a meaningful concept. you can't be conformant to a term - you may conform to constraints related to a term - but if you violate some of these you are not conformant to the specification.

All the Use Cases proposed assume conformance is an absolute concept since they do not define any form of partial conformance.

If you wish to propose a new set of requirements then you need to provide and get a new motivating Use Case agreed.

@dr-shorthair

This comment has been minimized.

Copy link
Contributor

commented Mar 27, 2019

Hmm. I tend to agree with Rob here: a profile will usually define a whole set of required structures and permitted values. Conformance to the whole profile is the goal. If any part of it is 'optional' then that can be omitted, but otherwise, this would be a yes-no operation over the whole thing.

@nicholascar

This comment has been minimized.

Copy link
Contributor

commented Mar 27, 2019

@agreiner yes, within the limits @dr-shorthair mentions.

@kcoyle

If the PROF vocabulary is going to be useful it probably needs a guidance document or user guide of its own

Something to think about post June perhaps... We already have a solid foundation of a lot of examples to work with, though they may all need updating still as we complete PROF.

In line with the plenary directive, I'm not going to monitor this Issue for the pause time period now.

@kcoyle

This comment has been minimized.

Copy link
Contributor Author

commented Mar 27, 2019

@dr-shorthair So you would opt for "b" as a definition of profileOf, right?

@rob-metalinkage Dublin Core profiles have no "profile of" concept, only adherence to defined terms and the definitions and constraints that define those terms in their "original" vocabulary declaration. Yet, they are profiles. We'll be initiating some more work on the DC profile concept; I'll keep in mind whether any concept of "profile of" makes sense in that environment.

@smrgeoinfo

This comment has been minimized.

Copy link
Contributor

commented Mar 27, 2019

Basic issue-- communicate to a client application what rules they can assume will be followed in an instance document representing some resource; this allows a developer to write software to access information contained in the representation.
Assumptions:

  1. there is some specification (spec1) that elucidates the rules followed by a given resource representation.
  2. specification (spec1) can use rules from other specifications (specX).
    a. If all rules from specX are part of spec1, but some rules are restricted in some way consistent with specX, then spec1 is PROFILEOF specX.
    b. If all specX rules are followed but not modified, then spec1 INHERITSFROM specX.
    c. if Spec1 only uses some rules from specX (consistent with specX), then spec1 USES specX, and Spec1 must be clear about what it is using from specX and how.

If either spec1 or specX does not specify any conformance rules for representations, then the whole discussion is moot.

@agreiner

This comment has been minimized.

Copy link
Contributor

commented Mar 27, 2019

Yes, I've been thinking along those lines, especially 2a and 2c. I'm fine with restricting profileOf to the case where any dataset that conforms to spec1 also conforms to specX, as long we also enable bringing in terms from other sources in addition. "Uses" is as good a term as any. I think one could use large sections of other profiles or standards, even using more terms from any one of them than from the one it is a profileOf. This would work if the terms brought in don't conflict with the spec that the profile is a profileOf. It should not be problematic for terms in a "used" spec that are not used in the profile to conflict with the "profiled" spec. This is analogous to reusing terms from one vocabulary in another, where that usage does not entail conformance with the entire original vocabulary. One could not infer that a dataset that conforms to a profile also conforms to a specification that the profile uses, but one could infer that a dataset that conforms to a profile also conforms to a specification that the profile is a profileOf.
@rob-metalinkage, I'm being careful here to discuss conformance of datasets to specifications and profiles, not conformance of profiles to profiles. The relationships between profiles are not about conformance. We are defining something new here.

@rob-metalinkage

This comment has been minimized.

Copy link
Contributor

commented Mar 27, 2019

@smrgeoinfo correctly distinguishes different dependency cases. the Profiles Vocabulary currently only addresses 2a, which is the case where we have explicit motivating Use Cases.

2b is addressed by owl:imports IMHO, and doesnt require a new vocabulary, though it does require an OWL/RDFS implementation. We could define this new UC and a new property.

2c is AFAICT addressed by re-use without an owl:imports, but there is no canonical way of getting the model for a specific term. This is a rather tricky general RDFS problem that I think is not possible to address in this scope IMHO. So maybe a new type of dependency could be defined for "uses terms from", and profileOf is a subproperty of this property. not sure this really logically fits inside a Profile scope, and if we include that is there any other support for this UC we could usefully provide? (without UC and examples its hard to guess)

If people really need to address the other cases happy to consider new UC and extensions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.