Profiles extend or refine (UC 5.37)

[kcoyle]

Profiles can extend other vocabularies or profiles, or can be refinements of other vocabularies or profiles (UC 5.37)

[dr-shorthair]

I suggest that the relationship between a 'Profile' and its underlying standards is dependsOn rather than profileOf. The latter kinda implies that a profile is of only one source.
'dependency' is a more general concept which I think does reflect the intention?

[kcoyle]

I agree that there may well be more than one standard that is behind the profile. dependsOn sounds okay, but I'd also be interested in hearing other options. I thought about "extends" but it could just as easily narrow, restrict or constrain. It's hard to come up with a word that conveys all of that. depends may win.

[makxdekkers]

Again, can we discuss and decide on the semantic definition of a property before deciding on what the URI is?

[nicholascar]

Why don’t we just use prov:wasDerivedFrom? That property indicates non-exclusive dependence so would fully cover dependsOn (or dependedOn at time of creation)

[makxdekkers]

@nicholascar The definition of prov:wasDerivedFrom is "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". Do you suggest that the part "the construction of a new entity based on a pre-existing entity" is what we're looking for?

[riccardoAlbertoni]

I am probably over-complicating the issue, but I wonder if we want to distinguish between the different type of dependences in order to make smarter the profile negotiation.

I am thinking about a generic dependency property ( e.g., dependsOn suggested by Simon @dr-shorthair), and some specialized dependsOn subproperties to indicate specific kind of dependency in the context of Profiling (e.g., I do not know .. extend, restrict)?

At least a property representing "subtype polymorphism" to help to figure out the compatibility among profiles which is necessarily expressed by the more generic dependency relation.

[nicholascar]

@makxdekkers Yes, that's what I meant. I admit that dependsOn as discussed here may be seen to have a narrower definition than prov:wasDerivedFrom but it is certainly covered by the broader term, including possibly multiple inheritance, and use of that property would obviate the need to create yet another generically named property about derivation which the world can live without.

[aisaac]

I also don't like discussing the specific property to use, before agreeing on what is meant precisely. But in this case I agree that we need a sort of derivation property, and prov:wasDerivedFrom is appropriate for it, even if we end up refining it later.

[dr-shorthair]

Sorry - it appears I hijacked this issue to discuss something related (cardinality), when @kcoyle meant for us to be discussing 'extend or refine' - i.e. is extension acceptable as well as refinement?

[nicholascar]

@rob-metalinkage says that wasDerivedFrom use is ok - can always be specialised later. I will update the ontology doc to reflect this and put through a PR for Rob to review

[rob-metalinkage]

IMHO profileOf is potentially a subproperty of prov:wasDerivedFrom

making it so makes profiledesc dependent on prov (discoverable via owl:includes so we dont need to make this explict?)

for example, a profile V2 that fixes a bug in V1 was derivedFrom V1, but is not a profileOf V1

so, please leave profileOf with its explicit semantics that profiles only restrict dct:Standards in conformant ways.

Happy to model the other relationships more with prov: however. Suggest not overloading profiledesc with a separate versioning model however.

Getting Makx's insight into the DCAT-AP governance and maintenance processes and history will be useful to see if there really are any prov: specialisations profiles uniquely need.

[dr-shorthair]

agree: we are talking about a sub-property of prov:isDerivedFrom.
I would still suggest using a name other than "profileOf" however,
But that's probably just my residual discomfort with the idea that there is any real difference between a 'Profile' and a 'Standard with dependencies'.

After a couple of days with @danbri reminding us to think of the effect of the surface syntax on adoption, I'd recommend new properties in a single namespace, even if they are axiomatically linked in the background to standards like PROV. It is helpful to focus on the instance data, and for that to be clear and uncluttered. This is particularly if we anticipate use of, and maybe a run-time choice of, multiple different technologies to specify it (RDFS, OWL, SHACL, ShEx, JSON-schema).

[andrea-perego]

Sorry for jumping in late, but I share @makxdekkers's concerns about using prov:wasDerivedFrom. In my understanding, this property does not imply any dependency with the "base specification".

BTW, VOAF has a property voaf:reliesOn which is close to (my understanding of) the dependecy between a profile and the base specification - quoting:

relies on - Indicates that the subject vocabulary uses or extends some class or property of the object vocabulary

[riccardoAlbertoni]

+1 to @andre-perego
I like the idea of taking inspiration/reusing voaf:reliesOn.

As noted by Lars's mail, voaf:reliesOn is between voaf:Vocabulary which is a subclass of 'void:Dataset', so it is quite RDF centric. Shall we generalize this property to support other kinds of vocabularies/profile/whatever.

@nicholascar: How to generalize voaf:reliesOn seems to be closely related to the Alignment between profileDesc and VOAF (issue 235)

I would suggest to consider the voaf:reliesOn sub-properties as a starting point for further candidate specialized relations. For example, quoting

• voaf:usedBy: Indicates that the subject vocabulary is used by the object vocabulary
• voaf:extends: Indicates that the subject vocabulary extends the expressivity of the object vocabulary by declaring subsumption relationships, using object vocabulary class as domain or range of a subject vocabulary property, defining local restrictions etc ...
• voaf:specializes: Indicates that the subject vocabulary defines some subclasses or subproperties of the object vocabulary, or local restrictions on those
• voaf:generalizes: Indicates that the subject vocabulary generalizes by some superclasses or super properties the object vocabulary.

I guess it is worth to take a look and align to such sub-properties, also to avoid reinventing relations that are somehow already identified in the linked data community.

[nicholascar]

Discussions about prof:isProfileOf's relation to prov:wasDerivedFrom now taking place in the Issue #485