Skip to content
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

Are the main prof: classes association-classes? #638

Open
dr-shorthair opened this issue Dec 21, 2018 · 15 comments

Comments

@dr-shorthair
Copy link
Contributor

commented Dec 21, 2018

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?

@dr-shorthair dr-shorthair added this to the Profile formalization milestone Dec 21, 2018

@dr-shorthair dr-shorthair added this to To do in Profile Guidance via automation Dec 21, 2018

@dr-shorthair dr-shorthair changed the title [profont] Are the main prof: classes are association-classes? [profont] Are the main prof: classes association-classes? Dec 22, 2018

@nicholascar nicholascar changed the title [profont] Are the main prof: classes association-classes? Are the main prof: classes association-classes? Dec 27, 2018

@andrea-perego

This comment has been minimized.

Copy link
Contributor

commented Jan 7, 2019

@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 comment has been minimized.

Copy link
Contributor

commented Jan 9, 2019

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.

@nicholascar nicholascar added this to To do in Profiles Ontology via automation Jan 9, 2019

@andrea-perego

This comment has been minimized.

Copy link
Contributor

commented Jan 9, 2019

@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

This comment has been minimized.

Copy link
Contributor Author

commented Jan 9, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Jan 10, 2019

@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

This comment has been minimized.

Copy link
Contributor

commented Jan 10, 2019

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

This comment has been minimized.

Copy link
Contributor Author

commented Jan 10, 2019

@nicholascar if you accept #639 you'll find I redid them already.

@nicholascar

This comment has been minimized.

Copy link
Contributor

commented Jan 10, 2019

Thankyou @dr-shorthair!

@nicholascar

This comment has been minimized.

Copy link
Contributor

commented Jan 10, 2019

Accepting proposition they are association classes and Simon has updated examples accordingly which have been merged from Pull #639 so closing.

Profile Guidance automation moved this from To do to Done Jan 10, 2019

Profiles Ontology automation moved this from To do to Done Jan 10, 2019

@aisaac

This comment has been minimized.

Copy link
Contributor

commented Jan 10, 2019

@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.

@aisaac aisaac reopened this Jan 10, 2019

Profile Guidance automation moved this from Done to In progress Jan 10, 2019

Profiles Ontology automation moved this from Done to In progress Jan 10, 2019

@kcoyle

This comment has been minimized.

Copy link
Contributor

commented Jan 11, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Jan 11, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Jan 13, 2019

@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

This comment has been minimized.

Copy link
Contributor

commented Jan 30, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Feb 14, 2019

Due to the Issue #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 nicholascar self-assigned this Feb 14, 2019

@nicholascar nicholascar added feedback and removed prof-2PWD labels Feb 14, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.