Re: [dxwg] property profileOfTransitive (#486)

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.

GitHub Notification of comment by rob-metalinkage
Please view or discuss this issue at using your GitHub account

Received on Sunday, 25 August 2019 23:33:26 UTC