Profiles Ontology Figure 3

[kcoyle]

Figure 3 of the profiles ontology contains some "difficulties" that need to be addressed.

First, there is the inclusion of the rdf:type's as "things" in the diagram. While not inaccurate, they are unnecessary and make the diagram more difficult to read. While classes can be useful, they are generally considered to be semantic aspects of entities and not separate things in themselves.

Second, there is here a "Standard X" that has a prof:hasResource linked to RS 1. AFAIK, standards are not covered by PROF, only profiles are, so it's confusing that this "Standard X" has a PROF-defined resource. If it is a standard then I would expect for there to be a profile that is a profile of that standard that then has a resource. At that point the diagram would have two profiles (maybe X and Y), with X having resource RS 1 and Y having resources RS 2 & 3.

Suggested: 1) remove boxes denoting classes. The class'ness is included in the definition of the properties (their domains) 2) resolve the issue of Standard X and "has resource" (the other option is that PROF has to become an ontology for both non-profiled standards as well as profiles)

[rob-metalinkage]

It may well be worth having two simpler diagrams to replace this - or to use shading to represent class not "meta-class".

the use of a prof:hasResource from a dct:Standard is not incorrect:

1) a Standard is implicitly a profile of itself with a empty set of constraints ( in the same way Class C rdfs:subClassOf Class C ) 2) there is no other vocabulary to attach resources to Standards using a qualified association, PROF is deliberately design to be useful in this context. Its should not be necessary to explicitly declare something as a profile 3) from the perspective of describing a profile, it is important to describe what resources are associated with a base specification

that said, i suspect that some focus on describing the "competency questions" of PROF might help, as it will be more obvious what it can do that cannot be done without it.

[aisaac]

For the record, I've also put some editorial input at https://github.com/w3c/dxwg/issues/642#issuecomment-460583433 Would it help if it's copied here, or is it ok to leave it there?

[kcoyle]

@rob-metalinkage I agree that "the use of a prof:hasResource from a dct:Standard is not incorrect" - this is RDF, after all, and I looked at the ontology and the domain for hasResource is open, so it is any owl:Thing. The problem is that this isn't addressed anywhere in the descriptions of PROF so having it appear "unannounced" in a diagram is going to cause confusion.

Adding standards here would require that "standard" as it is used in PROF needs to be defined. " 1. a Standard is implicitly a profile of itself with a empty set of constraints" doesn't cover "standards" as a whole, IMO. "Standards" is everything from rules for the manufacturing of ladders to the vitamin D content of milk, and I'm wary about stepping into this area without really thinking it through.

[kcoyle]

@aisaac I think our comments are on the same track so it could be very useful for you to copy yours here so we can look at them in one place. I wonder if this isn't something we should "sprint" on in general? ("general" meaning the diagram style in general, not just this one here)

[aisaac]

@kcoyle I think you're right about working on diagram style in general, but now I'm contemplating the possibility of having the same kind of comments copied everywhere (and answered everywhere) and to avoid this I prefer to check with @nicholascar if it's how he'd prefer to work on it. And then we can move the comments where they're best fit (and not copy them around).

[fellahst]

I would like to share with you the results of OGC Testbed 14: Characterization of RDF Application Profiles for Simple Linked Data Application and Complex Analytic Applications Engineering Report http://docs.opengeospatial.org/per/18-094r1.html (section 10 is relevant to this thread)

[rob-metalinkage]

Thanks @fellahst .

The semantic grounding here is full consistent with the W3C profiles vocabulary:

"One or more subsets of vocabularies can be used to define an application profile. The concept of Profile is defined as a subclass of Dublin Core dct:Standard. A dataset used by a given application conforms (dct:conformsTo) to an application standard. A vocabulary can be used by multiple application profiles."

The additional semantics of a "schema" seem to be the key area where this work is more specialised than the general solution. The idea of schema mappings is out of scope, but perhaps it is another resource with a different role using the qualified role metamodel of prof:ResourceDescriptor/prof:hasRole

From what I see it looks like treating a schema as an expression of the profile in the W3C profiles/dcat alignment is a special case of a dcat:Distribution, via the class prof:ResourceDescriptor. I think you could keep these classes and axiomitise a x:Schema rdfs:subClassOf prof:ResourceDescriptor - and if you want to preserve the "schema" role is could be a subProperty of prof:hasResource.

If you concur please note that here, or if you disagree could you provide a worked example using the prof: vocabulary to show where it fails to support your needs?

w.r.t. the further work suggestion :

"Metamodel for RDF Application Profiles: This ER proposes an initial metamodel for describing RDF application profiles. It aims at facilitating search and discovery of application profiles based on specific ontologies. Testbed-12 investigated an Application Programming Interface (API) for a semantic mediation service and defined an SRIM profile for a semantic registry to represent schemas and schema mappings. This work can be extended and refined to accommodate RDF application profiles, so they can be searched and discovered by registry clients and used by a semantic mediation service."

I think the emergence of a consistent but more general W3C model for profiles could be used as the basis for an extended model to support the same competency questions, and this would be a good focus for a followup testbed.

Note that I will be describing the subset of OGC published specifications that are profiles (according to the general conceptual model) using the W3C profiles vocabulary in the OGC Definitions Server - and it could easily be extended to support these more specialised concepts.

[andrea-perego]

@rob-metalinkage wrote:

The additional semantics of a "schema" seem to be the key area where this work is more specialised than the general solution. The idea of schema mappings is out of scope, but perhaps it is another resource with a different role using the qualified role metamodel of prof:ResourceDescriptor/prof:hasRole

I think this could be indeed a useful addition to PROF. IMO, being able to discover if mapping rules are available to transform meta/data between schemas is quite a common use case.

[kcoyle]

I'm not clear on what the OGC definition of schema actually entails, but this looks to me like the "domain model" boxes in the Singapore Framework. The OGC document says: "Schema defines the structure and constraints on a conceptual model." Which is what we often see in UML diagrams. @andrea-perego it isn't obvious to me that this definition of schema would be amenable to mappings. The mapping rules are what my community refers to as "cross-walks" - converting from one metadata schema to another. Is that what you are interested in? If so, those are often machine-readable and sometimes machine-actionable. Would you want to have a role for the conversion code itself?

[andrea-perego]

@kcoyle , I understood @rob-metalinkage was referring to the notion of "SchemaMapping" in Section 10 of the OGC document @fellahst kindly shared:

http://docs.opengeospatial.org/per/18-094r1.html#Application_Profile_Metadata

Quoting:

• SchemaMapping defines the transformation from one source schema to a target schema (using XSLT, Script, SPARQL rules, or other mapping languages). SchemaMappings are also modeled as specialization of dcat:Dataset. A schema mapping can have zero or more distributions that define the encoding of the schema mapping using different representation techniques (adms:representationTechnique) [10] such as XSLT or other schema mapping languages.

And, yes, I think it may be worth considering adding in PROF resources about cross-walks / mappings, with a specific role. Actually, we need two roles and/or relationships: one pointing to the source schema/profile, and the other one to the target schema/profile.

[nicholascar]

Original suggestions by @kcoyle:

remove boxes denoting classes. The class'ness is included in the definition of the properties (their domains)

I've redrafted the diagram to remove these

resolve the issue of Standard X and "has resource" (the other option is that PROF has to become an ontology for both non-profiled standards as well as profiles)

I've bypassed this by just using an example where a Profile inherits a Resource from another Profile, not a Standard. While not incorrect, as @rob-metalinkage says in his first comment, there's no need to specifically bring in that detail into this example so we can reduce complexity here.

From @aisaac:

For the record, I've also put some editorial input at #642 (comment) Would it help if it's copied here, or is it ok to leave it there?

You can leave the comment there. I think I've addressed all your points in this new release.

Comments from @fellahst & @andrea-perego:

Important comments but this Issue, 731, is narrow so I'm going to address it here and transfer OGC-related thoughts to another.

This diagram is now in PR https://github.com/w3c/dxwg/pull/790

[nicholascar]

OGC discussion quoted from here and taken up in Issue https://github.com/w3c/dxwg/issues/791

[kcoyle]

This was also commented on by Paul Walk:

Diagrams - relationships

I find the diagrams quite difficult to understand. I think I'm unclear whether the diagrams represent entity relationships or object-oriented-hierarchies. These seem to be mixed together - for example the relationships between Standard and Profile. I guess it's not necessarily invalid for these to be mixed in this way, but I find it unusual and a little confusing.

https://lists.w3.org/Archives/Public/public-dxwg-comments/2019Jan/0006.html

This references all of the diagrams. When they are all modified, he needs to be contacted to see if he feels his comment has been addressed.

Please do not "due for closing" until others in the thread weigh in to say whether it resolves their concerns.

My answer is this is much better, but the "OWL named individual" is unnecessary. The diagram is not specific to OWL.

Also, I don't think this related to #791, which is about adding a role for mapping.

[kcoyle]

@andrea-perego If we include roles for mapping, it seems that there should be two (at least?) - mapping documentation and mapping schemas. In my world, unfortunately, most of these are just documents, such as http://www.loc.gov/marc/dccross.html.

[rob-metalinkage]

i think we only need one role at this stage, because the format and the profile the artifact conforms to will provide information about "how it works" - if its XSLT then you expect it to be a schema mapping for XML. SHACL then for RDF. A PDF or HTML resource is going to be a document. An implementer can declare specific profiles for what ever form of mapping document they want to make canonical in their context and declare it using PROF.

note this doesnt preclude further refinement of these or addition of additional properties to describe the mapping - just we dont need to get into the nuances at this stage and dont have driving use cases or resources available to justify more detail.

[andrea-perego]

@kcoyle said:

@andrea-perego If we include roles for mapping, it seems that there should be two (at least?) - mapping documentation and mapping schemas.

Yep.

[andrea-perego]

@rob-metalinkage said:

i think we only need one role at this stage, because the format and the profile the artifact conforms to will provide information about "how it works"

Not sure I completely get your point. What is needed is to say that X (e.g., the GeoDCAT-AP XSLT) provides mappings from A (e.g., ISO 19115) to B (GeoDCAT-AP). This of course needs to be modelled with relationships. Whether these relationships correspond or not to roles, this of course depends on whether roles are concepts (as it is now in PROF) or relationships themselves.

[rob-metalinkage]

The original issue has been superseded by updated diagrams. Re-open with specific comments on new diagrams if relevant.

[kcoyle]

@rob-metalinkage No, it hasn't. I asked for other changes above. You only close when everyone agrees to close. Plus, I don't see Figure 3 in the document now at all.

[makxdekkers]

I still have no idea what isInheritedFrom means. The definition "A Profile's Resource Descriptor has been inherited from a base specification" is entirely circular. Moreover, in Fig. 5, if RD2 refers to the same artifact as RD1, I would assume RD1 and RD2 to be identical. And how is it possible that Profile Y links to two different constraints files? The diagram would make sense to me if there was no RD2.

[rob-metalinkage]

This issue is not longer useful, there have been so many related issues tangled up in it. A set of changes has been made to the diagram, incorrect assumptions about dct:Standard addressed (they obviously can have resources given the domain of prof:ResourceDescriptor) and topics have been taken out to other issues (#791 for mapping, #842 ) thats enough to close this overloaded issue. Concrete proposals for further improvements can be made in new issues.

[kcoyle]

There also needs to be one for Andrea's to add mapping schemas to the set of roles.

[kcoyle]

I'm ok with closing when the owl:namedIndividual is removed.

[aisaac]

Could we delete the comments about the OGC testbed? Now that @nicholascar has copied the stuff in https://github.com/w3c/dxwg/issues/791 I think we can do it. And we could continue using this issue for its original purpose.

[kcoyle]

Sure, if it's been moved elsewhere. Maybe replace the comments with a simple link to the new issue?

[nicholascar]

Issue for Andrea's mapping role: https://github.com/w3c/dxwg/issues/847

[nicholascar]

Original issue listed here, about Figure 3, long since dealt with. Other points raised have been hived off into other Issues so due for closing.

[kcoyle]

@nicholascar There is no longer a "figure 3" in the profiles document - just 2 and 4. If figure 3 has been removed, please let us know. If the figures are mis-numbered and one of them is the "figure 3" spoken of here, then it can be fixed and we can look at that and determine if the issue should be closed. As it is, there's no there there. ;-) Note, I pointed this out above. Thanks.

[nicholascar]

In https://raw.githack.com/w3c/dxwg/prof-3PWD-candidate/prof/ I see Figures:

Figure 1 OWL [OWL2-OVERVIEW] overview diagram of this vocabulary

Figure 2 A full example profile described using common metadata and the Profiles Vocabulary

Figure 3 Inferring a transitive hierarchy from asserted skos:broader statements. Dotted arrows represent statements inferred from the SKOS data model. Solid arrows represent asserted statements. Reproduction of Figure 4.5.2 in [SKOS-PRIMER] - inside the NOTE Explanation of profiling transitivity

Figure 4 Property isTransitiveProfileOf in use. See the full explanation in the example text below.

... and Figures 5 - 16.

The figures are auto-numbered by ReSpec so there's always been a Figure 3, whatever edits we've made. Perhaps you missed Fig 3 in the large transitivity Note?

If so, then that's not the figure yo mentioned anyway - it's taken directly from SKOS - so the fix comments - changes to all PROF figures - still apply.

As mentioned in previous comments, all the figures have been redrafted and are all similarly styled now with changes based on other feedback (e.g. @aisaac's above).

[kcoyle]

OK, now I see it! But that Figure 3 is very different from the other figures, and I wonder, given that it is a note, if it really belongs here. Even the 'figure' caption looks very different (respec DOES create difficulties!). Do you intend to keep the green note area in the spec?

[nicholascar]

Removing "due-for-closing" since there is work to be done and labelling as "editorial" since we are now discussing styling of content.

[nicholascar]

On reflection, yes I think we will keep the Note box. SKOS has done a good job for us and we are just re-using that explanation here, so best to just note to it. It shouldn't be in the main text since we aren't offering this up in this doc for the first time.