Dxwg: Are the main prof: classes association-classes?

[dr-shorthair]

I had another go at testing the profiles ontology - this time for PAV as a profile of PROV-O.

Initially, I just followed the patterns of the other ones in the current examples graph, which used the actual URI's for the dependencies - see PAV example which follows the DCAT-AP example.

However, I felt uneasy about assigning a role to a _resource_, rather than to the _association_ (if it is inherent in the resource it is a _type_ not a _role_ ...). Then I recalled earlier adding the prof:hasArtifact property, so that the prof:ResourceDescription class could serve as an association-class.

So I have revised the example with the prof:ResourceDescription individuals now as qualified-associations, rather than the actual artefacts.

1. Is this pattern correct? If so, most of the other examples in this graph need to be brought into line
2. The explanation of prof:ResourceDescriptor and prof:hasArtifact needs clarifying to make this more clear
3. should prof:BaseSpecification also follow this pattern, i.e. be a sub-class of prof:ResourceDescriptor rather than of dct:Standard?

[andrea-perego]

@dr-shorthair said:

However, I felt uneasy about assigning a role to a resource, rather than to the association (if it is inherent in the resource it is a type not a role ...).

I have the same concern, and there was a short discussion on this topic during the last F2F.

IMO, the role is not intrinsic to the resource descriptor itself, but it is rather an "attribute" of the relationship between the resource descriptor and a profile.

Personally, I see more appropriate to model roles as relationships between resource descriptors and profiles.

[aisaac]

This is a good discussion. Having roles as concepts/classes is not ideal. On the other hand, it's awkward to create many sub-properties of prof:hasResource and/or prof:hasArtefact. Even more importantly, it could be that roles for Resource Descriptors and their artefacts are actually 'essential' (in the sense of formal ontology). E.g., an XML schema could be said to always be usable for validation. So it's not a 'role' anymore (again, in the sense of formal ontology) anymore, it becomes closer to a type.

Of course this needs to be tested against the roles that we agree on. Which probably means that we should have the discussion once we've agreed on all the roles we need.
(incidentally, this would also be a point for including the list of roles we want into the PROF ontology recommendation!)

NB: I would rather hold off discussion on BaseSpecification in this issue until we're sure we want to keep this class, i.e. until #641 is closed.

[andrea-perego]

@aisaac wrote:

Even more importantly, it could be that roles for Resource Descriptors and their artefacts are actually 'essential' (in the sense of formal ontology). E.g., an XML schema could be said to always be usable for validation. So it's not a 'role' anymore (again, in the sense of formal ontology) anymore, it becomes closer to a type.

I remember that this was one of the points raised during the F2F. However, I'm not sure how safe would this solution be. E.g., I think who has been playing with XML for some time, stumbled upon XML Schema's that couldn't be used for validation, and so this task was carried out via another method (e.g., Relax NG). Supposing to apply this use case to a profile, we have a resource descriptor (XML Schema) used for defining the profile, and another one (Relax NG) for validating it.

That's an additional reason why I think a "role" cannot be intrinsic to a resource descriptor , but it always needs to be related to the profile.

[dr-shorthair]

Just to be clear, this issue is about which of these implementation patterns makes the most sense:

1. denote the resource description with the URI of the artefact:

<https://practicalprovenance.wordpress.com/2016/05/07/tracking-versions-with-pav/>
  rdf:type prof:ResourceDescriptor ;
  dct:format <https://www.iana.org/assignments/media-types/text/html> ;
  prof:hasRole roles:Guidance ;
.

1. GIve the resource description its own URI, and provide a link to the actual artefact:

:pav-blogpost
  rdf:type prof:ResourceDescriptor ;
  dct:format <https://www.iana.org/assignments/media-types/text/html> ;
  prof:hasRole roles:Guidance ;
  prof:hasArtifact <https://practicalprovenance.wordpress.com/2016/05/07/tracking-versions-with-pav/> ;
.

Under pattern 1. the role is intrinsic to the resource.
Under pattern 2. the role is attached to the association.

[aisaac]

@andrea-perego you may be right.
Anyway now I understand @dr-shorthair 's intention, and pattern 2 (an instantiation of the n-ary relation pattern, I guess) could be a way out of the issue, indeed.

I guess my misunderstanding of the scope of the issue was because of the present tense in "Are the main prof: classes association-classes?" I don't think that in the current PROF spec these classes are association classes. But we may want to change their semantics and turn them into such classes, indeed. But I must say that I've not thought of it much now so I'm going to abstain for the moment.

[nicholascar]

Some of the early examples I've made use Pattern 1 but others, since the addition of prof:hasArtifact to the ontology use the N-Ary relation Pattern 2.

I agree that from a modelling perspective, Pattern 2 is the better one as it doesn't lock the artifact into anything (properties that might, through inference or more info lead to clashes).

Unless there are objections, I'll redo all examples like this, since I have to update them all anyway.

[dr-shorthair]

@nicholascar if you accept https://github.com/w3c/dxwg/pull/639 you'll find I redid them already.

[nicholascar]

Thankyou @dr-shorthair!

[nicholascar]

Accepting proposition they are association classes and Simon has updated examples accordingly which have been merged from Pull https://github.com/w3c/dxwg/pull/639 so closing.

[aisaac]

@nicholascar does the change also imply changing some parts of the text of the spec, not only examples?
It wouldn't be great if we leave some wording in, which would allude to the old pattern. We may end up in a situation like the one for prof:BaseSpecification, where there might have been a concept drift and there are still parts of the documentation that are not-so-precise about it.
NB: in the end I'll trust your judgement about this, I just want to double-check, since this editorial aspect of the change has not been mentioned in the issue.

[kcoyle]

I believe that @andrea-perego was suggesting that another option is:

https://practicalprovenance.wordpress.com/2016/05/07/tracking-versions-with-pav/
prof:isGuidance http://example.com/profile-it-is-guidance-to .

0r

http://example.com/profile
rdf:type prof:Profile ;
prof:hasGuidance https://practicalprovenance.wordpress.com/2016/05/07/tracking-versions-with-pav/ ;
prof:hasFullConstraints http://example.com/sh.ttl ;
prof:hasFullConstraints http://example.com/sx.ttl .

... that the role become the predicate between the resource and the profile. That has both advantages (more direct path) and disadvantages (additions are changes to the base vocabulary, not a term list). (Yes, I did not do all of the detail regarding file types - just hitting the concept here. )

Andrea, did I get that right? Please correct if not.

[andrea-perego]

Thanks, @kcoyle . This is actually the pattern I was suggesting to consider.

My main point was about considering PROF roles as relationship, so I'm definitely in favour of the association class approach proposed by @dr-shorthair compared with the original one. However, I wonder whether a less complex pattern, using just a binary relationship, could do the same job in a simpler way.

[aisaac]

@kcoyle @andrea-perego fair point. I would say I still prefer @dr-shorthair 's solution at this point because it seems more flexible. But when we see how many roles we have and how much (or little) they're likely to extend in the future, I wouldn't object to the binary relationship option. Maybe we can keep it as a note for a future WD?

(and yes @kcoyle I'm not looking at the what the extensions in your URIs could mean ;-) I agree it's not the problem for this specific issue!)

[kcoyle]

Is option 2 likely to be coded with a blank note for the resource description? "Things" often or usually have IRIs, but associations (in my experience) end up being bnodes. If that is the case then I see this as a downside. The main question is: can it be expected that folks will mint actual IRIs for the association nodes?

[nicholascar]

Due to the Issue https://github.com/w3c/dxwg/issues/747 created based on Feedback, the substantive issues left in this Issue are now discussed there, therefore I'm marking this one "due for closing" since the original question's - about association classes - been answered, at least for now.

[nicholascar]

Long addressed with remaining issues in #747 so closing.