prof:inheritedFrom needs more convincing case and/or example

[aisaac]

Examples are now provided for this, however this concept still appears to be unclear to some. This issue remains open pending a round of feedback based on improvements to examples and definition.

Original post here (edited above as its what appears in the doc)

As in the title...
This came to mind while writing the ESWC paper.
The property is not super-clear in https://w3c.github.io/dxwg/profilesont/ and there's no example for it.

Actually one could question whether it is needed, or whether it is just a "utility properties" to be derived from other statements, the same way that skos:broaderTransitive is in SKOS. That is to say, that they could be kept for amateurs only ;-) and put in an "advanced" section.

[andrea-perego]

+1 to @aisaac . I have the same concern.

[kcoyle]

I also have the concern that the concept of "inheritance" here isn't clear. What is inherited, and what are the implications of that inheritance? Does inheritance mean that the constraints are not also included in the profile being defined but must be included from the "inheritedFrom" resource? This is made more difficult by the fact that the definition of "resource descriptor" is not very clear so it's hard to imagine what kind of thing/resource one would inherit from.

[rob-metalinkage]

constraints from a profiled specification must be implemented by the profile. This is a transitive inheritance - so please come up with a new word and evidence of its use in the wild, or propose some better wording.

from wiki.. "In most class-based object-oriented languages, an object created through inheritance (a "child object") acquires all the properties and behaviors of the parent object (except: constructors, destructor, overloaded operators and friend functions of the base class). Inheritance allows programmers to create classes that are built upon existing classes,[1] to specify a new implementation while maintaining the same behaviors (realizing an interface), to reuse code and to independently extend original software via public classes and interfaces. The relationships of objects or classes through inheritance give rise to a directed graph. "

what is not clear about this?

[aisaac]

Note that the original issue is for an example and motivation, not questioning the notion of inheritance. In fact there's hope that such elements would help discussing the notion of inheritance, if need be. For the moment I feel we'd better wait until then.

[kcoyle]

@rob-metalinkage The issue that I raised is that it isn't clear what happens when:

ontologyA has properties A, B, C, D and class X
profileB includes properties A, D
profileB "prof:inherits" ontologyA (not clear what this would mean)

Does profile B also inherit ontologyA B, C?

Because classes in RDF do not define properties or constraints, there is no inheritance of properties through the re-use of a class. The answer above is No.

The definition you give says "object created through inheritance (a "child object") acquires all the properties and behaviors of the parent object" but that would mean that the profile would have to be created within an object-oriented programming language and the contents of the profile would have to be created through inheritance in a formal way using subclassing. Re-using properties and classes in RDF does not entail inheritance - they simply are what they are, as defined in the base vocabulary. Thus the only possible inheritance is with sub-(class/property), not re-use. While one can inherit class or property constraints through sub- it is not at all clear how a profile can be sub- another profile, in a formal sense. And that is why the use of the term "inheritance" in the case of re-use is confusing.

[aisaac]

@kcoyle @rob-metalinkage can this discussion go elsewhere? My issue was a simple editorial one, chances are that when it's resolved by merely added some text, we would forget about the discussion...

[kcoyle]

@aisaac We can move this, but depending on our conclusion we may not even need prof:inheritedFrom.

No, scratch the above, sorry. I think this gets to the meaning of inheritance, which is necessary for a convincing case or example. Without a clear definition we can't have a convincing case. So I think we need to go into some detail about what is a convincing case beyond "A inherits B" - what does that mean, what are the conditions that make that true?

[aisaac]

@kcoyle it's just that I feel we need the example to better understand and decide - at least I need the example to make my own mind. Which means that the issue can be closed before we make a decision (as the issue is only about requesting some text including examples).

[kcoyle]

Yes, we do need an example. And the example needs to be clear enough that we know what is meant by inheritance. That's what I'm asking for - one that clarifies the use case and meaning.

[nicholascar]

I've created a PR to merge in the link to this Issue and also an example highlighting use, see the branch rendered: https://raw.githack.com/w3c/dxwg/Issue-642/profilesont/index.html#Property:isInheritedFrom (may be deleted soon if merged into gh-pages).

[rob-metalinkage]

I'm not seeing anything here other than getting tangled up in understanding the nature of classes and sets - so you could think of profiles define sets of conforming objects - they are RDFS classes in that sense - but not declared as such (see OWL punning). Our concern is more the non RDFS/OWL matters of refererencing rules in other languages and "frames" - profiles are not "open" - they have a defined set of properties - closer to shapes than classes.

[kcoyle]

I see that this has resulted in a commit and merge without getting further discussion from this group. Please, for topics that have been discussed make sure we arrive at a solution in the issues area before it is added to the document.

In fact, I am wondering if we shouldn't back out that merge while we continue to discuss.

Here is the example that has been given:

Example 1: Property isInheritedFrom in use

# If Standard X, described using PROF, is given as having a Resource
# Descriptor, RS_1, with role "Full Constraints" as follows:

<@prefix ex1: <http://example.org/profile1/> .
@prefix ex2: <http://example.org/profile2/> .
@prefix dct: <http://purl.org/dc/terms/> .
@prefix prof: <http://www.w3.org/ns/dx/prof/> .
@prefix role: <http://www.w3.org/ns/dx/prof/role/> .


ex1:Standard_X
    a dct:Standard , prof:Profile ;  # this may be a 'null' profile,
                                     # i.e. a profile of nothing, a regular Standard
    dct:title "Standard X" ;
    prof:hasResource ex1:RS_1 .

ex1:RS_1
    a prof:ResourceDescriptor ;
    dct:conformsTo <http://www.w3.org/ns/shacl#> ;  # the SHACL standard
    dct:format <https://w3id.org/mediatype/text/turtle> ;  # the RDF Turtle format
    prof:hasRole role:fullConstraints ;      # this ResourceDescriptor is the total set of
                                             # constraints needed for validating data
                                             # against Standard X for conformance
    prof:hasArtifact ex1:constraints.ttl .

# then, a profile of Standard X, perhaps Profile Y, may use
# prof:isInheritedFrom to re-use that Resource Descriptor RS_1

ex2:Profile_Y
    a prof:Profile ;
    dct:title "Profile Y" ;
    prof:isProfileOf ex1:Standard_X ;  # this is a profile of Standard X
    prof:hasResource [
        a prof:ResourceDescriptor ;  # RS 2 in diagram
        prof:isInheritedFrom ex1:Standard_X ;  # this Resource Descriptor is inherited from
                                               # Standard X
        dct:conformsTo <http://www.w3.org/ns/shacl#> ;  # as above
        dct:format <https://w3id.org/mediatype/text/turtle> ;  # as above
        prof:hasRole role:partConstraints ;  # this ResourceDescriptor is now only Part Constraints
                                             # for Profile Y as it's implementing some of its own,
                                             # additional constraints (see next Resource Descriptor)
        prof:hasArtifact ex1:constraints.ttl  # direct URI reference to ex1:RS_1's artifact
    ] ,
    [
        a prof:ResourceDescriptor ;  # RS 3 in diagram. This is not inherited from anywhere
        dct:conformsTo <http://www.w3.org/ns/shacl#> ;
        dct:format <https://w3id.org/mediatype/text/turtle> ;
        # these constraints are Profile Y's on top of Standard X's
        prof:hasRole role:extensionConstraints ;  # Extension Constraints are those on top of
                                                  # another base specification's
        prof:hasArtifact ex2:extension_constraints.ttl  # a file within this Profile
    ] .

I'll comment lower down, but want to hear from @aisaac and @andrea-perego if they agree to backing this out while we discuss.

(Note: had to edit this to retain the left brackets, so if that confused you it has been fixed.)

[kcoyle]

Because this is long, I'm going to try to break it up into small bits:

ex1:Standard_X
    a dct:Standard , prof:Profile ;  # this may be a 'null' profile,
                                     # i.e. a profile of nothing, a regular Standard
    dct:title "Standard X" ;
    prof:hasResource ex1:RS_1 .

What this says is the ex1:Standard_X is a member of two classes: dct:Standard and prof:Profile. I don't understand what is meant by "a profile of nothing". Regardless of what follows (e.g. whether this is declared to be or not to be a profileOf something), that class membership remains. What is intended by using both class declarations?

[kcoyle]

I'm finally figuring out something that has been very confusing to me in the diagrams, so this example has helped in that way, thanks. In the diagram in "Figure 3" here it shows a box for ProfileY that has 2 resources, RS2 & RS3. Those link to a single Resource Descriptor "box" representing the class. I think this mixes instance data and the data model rather oddly. For diagrams representing instance data either one could

1. not include the type declaration "boxes", since they make kind of a mess of the diagram
2. use a different kind of diagram that combines the type and the "thing" in a single box

Having the classes represented separately from the members of the classes when illustrating instance data is what I find confusing - it mixes "things" and "the classes those things are classes of" as if they exist separately, and they do not.

[kcoyle]

"ex2:" doesn't clarify the meaning or functionality of this property for me. I'll name a few things, just to get a discussion started:

In this example, there are multiple profiles that each have only a single resource type: a SHACL file. Nothing is said about the case where:

profileX has the following resources:

• a PDF document
• a SHACL document in JSON-LD

profileY has the following resources:

• a Word document
• A ShEx document in ttl

And there is a triple that states:

     profileY prof:inheritedFrom profileX

What is an application supposed to do with these?

profileX has this resource:

• a SHACL document

profileY has this resource:

• another SHACL document

  profileY prof:inheritedFrom profileX

There are now 2 SHACL files.

• One may be entirely different from the other (AAA);
• one may contain SHACL statements that are also in the other, but are the same;
• one may contain SHACL statements that are also in the other but that give conflicting (or at least different) rules.

What is the required action on the application processing these for each of these cases?

ProfileX has properties A, B, C, G (let's say in a SHACL document)
ProfileY has properties A, B, C, D (ditto)

What are the outcomes from these two statements:
ProfileX prof:inheritedFrom ProfileY .
ProfileY prof:inheritedFrom ProfileX .

If the answers to any of these are: You shouldn't do that! then there needs to be a description in the ontology that explains what is and is not "valid" when using prof:inheritedFrom.

[rob-metalinkage]

The answer is not "you shouldn't do that" but rather "we expect people to do any of these things"

noting that prof:inheritedFrom applies to the qualified associations of type "ResourceDescriptor" - not on the profile...

if Profile "X" has a resource RX declaring a set of constraints on properties A, B,C,G and Profile "Y" is a profile of X and has a resource RY declaring a set of constraints on properties A,B,C,D

then...

a) the constraints in profile Y on A,B,C must be compatible with the constraints in profile X
b) the declared role of resource RY has to be some form of "partial" because is does not include constraints on property G

so - we must use declared roles to allow clients to know if they need to look at inherited constraints to validate - or if a full set of constraints have been conveniently packaged.

it is up to implementations to worry about checking constraints are satisfiable (non-contradictory) - all we can do is allow these to be found and classified in the chosen flattening/packaging strategy.

In guidance - we could suggest that profiles are available in the flattened view with resources defining the full constraints - we could declare a canonical name for this profile of the Profile ontology if you think it would help.

to a certain degree, the constrain language will need to define its own syntax and semantics for inheritance - the profiles ontology only allows declaration of intent.

[kcoyle]

@rob-metalinkage said: "noting that prof:inheritedFrom applies to the qualified associations of type "ResourceDescriptor" - not on the profile..."

This may be the source of my confusion because all of the requirements related to inheritance all speak of profile inheritance. From the draft profiles guidance document:

"2..4 Profile inheritance [RPFINHER]
Profiles may add to or specialise clauses from one or more base specifications. Such profiles inherit all the constraints from base specifications."

In addition we have this, which I think may also refer to resources rather than profiles:

"2.3 Profile of profiles [RPFPP]
One can create a profile of profiles, with elements potentially inherited on several levels."

In 2.3 it is unclear whether this speaks of a prof:Profile with resources, or a single document (e.g. a SHACL document) whose rules are referred to here as "elements".

Unfortunately I have no idea what is meant by:
"In guidance - we could suggest that profiles are available in the flattened view with resources defining the full constraints - we could declare a canonical name for this profile of the Profile ontology if you think it would help."

What is a "flattened view" of a profile? Then, it seems clear that the resources define the profile, although only some of them define constraints.

I do not support the idea of stating that there is inheritance and then "up to implementations to worry about checking constraints are satisfiable". I don't see utility in stating something that is so ill-defined in its practice.

Personally, I would not want to include this definition of inheritance of resources in the guidance document because it appears to be very implementation-specific and the guidance document will be more general. (Also, it seems to contradict the requirements we have.) I see a difficulty in indicating specific relationships between profile documents (profont resources) without making the guidance document solely about the profont ontology model. In our profiles requirements we are not specifying roles, resources, etc. but the "best practices" for profiles, regardless of how they are modeled. This "inheritance of resources" issue doesn't fit there, IMO.

Also, I would like to see responses to my other two comments. Thanks.

[aisaac]

Thanks for the example. I believe that it helps the discussion... But first some friendly editorial advice. It would be good if profiles ids had numbers or letters that can be reused by the resource descriptors id, making sure it's easy for the reader to connect profiles with descriptors, just from reading the ids. X,Y,1,2,3 could be P1, P2, P1RS1, P2RS1, P2RS2. It's not beautiful but will make our discussion/understanding a tad easier.
And echoing a comment from @kcoyle, in such an example there's no need for representing class instantiation in the diagram. It's already visually quite complex, cf the arrow between RS1 and ResourceDescriptor. Instead, pick ids for the instances, which will reflect the main class they belong to. Like resourceDescriptor1ForProfile2. Not beautiful, but clearer.
Further, the distinction between "OWL Class" and "PROF class" is not really useful. I mean, it could be useful for a general overview of PROF, but for this example I think it brings complexity that can be easily left out.

Finally, don't include materialized trivial rdf:type statements unless they mean something. If ex1:Standard_X shall be defined as instance of prof:Profile then it's enough, in an example that is not about the relation between dct:Standard and prof:Profile.

On the content itself, like @kcoyle I sense that we've talked a lot about 'profile inheritance' and that prof:isInheritedFrom is about something slightly different (maybe a consequence of profile inheritance, but for the resources that embody these profiles).

But I would prefer that the example is editorially a bit simpler before discussing this really complex matter.

[rob-metalinkage]

+1

[smrgeoinfo]

Is the inheritedFrom property really necessary? What if the encoding worked like the example below.
What is actually modeled is a specification (the intention of dct:Standard, even if the actual defintion isn't clear). It's still represented by the prof:Profile class in the example. The distinction of 'standard' and 'profile' is apparently pretty fuzzy given all the discussion about defining profile.
By treating resourceDescriptor as a qualified association from a specification to some related resource that has one or more distributions, various problems can be solved or avoided. To address @kcoyle question 1 and 3, use hasRole property could specify the 'inheritance' relationship type (override, replace, restrict, supplement), and add a property to link the ResourceDescriptor back to what it describes/constrains. Making the range of hasArtifact a dcat:distribution, multiple representations for the resourceDescriptor target could be addressed (@kcoyle question 2 above).

# Standard X, has validation resource SX-RS_1, 
# described using PROF, has SHEX and SHACL representations
# of validation rules.
# Profile_Y uses the constraints resource SX-RS_1  from Standard_X
#,  add validation rules as another 'hasResource' blank node,
# 	and has guidance document available as MSWord doc or pdf:

<@prefix ex1: <http://example.org/profile1/> .
@prefix ex2: <http://example.org/profile2/> .
@prefix dct: <http://purl.org/dc/terms/> .
@prefix prof: <http://www.w3.org/ns/dx/prof/> .
@prefix role: <http://www.w3.org/ns/dx/prof/role/> .


ex1:Standard_X
    a prof:Profile ;  # use this type to get binding to prof properties,
			     # it is a subtype of dct:Standard, brings in dct properties 
    dct:title "Standard X" ;
    prof:hasResource ex1:SX-RS_1 .  # use this because we want a qualified association			

ex1:SX-RS_1
    a prof:ResourceDescriptor ;		# use this type to assign role, and bind to distributions (via hasArtifact)
	dct:isRequiredBy ex1:Standard_X          # other relations to the described standard
						# need to be accounted for, e.g. guidance, example, visualization
						# could just use dct:subject for starters
         prof:hasRole role:fullConstraints ;      # this ResourceDescriptor is the total set of
                                             # constraints needed for validating data
                                             # against Standard X for conformance
    #there are two equivalent representations of the validation rules:
	prof:hasArtifact [
		a dcat:Distribution ;
		dct:conformsTo <http://www.w3.org/ns/shex#> ;  # the SHEX standard
		dct:format <https://w3id.org/mediatype/text/jsonld> ;  # the JSON-LD serialization
		dcat:accessURL <constraints.jsonld> 
		] ;
	
	prof:hasArtifact [
		a dcat:Distribution ;
		dct:conformsTo <http://www.w3.org/ns/shacl#> ;  # the SHACL standard
		dct:format <https://w3id.org/mediatype/text/turtle> ;  # the RDF Turtle format
		dcat:accessURL <constraints.ttl>	
	] .

# then, a profile of Standard X:  Profile Y

ex2:Profile_Y
    a prof:Profile ;
    dct:title "Profile Y" ;
    prof:isProfileOf ex1:Standard_X ;  # this is a profile of Standard X
    prof:hasResource ex1:SX-RS_1 ;
    prof:hasResource [
        a prof:ResourceDescriptor ;  # PY-RS_3 in diagram. This is not inherited from anywhere
		dct:isRequiredBy ex2:Profile_Y ;
        # these constraints are Profile Y's on top of Standard X's
        prof:hasRole role:extensionConstraints ;  # Extension Constraints are those on top of
                                                  # another base specification's
        prof:hasArtifact [
			a dcat:Distribution ;
			dct:conformsTo <http://www.w3.org/ns/shacl#> ;  # the SHACL standard
			dct:format <https://w3id.org/mediatype/text/turtle> ;  # the RDF Turtle format
			dcat:accessURL <extension_constraints.ttl>	
	] ;
    prof:hasResource [
        a prof:ResourceDescriptor ;  # PY-RS_3. This is not inherited from anywhere
        dct:subject ex2:Profile_Y ;
        prof:hasRole role:guidance ;
        prof:hasArtifact [
        	a dcat:Distribution ;
        	dct:format <ms-word> ;  # Microsoft word document
        	dcat:accessURL <profileguidance.doc>	
        	] ;
        prof:hasArtifact [
        	a dcat:Distribution ;
        	dct:format <adobe pdf> ;  # adobe acrobat document
        	dcat:accessURL <profileguidance.pdf>	
        	]
	].

[kcoyle]

@smrgeoinfo I like this way of expressing the relationship, although I suspect that conceptually "requires" might be considered too strong to some people. The definition of the dct term, though, includes support materials, and I believe this comes from the learning / teaching community and could include things like teachers' manuals.[1] Therefore, any kind of strong dependency would fit, and the mere fact of including files as resources of a profile should mean that they have implicit importance for the functioning of the profile. Given that "prof:inheritedFrom" has no axioms associated with it, but that is left to the implementation, it is no more precise than "dct:requires / dct:isRequiredBy". Having it be a role would avoid the implication that the "inheritance" is an O-O class relationship. Then if someone's application did require a specific type of requirement or dependency, that could be expressed with a role. IMO, having "prof:inheritedFrom" without any clear definition of what that means is just a likely source of confusion. At least with dct:isRequiredBy the definition [1] is pretty clear, while the definition of prof:inheritedFrom in circular and doesn't give a clue as to what inheritance means in the context because it doesn't define or given examples of inheritance (and it uses the word "inheritance" to define "inheritance").[2] Even worse, I don't think it accurately says what I think it means - because it can be inheritance from more than one base specification.

[1] "A related resource that is required by the described resource to support its function, delivery, or coherence."
[2] "A Profile's Resource Descriptor has been inherited from a base specification"

[VladimirAlexiev]

The last example above shows format and conformsTo being used on two different entities: the ResourceDescriptor (as per spec) and the artefact. I think only the latter makes sense: format and conformsTo are innate props of the artefact whereas ResourceDescriptor captures its relation to a profile.

Furthermore, I think a ResourceDescriptor may reasonably have several equivalent artefacts: eg the same Shacl served as turtle or rdf xml, for convenience.

Furthermore, the same artefact may list several formats, selectable through conneg.

So I think all these links and their cardinalities are not quite clear in the spec. As in another issue, the function of ResourceDescriptor should be crystal clear before we know where to put the links, and whether inheritedFrom is needed.

[kcoyle]

@VladimirAlexiev To me it isn't clear if there is only one artifact per ResourceDescriptor, or if it is as you say, that a ResourceDescriptor can have multiple artifacts in different formats. @smrgeoinfo 's example shows the latter:

 prof:hasRole role:guidance ;
		prof:hasArtifact [
			a dcat:Distribution ;
			dct:format <ms-word> ;  # Microsoft word document
			dcat:accessURL <profileguidance.doc>	
			] ;

I think this merits its own discussion so I will create an issue for that. (It also came up in a comment to the comments list.)

This just was commented on in #529 with this comment.

[agreiner]

@rob-metalinkage I don't quite understand your description of a "flat" version of a profile here. What I've been thinking of is one where the actual definitions of things appear in the profile itself rather than (or in addition to) references to other specs. So the flat version could be used on its own for guidance without the need for reference to all the parent specs. In that sense, the flat version is the more full. Is that what you are thinking?

[VladimirAlexiev]

@rob-metalinkage I didn't quite understand your comments about dcat:Distribution.

• what's the relation between dcat:Distribution and ResourceDescriptor and "artefact"?
• I think a Distribution has only one URL and may have several format (if that URL supports conneg)
• If the purpose of ResourceDescriptor is to describe the relation of the artefact to the profile, then it makes sense to allow several artefacts under one ResourceDescriptor, differing only by format.
• So maybe dcat:Distribution is equivalent to artefact?

[smrgeoinfo]

@VladimirAlexiev thanks for the correction to the example code, I made a fix in the comment above. Your interpretation of my example is consistent with what I was thinking.
Specification --> hasResource --> ResourceDescriptor(hasRole) --> hasArtefact --> Distribution

[rob-metalinkage]

@VladimirAlexiev

q: what's the relation between dcat:Distribution and ResourceDescriptor and "artefact"?
a: the relation between dcat:Distribution and prof:ResourceDescriptor is a "non-normative alignment" via subclass - i.e. an implementer can safely choose this if they wish but use of dcat is not imposed. The relationship between ResourceDescriptor and "artifact" is the same relationship as between Distribution and dcat:downloadURL

"I think a Distribution has only one URL and may have several format (if that URL supports conneg)"

• this cardinality is not defined in DCAT. A case to constrain it is not clear, so cardinality is left open. Profiles of Profile and DCAT would be the appropriate mechanism to make such a constraint in an operational context.

• "If the purpose of ResourceDescriptor is to describe the relation of the artefact to the profile, then it makes sense to allow several artefacts under one ResourceDescriptor, differing only by format."
  a: there is nothing to stop this approach. The semantics of the use of dct:format on the resource descriptor (or DCAT distribution) probably requires an entailment rule to be axiomitised - at this stage we do not have sufficient evidence or experience to enforce a particular pattern, but we do explicitly wish it to be easy to use DCAT to catalogue profiles

• "So maybe dcat:Distribution is equivalent to artefact?"
  a: no more so than dcat:Distribution is equivalent to the range of a dcat:accessURL - in simple cases they may be the same, but the option to provide additional metadata about the relation of the artefact to the profile is important. in general, having a descriptor for an object allows a cataloguing context to make statements about that object independent of any intrinsic properties - which will generally help in Linked Data environments to retrieve the metadata about the object indpendently of getting its entire contents. It is not impossible, but a much higher barrier, to demand , for example, that every PDF document supports canonical metadata form accessible via conneg from the same downloadURL.

This does get deep into the whole design of DCAT and the relationships between descriptors and content, and broader issues of lack of a canonical way to resolve a single URI to get metadata about an object from a particular viewpoint (different people may need to see different levels of detail). Cataloguing is the default way to handle this problem, and we provide a minimal level of support for that architecture. (note this is all rather peripheral - as its description conformance hierarchies and roles that are the functional goals here)

[rob-metalinkage]

note that this thread has diverged quite a lot from the original topic and is now essentially a duplicate of #769

[rob-metalinkage]

Propose to close this issue as it is no longer resolvable against the original topic, it should be replaced by a clean issue to discuss the relevant point (is the predicate well enough explained - or can an improvement be suggested)

General issues of DCAT alignment and the nature of inheritance are handled in #769 and #808 and #795

[kcoyle]

@VladimirAlexiev Could you give us an example of your thinking in code? You might look at some of the code examples in #769, including the diagram showing the placement of the artifact and dct:format, and examples here. If those comments are related to your own, you might respond there, and we can possibly resolve that part of that issue.

Thanks.

[kcoyle]

I removed the 'due for closing' because we still don't have a resolution for the main issue. We can try to move the question about artifacts and multiple artifacts to #769 but we still need a resolution here regarding prof:inheritedFrom. We have an example that was provided by Nick (I think). Antoine asked for some changes to the example, which I don't believe were done. Richard questioned the need for inheritance, which is very much related to the question here, and gave a detailed example. Vladimir replied that "So I think all these links and their cardinalities are not quite clear in the spec. As in another issue, the function of ResourceDescriptor should be crystal clear before we know where to put the links, and whether inheritedFrom is needed." This connects the ResourceDescriptor and cardinality issues with the main question on inheritance. They are linked and probably need to be resolved in concert with each other.

@smrgeoinfo @VladimirAlexiev @aisaac @rob-metalinkage @nicholascar

What we need here is a conclusion, which would probably be a revised example (both in code and as a one or more use cases), and a clear definition of "inheritedFrom".

[smrgeoinfo]

I haven't seen anything in the discussions here to make me think that the solution proposed earlier, revised based on suggestions by @VladimirAlexiev , and sketched (roughly) in this diagram can't be the basis for a solution.

[rob-metalinkage]

"What we need here is a conclusion, which would probably be a revised example (both in code and as a one or more use cases), and a clear definition of "inheritedFrom"." - an example has been provided and an update of the definition made. the only way to progress this is to get it out for further review.

@smrgeoinfo - it is unnecessary to make the range of artefact a dcat:Distribution - as a ResourceDescription already plays that role as a metadata carrier - recognising that this provides the advantage that such metadata is specific to the set of roles defined. As in dcat it doesnt stop you making any assertions about the target of the hasArtifact (or accessURL).

And note that @smrgeoinfo (Stpehen , not Richard?) did not at all "question the need for inheritance" in any way - this property does not define inheritance. We have use cases which explicitly define the requirements for inheritance, What this property does is allow you to find which specification in an inheritance hierarchy (defined by isProfileOf property chains) defines the role of a resource. Its a convenience to support @agreiner requirement that there is a "flat" view of profile descriptions available.

as such, it is not the "qualified association between specifications" - we already have that in the main part of the model - this property exists solely to allow us to flatten inheritance hierarchies into a simplified graph without losing information about which part of the inheritance graph originally referenced the resource.

(I'd be quite happy to remove this and say that the flattened profile view is an implementation choice - and people could define their own idiosyncratic metadata for this information.)

Either way - at some point reviewers need to go back and examine the competency questions and the model and decide if there is better way to meet the requirements, rather than making assumptions about the meaning based on "trigger" words in names and definitions.

The model demonstrably meets identified requirements and no concrete proposal for a simpler but equally effective solution exists - so we need to iterate on the examples and explanations and at some point just accept the best we have collectively been able to devise.

[rob-metalinkage]

we can also iterate on the predicate name of course: it is similar to rdfs:isDefinedBy without the sense of "defined" - maybe isSpecifiedBy make it clearer that inheritedFrom (although it loses the reinforcement of the concept that profiles express a requirement to conform to constraints that are inherited via isProfileOf)

[kcoyle]

@rob-metalinkage "an example has been provided and an update of the definition made. " There were questions about the example that were not answered here. Just providing an example is not enough, there has to be discussion and response, possibly leading to changes. To point of providing an example is that it facilitates discussion. In addition, Richard provided a counter example. How do you want to handle that? Also, @VladimirAlexiev had comments that may need responses. All of these need to be considered.

I also don't know that an update of the definition has been presented to, nor accepted by, the group. That would be a first step in a resolution. This could be done as an email to the public list or, if needed, a new github issue. Then we could ask for a straw poll vote on it, after suitable discussion.

[rob-metalinkage]

reread the thread - response has been provided to the points @VladimirAlexiev inline (and a formal response can be made after 2PWD is released to request review). Stephen's counter example has been considered and discussed. Definitions have been discussed and we have the best we can achieve in this round via three weeks of collaborative editing via the google doc. You simply need to accept that there is a point at which "the group" has had input via all the formal mechanisms, the impact has been assessed, and in this case improved definitions in a new draft is proposed. This new draft can then be exposed to wider review, which is the only way to resolve things.

There is an outstanding suggestion re renaming some entities within the example - happy to take this on board as a new issue, as it technically is a different subject to this issue and applies to all examples.

[kcoyle]

@rob-metalinkage one word: consensus

Do a vote or a poll to confirm consensus

[rob-metalinkage]

Give the original issue has been addressed with an example, but there is obviously active discussion around the underlying concepts I have created a new issue #842 to address the substantive question - is this property optimally designed, named and described? I have put forward a concrete proposal to allow us to move forward.

General issues of DCAT alignment and the nature of inheritance are handled in #769 and #808 and #795

There is a new issue with the key outstanding matter directly arising from this discussion, relating to example naming: #840

#841 is s trivial PR to pull this issue in, and replace this issue now that an example is in .

consensus needs to be managed with good procedures that keep matters separated, otherwise no one knows what they are agreeing to - so this issue needs to be closed and discussions directed to single-thread replacements. The above outlines where all the discussions should be taking place from now/

So, lets put this forward to a consent process - are there any objections to:

1. Accept PR-841 at the next plenary to get the updated issues into the public arena
2. respondents to check and update the relevant (!) open issues with any outstanding concerns (or open new issues if you believe the concern is not the focus of an existing issue, bearing in mind issues need to focussed on a matter that can actually be resolved.
3. editors make sure that external comments are captured and replied to in the disposition of comments documents maintained by the chairs.

NB A vote at the plenary to accept the PR marks a consensus to move forward - and of course the issue persists even after closing so discussion is not lost.

[aisaac]

I have added back the 'due for closing'
A lot of comments and suggestion do indeed seem to cover the relationship with DCAT or even more generally the pattern for resource descriptors, artefacts, i.e. something much broader than inheritance. And/or they are based on a misunderstanding of a version of the example that was easier to misunderstand then.

I have created two new issues which I think are not covered in the other issues mentioned above:

• one of the level at which the inheritance statement should be represented: What is the level of the inheritance link? #857
• one for editorial fixes Editorial issues in prof:inheritedFrom example #858 (minor problems that I have spotted while re-reading everything in this issue and the spec)

Based on my comment at https://lists.w3.org/Archives/Public/public-dxwg-wg/2019Mar/0676.html I now believe that with PR #841 can be merged and this issue can be closed.