-
Notifications
You must be signed in to change notification settings - Fork 47
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
prof:profileOf sub-property of prov:wasDerivedFrom (!?) #485
Comments
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. |
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 Should we use a straightforward To be continued... |
+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. |
So I guess a resolution on this issue depends on how we close #507. |
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. |
As I commented in #216 (comment) , |
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? |
I think @andrea-perego is saying that, since 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. |
@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). |
@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? |
@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. |
@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. |
@kcoyle said:
+1 from me. I totally agree. |
+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 |
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" |
@smrgeoinfo Do you mean "if A is dependent on B, A will not work without B"? |
yup, fixed. Thanks! |
@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. |
@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? |
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" Right? |
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. |
@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:
Thanks. |
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. |
@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 #828 but I've left off the PROF -> PROV alignment due to the issues I've noted in the wiki table. |
Is there any specific reason why the property prof:profileOf is not defined as a sub-property of prov:wasDerivedFrom?
The text was updated successfully, but these errors were encountered: