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

Profiles Ontology Figure 3 #731

Open
kcoyle opened this Issue Feb 5, 2019 · 26 comments

Comments

7 participants
@kcoyle
Copy link
Contributor

kcoyle commented Feb 5, 2019

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

title

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

This comment has been minimized.

Copy link
Contributor

rob-metalinkage commented Feb 5, 2019

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

This comment has been minimized.

Copy link
Contributor

aisaac commented Feb 5, 2019

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?

@kcoyle

This comment has been minimized.

Copy link
Contributor Author

kcoyle commented Feb 5, 2019

@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

This comment has been minimized.

Copy link
Contributor Author

kcoyle commented Feb 5, 2019

@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

This comment has been minimized.

Copy link
Contributor

aisaac commented Feb 5, 2019

@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).

@nicholascar nicholascar added this to To do in Profiles Ontology via automation Feb 14, 2019

@nicholascar nicholascar added this to the PROF 3PWD milestone Feb 14, 2019

@fellahst

This comment has been minimized.

Copy link

fellahst commented Feb 21, 2019

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

This comment has been minimized.

Copy link
Contributor

rob-metalinkage commented Feb 21, 2019

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

This comment has been minimized.

Copy link
Contributor

andrea-perego commented Mar 4, 2019

@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

This comment has been minimized.

Copy link
Contributor Author

kcoyle commented Mar 5, 2019

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

This comment has been minimized.

Copy link
Contributor

andrea-perego commented Mar 5, 2019

@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 nicholascar referenced this issue Mar 5, 2019

Merged

Issue 731 #790

@nicholascar

This comment has been minimized.

Copy link
Contributor

nicholascar commented Mar 5, 2019

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.

isinheritedfrom

This diagram is now in PR #790

@nicholascar

This comment has been minimized.

Copy link
Contributor

nicholascar commented Mar 5, 2019

OGC discussion quoted from here and taken up in Issue #791

@kcoyle kcoyle removed the due for closing label Mar 6, 2019

@kcoyle

This comment has been minimized.

Copy link
Contributor Author

kcoyle commented Mar 6, 2019

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

This comment has been minimized.

Copy link
Contributor Author

kcoyle commented Mar 6, 2019

@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

This comment has been minimized.

Copy link
Contributor

rob-metalinkage commented Mar 6, 2019

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

This comment has been minimized.

Copy link
Contributor

andrea-perego commented Mar 11, 2019

@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

This comment has been minimized.

Copy link
Contributor

andrea-perego commented Mar 11, 2019

@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

This comment has been minimized.

Copy link
Contributor

rob-metalinkage commented Mar 13, 2019

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

@kcoyle

This comment has been minimized.

Copy link
Contributor Author

kcoyle commented Mar 13, 2019

@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

This comment has been minimized.

Copy link
Contributor

makxdekkers commented Mar 13, 2019

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 comment has been minimized.

Copy link
Contributor

rob-metalinkage commented Mar 26, 2019

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

This comment has been minimized.

Copy link
Contributor Author

kcoyle commented Mar 26, 2019

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

@kcoyle

This comment has been minimized.

Copy link
Contributor Author

kcoyle commented Mar 26, 2019

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

@aisaac

This comment has been minimized.

Copy link
Contributor

aisaac commented Mar 26, 2019

Could we delete the comments about the OGC testbed? Now that @nicholascar has copied the stuff in #791 I think we can do it. And we could continue using this issue for its original purpose.

@kcoyle

This comment has been minimized.

Copy link
Contributor Author

kcoyle commented Mar 26, 2019

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

@nicholascar

This comment has been minimized.

Copy link
Contributor

nicholascar commented Mar 26, 2019

Issue for Andrea's mapping role: #847

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.