prof:profileOf sub-property of prov:wasDerivedFrom (!?)

[riccardoAlbertoni]

Is there any specific reason why the property prof:profileOf is not defined as a sub-property of prov:wasDerivedFrom?

[nicholascar]

The relationship has occurred to us but we are not sure it’s Really a derivative relationship. It may be a subPropertyOf prov:wasInfluencedBy instead.

Happy to bash this one out here.

[nicholascar]

From PROV-O' explanation of wasDerivedFrom:

"A derivation is a transformation of an entity into another, an update of an entity resulting in a new one, or the construction of a new entity based on a pre-existing entity."

It is appropriate to say directly that :DCAT-AP prov:wasDerivedFrom :DCAT when taking about the provenance of DCAT-AP as a thing. Of course this dosent convey the special sense of what it is to be a profile of something else.

Should we use a straightforward prof:profileOf rdfs:subPropertyOf prov:wasDerivedFrom to tie profileOf into PROV?

To be continued...

[riccardoAlbertoni]

+1 to @nicholascar that was my implicit suggestion ;)

I think prov:wasInfluencedBy leaves prof:profileOf too underspecified. It actually subsumes generation and other relations that do not properly characterize prof:profileOf. Anyway, I am open to change my mind if anyone has an answer to my original question.

[aisaac]

So I guess a resolution on this issue depends on how we close #507. But I have to say that my experience with PROV is that it's likely that any property will include some domain or range declaration that will be quite strong. And that is going to bring us to endless and unnecessary discussions about whether the inherited domains and range make sense :-/

[kcoyle]

Where does this leave the assumption that "profileOf" implies formal inheritance? See #642 for such a statement in comment. There is no implication of formal inhertance in prov:wasDerivedFrom - especially since it includes that statement that the result can be a "new entity", which could include a stand-alone entity.

[andrea-perego]

As I commented in https://github.com/w3c/dxwg/issues/216#issuecomment-390023563 , prov:wasDerivedFrom does not imply any notion of dependency (I'm not talking about inheritance here), which is what prof:profileOf is also meant to model. So, I'm still unsure whether we need to make prof:profileOf a subproperty of prov:wasDerivedFrom.

[kcoyle]

Sorry, @andrea-perego - need to clarify what you meant. What is it that prof:profileOf "is also meant to model"? Dependency, or no dependency; inheritance or not?

[nicholascar]

I think @andrea-perego is saying that, since prov:wasDerivedFrom doesn’t say anything about dependency but that prof:isProfileOf does, it would be of no value to make this rdfs:subPropertyOf.

I’ll add another objection of my own: PROV is all about past tense whereas PROF is all about present tense vis ‘was’ v. ‘is’ at the start of property names respectively. This makes direct sub property relations tricky and makes me want to avoid relationships like the one asked for here.

[andrea-perego]

@kcoyle , as @nicholascar says, it's the notion of dependency I was referring to (i.e., the fact that a "profile" depends on one - or more - specifications).

[kcoyle]

@andrea-perego @nicholascar The profiles that I know (including the DCAT ones) are based on existing ontologies or profiles but have no formal dependency. (Re-use is not dependency in RDDF.) Also, I just looked at the definition of isProfileOf and have no idea what it means due to unclear wording:

"The subject of 'is profile of' defines constraints on the object which playes the role of a base specification"

So maybe a first step is to understand the meaning of isProfileOf? What constraints are defined?

[andrea-perego]

@kcoyle , I tend to agree that the notion of "dependency" may not always apply, and depends on the characteristics of the under-lying formal (or natural?) language used, but also on how the profile definition is implemented. But still "re-use" of existing terms from other specification can be seen as a dependency in the broader sense. E.g., if the new DCAT version will be not backward compatible, this will affect DCAT-AP, as, formally, it may be no longer considered a profile of DCAT.

[kcoyle]

@andrea-perego I'm fine with general dependency as long as not too much is assumed by it, and prefer profileOf not translate to specific constraints. But in other discussions there has been talk of understanding profileOf to include an inheritance of constraints (what is meant by this is unclear to me). If profileOf has a strict axiomatic role then it can only be used in circumstances that meet that strict definition. I would prefer a broad definition, like yours, so that it can be a way to simply say that one has made use of constructs from another metadata schema, and there is a kind of "generational" relationship. One library philosopher referred to this as a "family of works" that includes works derived from other works. We could think of creating a "family of profiles" which fits well with the DCAT profiles that already exist, IMO.

The other aspect of this is that a profile can make use of terms and definitions from more than one piece of prior "art", and it may not use all of the schemas/profiles it borrows from. This also argues for making profileOf conceptual rather than axiomatic because it would be difficult to define an axiom that could be true in such a wide variety of cases.

[andrea-perego]

@kcoyle said:

[...] This also argues for making profileOf conceptual rather than axiomatic because it would be difficult to define an axiom that could be true in such a wide variety of cases.

+1 from me. I totally agree.

[nicholascar]

+1 to the above.

I'm sort-of interested in some relations of PROF to PROV so some notion of PROV-like process flow modelling might be understood by isProfileOf but I think it wise to avoid strong axiomes in PROF too.

[smrgeoinfo]

Just to anchor the conversation back to the draft spec , currently : "The subject of 'is profile of' defines constraints on the object which playes(sic) the role of a base specification" Adopting the conceptual rather than axiomatic approach, precisely what this means will have to be defined in profiles of the profile spec. As worded I don't think it is consistent with 'prof:isDerivedFrom', or with the concept of dependency (taken to mean if A is dependent on B, A will not work without B).

[agreiner]

@smrgeoinfo Do you mean "if A is dependent on B, A will not work without B"?

[smrgeoinfo]

yup, fixed. Thanks!

[nicholascar]

@riccardoAlbertoni: there's general consensus here that there won't be a sub-property declaration made. Are you happy with this outcome? If so, I will close.

[kcoyle]

Nick, what about the comments at: here and here. These are the opposite of what is said elsewhere. Perhaps this needs to be a new issue, but I would hate to lose this discussion.

[nicholascar]

@kcyole I don’t understand. All the links you’ve provided agree that no strong semantics are wanted thus subPropertyOf declaration should be made.

None of us think wasDerivedFrom-style strong linkages are a good idea except perhaps Riccardo who we’ve not heard from on this point recently, hence my email, so can you please restate your concern here?

[kcoyle]

Maybe I am mis-interpreting @rob-metalinkage 's statements, so let's remember this when we discuss the definition of profileOf. And I believe above you don't mean:

"thus subPropertyOf should be made"
but "thus subPropertyOf should not be made"

Right?

[rob-metalinkage]

I think we have found no compelling case to include strong axiomitisation tying the specific isProfileOf semantics to the more general defintions in PROV. We can publish this as a recommended "alignment" following DCAT practice. Maybe add into the usage note that it is a stronger bit compatible semantics that the prov:wasDerivedFrom which may be asserted using the relevant alignment vocab.

proposal: update usage note, leave issue in new PWD to elicit any further insights.

[kcoyle]

@rob-metalinkage I think I like the solution but I'm unclear on some things you said but that we might want to add to the documentation:

1) in what way is this an alignment with DCAT? 2) I think there's a typo in the sentence about the usage note - "it is a stronger bit compatible..." Could you revise that?

Thanks.

[rob-metalinkage]

its not an alignment with DCAT. DCAT offers informative alignments with a range of other vocabs - thats the practice being referred to.

I'll update the usage note in the google doc with a firm proposal.

[nicholascar]

@kcoyle yes, a typo, should read "thus subPropertyOf should not be made".

Further to Rob's point about possible alignment with PROV: we have alignments in the wiki page https://github.com/w3c/dxwg/wiki/PROF-Alignments-and-crosswalks and I've brought most of that content into PR https://github.com/w3c/dxwg/pull/828 but I've left off the PROF -> PROV alignment due to the issues I've noted in the wiki table.