property profileOfTransitive

riccardoAlbertoni commented 5 years ago

I guess the intention for profileOfTransitive was to replicate the modelling pattern adopted for the broaderTransitive and broader properties in SKOS. In that case, I have two issues:

I would consider renaming this property in "transitiveProfileOf". Of course, I leave the last word to native speakers but while "broaderTransitive" works well to me, "profileOfTransitive" is a little confusing, probably due to the 'Of" before "Transitive" which might be interpret as "profile of transitive" instead of "profileOf transitive".

In order to replicate the skos:broader /skos:broaderTransitive, the following statement might be added


prof:profileOfTransitive rdf:type owl:ObjectProperty , owl:TransitiveProperty .
prof:profileOf rdfs:subPropertyOf prof:profileOfTransitive .

rob-metalinkage commented 5 years ago

+1 that is exactly the interpretation behind the profiles ontology design.

Not sure i understand the last para.. there is only one DCAT-AP being discussed anywhere as far as i can see so i think you are saying in an inside out way that we do have a working definition consistently modelled?

kcoyle commented 5 years ago

I was responding to this in Nick's note:

@kcoyle “...if something like the DCAT-AP PDF can be considered a profile...”

According to Profiels Ont it wouldn’t be, it would be the artifact of a Resource Descriptor. See the on point example: https://w3c.github.io/dxwg/profilesont/#eg-dcat-ap

The question is: is the subject in the following triple coherent with the profilesOnt definition of prof:Profile?:

This follows from the definition of the domain of prof:profileOf as prof:Profile. So I'm trying to clarify what the nature of prof:Profile is because it isn't clear to me, so I was using DCAT-AP as a concrete example. To me, the DCAT-AP specification expressed as it is in the form of a PDF meets the definition in profilesOnt and profgui documents for _profile_. If, however, it does not meet the intended usage in profilesOnt then I think we have a problem with our definition of profile and we need to work to reconcile that. (The definition of prof:Profile does not connect to the definition of prof:ResourceDescriptor, and the diagram at https://w3c.github.io/dxwg/profilesont/#eg-hierarchy doesn't clarify that for me.) (I have other questions about the diagrams, but let's clarify this first.)

makxdekkers commented 5 years ago

@kcoyle You asked for my view on "Conformance implementation can take place elsewhere or even be unknown to the profile, and it does not have to be co-existent with the profile specification". I must honestly admit that I don't understand your statement, so I am afraid that I can't clarify it. Can you define "conformance implementation"? Are you making a distinction between a "profile" and a "profile specification"? The situation with the EU DCAT-AP is that there is a document (draft of latest version at https://github.com/SEMICeu/DCAT-AP/tree/master/releases/1.2/Draft) and a SHACL file that can be used to validate instance data (https://github.com/SEMICeu/dcat-ap_shacl, cardinality and ranges). Does that help?

kcoyle commented 5 years ago

@makxdekkers Thanks, I realize that this thread has taken quite a turn! The "conformance implementation" is based on terminology in the profiles ontology and I believe it simply means what you say above, which is some code or machine-actionable document that can implement the constraints in the profile. But the main question I am asking is: is DCAT-AP itself (the document of that name) consistent with the definition of prof:Profile?

The first question is "what is a prof:Profile"? The second is: Must a profile include actionable conformance? Obviously, one answer hinges on the other. (Another wording: does conformance here mean actionable code, or can it mean described verbally but not itself actionable?)

If I have X-AP which is a document much like DCAT-AP, but I have no conformance code, is X-AP a profile by the definition in profilesOnt?

I'm trying to clarify the statement above that says: I dont think it makes sense to talk about specifications or standards or profiles without an assumption of conformance. followed by my question of whether DCAT-AP (the PDF document with that title) can be used in a profilesOnt statement:

<iri for DCAT-AP.pdf> prof:profileOf <iri for DCAT>

or if the subject of that triple must be an IRI for a profilesOnt structure, as in the various diagrams.

All of this is triggered by the interaction above:

@kcoyle “...if something like the DCAT-AP PDF can be considered a profile...”

According to Profiels Ont it wouldn’t be, it would be the artifact of a Resource Descriptor. See the on point example: https://w3c.github.io/dxwg/profilesont/#eg-dcat-ap

That was where my confusion began. And now I probably have added to yours. But it is needed to clarify how the profiles ontology can be used and how strict it is in defining "profile".

makxdekkers commented 5 years ago

@kcoyle It's an interesting question. I can see a analogy here with Dataset. A similar question could be: If I have a file with data, is that a dcat:Dataset? In that case, no, it isn't; the file is the Distribution of a Dataset. In the case of profiles, it is a similar situation: the prof:Profile is the 'conceptual' resource, and the specification document is one of the possible serialisations of it, just as the SHACL file is another. Please note that the files linked from https://joinup.ec.europa.eu/release/dcat-ap-v11 at the bottom of the page are shown under the heading 'Distributions'! So my answer would be, no, the human-readable document is not the prof:Profile. The definition at https://w3c.github.io/dxwg/profilesont/#Class:Profile is correct as far as I am concerned: it says a prof:Profile is a "named set of constraints", not a "document containing a set of constraints".

makxdekkers commented 5 years ago

And as I see it, the Profile Ontology defines the semantics of prof:Profile, not the English word 'profile', the meaning of which you would look up in an English dictionary.

nicholascar commented 5 years ago

@kcoyle: the give-away is that you've referred to a DCAT-AP resource ending in .pdf, viz. <iri for DCAT-AP.pdf>, which is, as @makxdekkers says, a distribution of the conceptual thing, the profile.

So, "Must a profile include actionable conformance?": No. You could declare a profile like this, using your demo URI:

<http://example.org/catalogue/profile-x> a prof:Profile ;
    rdfs:label "Profile X" ;
    prof:hasResource <http://example.org/catalogue/profile-x/distribution-y> .

<http://example.org/catalogue/profile-x/distribution-y>
    a prof:ResourceDescriptor ;
    rdfs:label "Profile X Guidance Document (PDF)"  ;
    dct:format <https://w3id.org/mediatype/application/pdf> ;
    prof:resourceRole roles:Guidance ;
    prof:artifact <iri for DCAT-AP.pdf> .

So this is s conceptual profile with one ResourceDescriptor which is a PDF document with the role of Guidance. No SHACL-like resources in sight!

kcoyle commented 5 years ago

This is all fine - for folks who are imbued with knowledge of DCAT datasets and distributions. I'm not sure how this plays beyond that environment. So much depends on who we see as the audience for the profile guidance and the profiles ontology. For example, someone with a "physical" profile document (pdf, txt, whatever) but who hasn't encountered DCAT dataset/distribution concepts may find it intuitive to consider that file to be a profile. If we go this abstract/distribution route then we must use the abstraction/distribution distinction in the guidance document. This may narrow the audience for that document and for profiles ontology, making it less likely to be accepted more widely. With my DCMI hat on, I don't see this as desirable. I do see a possibility to create a profile guidance that is parallel to DCAT, and I also see a possibility to create a general definition of profiles that is not directly related to DCAT. However, I think these are two different efforts, and we will need to decide which we will deliver.

rob-metalinkage commented 5 years ago

I dont see the problem - its the standard http-Range14 issue - we can just refer to any of the common examples if we feel we even need to address it at all - e.g. hit Wikipedia and it will redirect to a language specific page.

The wording just needs to remind people that a profile can be expressed in many different ways, and some of those may be partial (e.g. some parts can be expressed in SHACL), so the profile is abstracted from its artefacts, this is why we have an abstract model in place already. Thus the issue is a purely editorial one of getting the best wording we can with the effort available.

makxdekkers commented 5 years ago

@kcoyle I don't understand. I see no problem with people calling their document a 'profile'. A lot of people will not be interested to formally describe their profile in LD terms, so they have no need to even look at the Profile Ontology. They can even call each of the eight files at https://joinup.ec.europa.eu/release/dcat-ap-v11, 'the profile'. But: as soon as they want their profile to play in the LD world, they will read the specification of the Profile Ontology and understand what the ProfOnt classes mean and how to describe their physical artefacts. They may still call their document colloquially 'the profile', but they'll know that their document is not the prof:Profile. The same situation occurs with someone who has a file with data. If that person wasn't familiar with DCAT, he or she may find it intuitive to call that file a 'dataset', and that's fine. It is just that for the description of the file with DCAT, that person would need to read the specification of DCAT and then understand that the file is not the dcat:Dataset.

nicholascar commented 5 years ago

@kcoyle said "I do see a possibility to create a profile guidance that is parallel to DCAT, and I also see a possibility to create a general definition of profiles that is not directly related to DCAT. However, I think these are two different efforts, and we will need to decide which we will deliver."

The Profiles Ontology, and the Guidance document, aren't tied to DCAT so we should be creating general definitions of profiles. Having said that, there's nothing that I can see in DCAT's formulation of things that is problematic for profiling so we should also be able to have "profile guidance that is parallel to DCAT" too in so far as Dataset relates to Distributions and Profile relates to Resource Descriptors.

Having a profile abstracted from its artefacts paralleling a Dataset abstracted from its Distributions, as @rob-metalinkage says above, is the flexible, sensible way of modelling things. DCAT makes the split for this purpose.

@kcoyle daid "...someone with a "physical" profile document (pdf, txt, whatever) but who hasn't encountered DCAT dataset/distribution concepts may find it intuitive to consider that file to be a profile.".

Sure, and when not talking about their document with the precision a formal ontology brings, that might be fine. But when they come to formally define things and perhaps when their profile becomes a bit more complex and powerful (e.g. wanting to create a schematron file from the PDF and use the PDF for Guidance, the schematron for Validation) then they abstract the notion of the Profile away from the 'physical' document.

The Geoscience Australia Profile (of ISO19115-1) is a good case in point: the profile used to informally refer to a Guidance document which was then put up in the GA catalogue in DOCX and PDF forms (http://pid.geoscience.gov.au/dataset/ga/122551), so then they had effectively a conceptual Profile (Dataset) and Profile Descriptors (Distributions). Now, GA have put their profile up as a bundle of things: an overview web page (http://pid.geoscience.gov.au/def/schema/ga/ISO19115-1-2014), code lists, schematron files, XSDs etc. The Profiles Ont is able to describe the GA Profile at all stages.

@makxdekkers - agree! We are on the same page here. You posted that as I was typing this out!

kcoyle commented 5 years ago

I agree with @rob-metalinkage that the wording of the document needs to explain that the profile is abstracted from its parts. I don't see that in the current version of the document, and the diagrams do not make that clear to me. Basically, everyone who reads the document needs to come away with this concept, even if they are unaware of the parallel model in DCAT.

@makxdekkers "But: as soon as they want their profile to play in the LD world, they will read the specification of the Profile Ontology and understand what the ProfOnt classes mean..." You are much more optimistic than I am. As is often said, the great thing about standards is that there are so many of them to choose from. That, and the fact that there is no enforcement. However, the key thing here is that the profiles ontology document must be very clear if it is to be used widely. Then users will choose to use it or not, but hopefully those who choose will be using it correctly.

@nicholascar said: But when they come to formally define things and perhaps when their profile becomes a bit more complex and powerful (e.g. wanting to create a schematron file from the PDF and use the PDF for Guidance, the schematron for Validation) then they abstract the notion of the Profile away from the 'physical' document. This brings up an essential question of authority that some of us are very familiar with from the library world. When there is a SHACL document and a ShEx document and a Schematron document and they either conflict or have minor differences, which is the authoritative statement of the profile? When there is a written/verbal document (like DCAT-AP.pdf) and it has aspects that cannot be expressed in SHACL ("mandatory if applicable") which is the authoritative statement? This probably arises less in DCAT because the distributions are all distributions from "a" dataset, meaning that there is probably a parent physical file somewhere (usually) that one can go back to. In the profiles case, it isn't clear if there is an authoritative parent, and the model is much more complex because the parts are not all distributions of the same thing. (I'm assuming that one is not required to have a written document as the foundation for a profile, but any set of artifacts makes a profile.) In fact, with profiles it is much more complex, and reminds me of some library cases. For example, in bibliographic description when you have a translation you want to know what version of the text was the basis for the translation, or if a translation is a translation of another translation. With profiles, if you have SHACL and ShEx validation documents, were they developed independently or was one derived from the other (there are translation programs between them). Without a parent or an anchor for all of the artifacts that make up the totality of the profile you have a lot of uncertainty. Also, you may need more information about the relationship between artifacts. How much this matters depends on the individual case. In fairly coordinated environments this may not have an affect. In the wild web world, like the one that schema.org operates in, usage of artifacts could be error-prone if their exact nature in relation to the content of other artifacts is not clear. That's not an argument against the model, but a caution for developers. Nor is this an argument to create a more complex model (which the library world does, and it's hellish-ly complex). But I think it is important to acknowledge that we are aware of these complexities, and to state a position in relation to them.

larsgsvensson commented 5 years ago

@makxdekkers scripsit:

The same situation occurs with someone who has a file with data. If that person wasn't familiar with DCAT, he or she may find it intuitive to call that file a 'dataset', and that's fine. It is just that for the description of the file with DCAT, that person would need to read the specification of DCAT and then understand that the file is not the dcat:Dataset.

void:Dataset being an obvious case... (VoID predates DCAT)

makxdekkers commented 5 years ago

@larsgsvensson Yes, and this was the background for the use case https://www.w3.org/TR/dcat-ucr/#ID36 and requirements https://www.w3.org/TR/dcat-ucr/#RVC and https://www.w3.org/TR/dcat-ucr/#RVM.

larsgsvensson commented 5 years ago

@makxdekkers Ah, OK. Thanks for giving me more context!

rob-metalinkage commented 5 years ago

This has largely superceded the "what is a profile" issue - and I think we have a convergence around the abstract model proposed. @kcoyle points out that we still need to work on messaging for some audiences, and as editor I'm always happy to help facilitate proposed improvements in wording - probably need these raised as specific issues in place in the documents to discuss and progress - so the process has to be first see if such issues exist in place, create if missing, then move them towards a proposed improvement.

This issue has done its job by teasing out feedback, supporting a discussion and reaching consensus that we have a position that does seem to make sense. I suggest we close it now.

kcoyle commented 5 years ago

I believe that issues should be closed when they have been resolved within the document. Until that happens, it should stay open.

nicholascar commented 5 years ago

@kcoyle in https://github.com/w3c/dxwg/issues/486#issuecomment-435887068. Yes, indeed, there's potentially many complex things that could be modeled but, like original DCAT, let's get this fairly simple model out there and leave complexity to PROFv2! Profile relation typologies, fine-grained ResourceDescriptor/Profile relations etc. all interesting and difficult but I don't fancy an ontology with many more classes and relations than we have now.

Currently there is no way in ontology land to formally define a profile and its bits, at any level of detail, so this is an improvement, and even if more finessing may be desired, I would hope simplicity will see wider adoption.

aisaac commented 5 years ago

OK I'm going to be very blunt: what in the discussion in the past three days is about the original topic of this issue? There was a proposal at https://github.com/w3c/dxwg/issues/486#issuecomment-434123157 Is there anything against it?

It is about the name of a property involved in a 'transitive closure' pattern and the axioms defining this property. This is not about profileOf. Actually it really doesn't say anything about profileOf, just as the existence of skos:broaderTransitive didn't say anything about the semantics of skos:broader (https://www.w3.org/TR/skos-primer/#sectransitivebroader). It's just a technical trick to make available a shortcut for a chain of profileOf statements, when such a chain exist, and for the people who are interested in such a shortcut. It doesn't 'pollute' the original profileOf statements at all. So again is there any objection against the proposal from 8 days ago?

rob-metalinkage commented 5 years ago

no - and it was discussed agreed ana actioned - which is why i wanted to close this.

nicholascar commented 5 years ago

This is now well exemplified in the document and hasn't had comments for months.

kcoyle commented 5 years ago

Nick, this deliverable is on hold, so of course there hasn't been a comment for months. Be patient! It'll probably take some time to ramp back up.

rob-metalinkage commented 5 years ago

@kcoyle - this is not accurate in that the comments stopped well before the "on hold" declaration - not that "on-hold" makes sense given the deliverable is specified in the recharter and its now August.

kcoyle commented 5 years ago

@rob-metalinkage The deliverable is on hold.

tombaker commented 4 years ago

@rob-metalinkage I do not see the basis for closing this issue - the three up-votes for a proposal ten months ago in this issue thread? The discussion thread above is long and quite unreadable. To close such an important issue, there really should be a clear statement of the problem, summary of the discussion, and a proposed resolution, ideally recorded somewhere else than just in Github (or does W3C accept Github issues as statements of record?). Summaries of this sort provide an intellectual audit trail for anyone in future wanting to understand the rationale for the vocabulary's design (e.g., see the extensive links in a paper that @aisaac and others wrote on about issues in the design of SKOS).

I take @aisaac 's point that the transitive closure pattern is "just a technical trick to make available a shortcut for a chain of profileOf statements", but SKOS involved real existing concept schemes where thousands of concepts were organized in complex and overlapping hierarchies, and being able to treat relations that were declared as non-transitive, as if they were transitive, on the basis of inferencing, made sense at such a scale.

How many "profile of a profile of a profile of" situations exist between real existing profiles today? Everyone has been acknowledging that real-existing profiles today are overwhelmingly stand-alone things, starting with DCAT. Proposing a design pattern based on how people may or may not design profiles in the future feels just a bit overengineered and prematurely complexified - something which, given the typical messiness involved in anything related to metadata, actually has a fairly high potential for being misused. In the lack of well-developed guidance on profiles (the "missing Rec-track deliverable"), why not err on the side of simplicity (i.e., drop the inferencing trick) and see, over time, where implementers really want to take this? Would dropping this actually break any existing implementations?

smrgeoinfo commented 4 years ago

Seems like this issue depends first on the resolution of w3c/dxwg#643, where the question (as I read it) is 'is the prof:profileOfTransitive property necessary'. A lot of the discussion here is more germane to w3c/dxwg#643. If the answer to that is NO, then this issue is moot. If the answer is yes, then the original questions here are:

should 'profileOfTransitive' be renamed 'transitiveProfileOf'
should two assertions be added to the ontology: prof:profileOfTransitive rdf:type owl:ObjectProperty , owl:TransitiveProperty . prof:profileOf rdfs:subPropertyOf prof:profileOfTransitive .

It looks like there are 4 upvotes on this proposal (https://github.com/w3c/dxwg/issues/486#issuecomment-434123157, and following comment from @nicholascar). FWIW I'm +1 on the proposed changes on as well.

rob-metalinkage commented 4 years ago

@tombaker this statement is not consistent with the examples already provided: "Everyone has been acknowledging that real-existing profiles today are overwhelmingly stand-alone things". It has been discussed at length in this thread already and clearly the opposite case is demonstrated and acknowledged ( @kcoyle "There is logical semantic "inheritance" ")

Can you please move that discussion to a new issue if you want to bring evidence that you believe refutes the existing Use Cases. Nothing stops a community disallowing profiling by policy - or requiring that profiles have validation resources that combine all inherited requirements. Such specific choices do not affect the model in the general case as long as they are supported.

In anycase @kcoyle indicated this issue should have been closed because its gone off topic - and i indicated it should be closed because the the original point was taken on board, discussed, a proposal accepted without dissent and changes included in the 2PWD. New feedback is required to reopen this surely?

BTW Github issues persist - this was a interesting discussion but its not useful as a actionable issue going forward.

kcoyle commented 4 years ago

@rob-metalinkage I wish to make clear that nothing that I have posted should be taken as support for non-standalone profiles. Obviously, we need to define precisely what we mean by that, but my point about "semantic inheritance" is for the human mind to observe and is not subject to any programming requirements, and therefore is irrelevant to a vocabulary for defining profiles. Or to say this another way, I would not accept a definition of profile that requires the creation of code that makes use of a "profileOf" statement and does any "include" or validation between profiles. If folks want to do that, it's obviously not dis-allowed, but I wouldn't make it part of a vocabulary today without widespread proof of concept, which I do not see.

We did indeed conclude that all of the profiles that we have seen to date are "standalone". See w3c/dxwg#228. And there was support for keeping it that way. I don't know where you see agreement for the opposite. To confirm the "standalone" proposal we could call for a concluding vote in that thread or with a poll. However we decide it, an explication of the idea could take place in the guidance document. I think that making a decision regarding PROF could be separate since there is no rule that PROF has to concur with the profiles guidance. A proposal could be made on wording for PROF and a definition of what is meant by "profileOf" (which we have attempted in w3c/dxwg#507 and the decision was deferred) which the WG could vote on.

rob-metalinkage commented 4 years ago

At the bottom of this comment is a suggestion to improve wording to help people understand this matter.

But first it needs to be pointed out that there are at least three problems with the claims in the last comment :

1) it is reverting to confusing the "logical" profile with a choice of representation - feel free to do the representation any way you like, but nothing about existing representations has bearing on the fact that logical profiles need to be separately identified and have relationships. 2) Nothing stops you choosing to flatten out your representations but that doesnt mean you can or should impose that view on every community 3) Given that for example published OGC specifications in the form of profiles certainly do not repeat all the constraints of base specifications it would appear that you are not looking at a wide enough sample to attempt top draw any such conclusions. 4) "We did indeed conclude" does not reference any formal decision making process which is relevant here - and the cited issue w3c/dxwg#228 actually supports the opposite view - the suggestion in the title to the same effect there was also refuted.

the actual conclusion in w3c/dxwg#228 was a consensus around some sort of statement like

"Profiles are hierarchical in nature but SHOULD be published as stand-alone resources containing all needed elements and constraints, as required by expected use."

noting that this a) does not make this mandatory and b) specifically says "stand-alone resources" whist stating "Profiles are hierarchical in nature "

Its not well enough worded perhaps because we are not citing it naturally to remove this unnecessary sense of incompatibility with expectations.

Happy to improve the wording here - but this is fundamentally a user choice and thus is really a matter for guidance - not the profiles vocabulary, which merely provides a canonical mechanism to do this either or both ways.

Can I suggest we make it more explicit:

"Although profiles may be hierarchical in nature it is considered advantageous to publish stand-alone resources containing all needed elements and constraints to fully describe a profile for convenience of systems so that the full hierarchy of profile descriptions and resources do not need to be accessed and merged during use. Such stand-alone resources SHOULD indicated via import or annotation mechanisms which specifications require each constraint. Profiles MUST use the "validation" role classifier to identify such resources if available."

I think that this addresses your underlying concern and requires no change (beyond improved annotations) to the 2PWD profiles vocabulary.

smrgeoinfo commented 4 years ago

Last two sentences in the suggestion above are not clear

Such stand-alone resources SHOULD indicated via import or annotation mechanisms which specifications require each constraint. Profiles MUST use the "validation" role classifier to identify such resources if available.

Here's my guess for what they mean:

A standalone profile that inherits requirements from a 'parent' specification should indicate the source of those requirements via import(???) or annotation mechanisms. If either software to validate conformance of instance documents to the profile, or documentation describing validation processes is available, the hasResource property should be used to specify this ResourceDescriptor with hasRole 'validation'.

kcoyle commented 4 years ago

@smrgeoinfo I'm going to use an example from my community, libraries. There is a one-namespace RDF vocabulary (BIBFRAME). In this case, profiles are all subsets of the main vocabulary. Subsets do NOT include terms from other vocabularies. (Yes, libraries are a bit rigid about these things.) Obviously one does not do an INCLUDE of a larger vocabulary for a subset, or it is no longer a subset. In fact, what is in operation at the moment is that the URIs of classes and properties suffice to make the connection between the usage in the profile and the usage in the main vocabulary.

This particular use case does not seem to be compatible with the statements you are commenting on. Do you agree?

smrgeoinfo commented 4 years ago

Yes in that case it seems that simply stating A is a profile of B (where in your example B is BIBFRAME) would be sufficient. There is no validation-related resource descriptor so the second sentence is irrelevant. Perhaps the first sentence should read

A standalone profile that inherits requirements from multiple 'parent' specifications should indicate the source of those requirements via import(???) or annotation mechanisms.

But since I'm trying to interpret the sentence from @rob-metalinkage "Such stand-alone resources SHOULD indicated via import or annotation mechanisms which specifications require each constraint.", perhaps we should wait for him to weigh in on whether my interpretation is on the right track....

rob-metalinkage commented 4 years ago

OK some progress.

@smrgeoinfo - not quite - thats mixing up the resource and the logical profile: profiles are not "standalone" if they inherit - but resources describing them may be (but again note they may be partial descriptions and still standalone

Take a typical OGC XML based web service profile - the service specification has multiple parts which can be validated separately: 1) data payloads - described using XSD 2) functional behaviour - described using a set of rules in a testing engine

Profiles typical introduce a schematron validation to apply in addition to the XSD

deployments may use a organisational profile - explicitly or implicitly - which sets standards for metadata content to deliver in payloads. Schematron doesnt support this content validation.

so we need to be careful we dont take one use case around vocabulary subsets and draw incorrect conclusions about the nature of resources used or needed in general, or skew wording to obscure the fact that the the profiles vocabulary intends to, and does, address all these cases.

@kcoyle I think there is no "incompatible" issue here as the statement being discussed is fully qualified by the preceding sentence: "Although profiles may be hierarchical in nature it is considered advantageous to publish stand-alone resources containing all needed elements and constraints to fully describe a profile for convenience of systems so that the full hierarchy of profile descriptions and resources do not need to be accessed and merged during use."

and its a good point that namespaces are a sufficient mechanism in RDF world - i keep trying to reduce assumptions that RDF is in use but since that is what it does well we can explicity mention is as an example.

first lets see if we can circle in on understanding the Use Case that seems to be hard to map to the existing descriptions:

in the case of a simple profile being a subset of terms in a larger vocabulary - there are two possible (and both valid) interpretations of "subset": 1) this is a mandatory subset which needs to be present for a particular use 2) this is a recommended subset for a particular use

In each case the "conformance" statements each community want to make need to be expressed in terms of the resources they provide. Profiles ontology itself does not cover conformance validation mechanisms, but provides a means to express the semantics of cases where a resource that conforms to Profile B (of specifications A,B, etc) may be inferred to also conform to each Specification A,B etc. That is its main purpose, as no other canonical way to do this has been identified and its critical to applications like DCAT.

As soon as you reference another vocabulary to subset it you have a namespace that provides a mechanism to reference the base specification - so our wording needs to capture that since its not obvious enough.

"Resources representing aspects of profiles, and in particular resources that claim to support validation of the entire profile ("validation" role) SHOULD unambiguously reference the specification that introduces requirements either included or constrained within the profile. This SHOULD be done by means most suitable to the form of representation, and MAY include use of URI namespaces in RDF, import and include statements, explicit data models defining attributes or annotation properties in machine readable forms and citations in text documents. "

possible SHOULD => MUST ?

The implication is that you can publish resources that duplicate requirements but do not reference a profiled specification - but it would obviously be either hard work for clients to understand these, or a requirement that clients "know" base specifications already : such as a software agent that.

nicholascar commented 4 years ago

The original two suggestions - to rename the property like SKOS's and to replicate the skos:broader /skos:broaderTransitive pattern - have been adopted.

The final comment seems to indicate that there is only one outstanding task here for editors:

As soon as you reference another vocabulary to subset it you have a namespace that provides a mechanism to reference the base specification - so our wording needs to capture that since its not obvious enough.

The second point:

possible SHOULD => MUST ?

has been rendered redundant due to others changes in the document's text.

w3c / dx-prof

property profileOfTransitive #2