Create generic properties such as "hasExpression" or "documentedIn" instead of hasResource/(hasRole | hasArtifact)

[nicholascar]

From Tom Baker et al. of the ShEx IG:

We wonder whether generic properties such as "hasExpression" or "documentedIn" might suffice to cover the simplest use cases for clustering profile-related resources.

Modeling these as [Profile->ResourceDescriptor] properties would more straightforwardly support scenarios in which a given profile-related resource were related to more than one other profile-related resource, but with different roles

[larsgsvensson]

We had a similar use case in the DNB and minted the property dnbt:isDescribedIn that possibly could cover Tom's documentedIn.

[aisaac]

Cross-linking to #6 re. the "expression" wording.

[aisaac]

Note that one issue for this is the loss of flexibility for representing the roles: using as many properties (possibly in a hierarchy) as there are possible roles work well when the number of roles is small and controled. It will become unwieldy if extensions have to be devised, or if the hierarchy of property is difficult to conceive (e.g. in case there is multiple inheritance, or properties that do not relate very well to any other). In the latter case, and especially if there's no requirement for expressing formal axioms about the relationships/roles, then a simple SKOS-inspired vocabulary for these relationships/roles will probably be easier to handle.

[kcoyle]

I see another possible path, which is a small set of general properties that can be sub-propertied in another namespace for specific applications. This combines both the "generic properties" and the "specific roles" in a more usable form, IMO. A disadvantage I see to the current set of roles is its flatness. Adding more specific roles at the same level is not ideal for searching.

The general properties could be things like:
-- documentation
-- validation
-- vocabulary definition

These may be sufficient for many users. Those who want more can create sub-properties like:

-- documentation
--- guidance rules
--- use cases
--- domain model
--- input form support

-- validation
--- full validation
--- partial validation

This facilitates searching, because you can search on the general property and retrieve all of the specific properties as well, so that you don't have to know what specific types of resources a "foreign" profile has. In a sense this becomes: "is there validation code for this profile?" or "get me whatever documentation exists related to this profile."

[makxdekkers]

+1 to @kcoyle

[aisaac]

So we'd be pushing the complexity to creators of extension? I can live with it.
Still I doubt it will work. Extending a vocabulary by subproperties is quite hard. It will be especially awful when people would like to reconcile extensions, where rdfs:subpropertyOf (that has precise semantics) will have probably be misused to represent links that are much softer. In fact the high possibility of such misuse is probably going to cast a big doubt on any extension, even for simple re-use.

If we want specializations, then we can do it also with a vocabulary of roles, with skos:broader between roles. This would allow to "search on the general property and retrieve all of the specific properties as well". Again, this is how Web Annotation Data Model has done it for its framework foir representing motivations, and I believe this as best a practice it can get.

And as a final heads-up: we can't probably avoid discussing hierarchies of profile roles for our 'core'. I believe that both 'documentation' and 'guidance' (which you've rightfully put in a specialization relationship) have to be tackled (and thus, minted) by us as they correspond to core scenarios.

[kcoyle]

Antoine, I'm not wedded to any particular solution, but I'm not sure why extending by subproperties is harder than SKOS B/N. They seem to be similar structurally when declaring across namespaces. Is it as easy to retrieve on SKOS B/N relationships as it is to retrieve of sub-/sup- in SPARQL?

What I'd like to see is a discussion of USE before we make any decisions - some use cases that actually show use of the roles would be very helpful. I'm assuming that some use would come through the content negotiation, but what use is desired for general searching? We have a requirement that profiles be discoverable, and if we define profiles as not singular things but clusters of resources with different roles, what does that discoverability look like? I'm positing what to me is a likely situation ("find me profiles for bibliographic data that are based on BIBFRAME and have a ShEx validation file", "find me a bibliographic profile, and get me everything that is documentation for that profile"), but I would love to see a bunch of scenarios so we have something concrete on which to make decisions.

[aisaac]

@kcoyle it is easy to retrieve SKOS (transitive) B/N relationships, but it requires activating transitivity which may not be activated in every tool by default. That said, quite often schema inference (incl transitivity of rdfs:subPropertyOf) is not always activated either - for similar reasons.
On the other hand PROF already relies on inference of transitivity, so I guess relying on it for the role hierarchy won't change the situation much.

Extending by subproperties is harder than with SKOS, because rdfs:subPropertyOf has more precise (formal) semantics. So either it will be harder for implementers who want to do it carefully, or it won't be harder for implementers who don't care about misusing rdfs:subPropertyOf. I expect problems will especially occur when the classification of roles could become vague and roles could be classified under several categories. Multiple inheritance of properties is notoriously hard to handle in data modeling exercises - more than with classes I believe.

Re your point on discussing use, I agree. But I can already anticipate that if we don't have much application scenarios right now for hierarchies, we won't get very far in terms of formal semantics and then opting for a solution that minimizes the semantic commitment for them (and thus opting for SKOS rather than RDFS/OWL) seems a wiser first choice.

[kcoyle]

@aisaac Thanks. I take your point that if we don't have application scenarios then we want a very general solution. I do think, though, that even a general solution needs suitable use cases. Perhaps we need to spend some time making sure that our use cases and the general solution are in sync?

[rob-metalinkage]

i'm against specific properties - originally I was thinking that way but there are two problems:

1. resources may have multiple roles - for example both validation and form building are typical roles for SHACL specifications.
2. such roles need to be defined in RDFS and OWL, hence logically in the ontology itself - and thus much more difficult to propose a set, but allow people to choose a different set or extend these roles.

[makxdekkers]

An advantage that I see for using SKOS roles is that the responsibility is moved to someone else and this group doesn't have to worry about it, beyond defining a property to point to a role concept. The disadvantage is that, when people start creating their own role vocabularies, it will be hard to interoperate across different role vocabularies. This risk would be mitigated by having a 'central' role vocabulary, but then there is a need for a maintenance agency. A W3C working group cannot be responsible for that kind of governance as its lifespan is limited.

Creating a small set of subproperties at least has the advantage that there is a fixed set of anchor points that people can rely on.

With a set of subproperties, a lazy publisher can decide just to use one (or more) of those; if the roles are expressed as SKOS concepts, the publisher must search for an existing role vocabulary that fits their needs or create their own.

The question for me is how much precision is going to be required to distinguish roles and how more or less precision is going to help or hinder interoperability.

[aisaac]

@kcoyle I fully agree. Hopefully we'll do this for everything we've done :-)

@makxdekkers I am puzzled: I agree with your analysis on the tradeoff for handling extensions to SKOS vocabularies, but wouldn't any of this be actually worse when handling extensions to a vocabulary of RDFS properties?

[makxdekkers]

@aisaac I don't think it would be worse, both are hard to handle. The difference that I see is that in the case of sub-properties, if a publisher doesn't need additional precision or have no financial or human resources to go into the details, they can use the provided set of sub-properties which is cheap, while in the case of SKOS roles, even if they don't need additional precision, they need to use an existing or local vocabulary which involves someone creating and/or maintaining the SKOS vocabulary.

From what I have seen, people like the idea of high precision on a theoretical level, but when they start applying it in practice they often opt for lower precision because that is cheaper.

[aisaac]

@makxdekkers re your last sentence, yes this is why I'm in favour of starting with the less-demanding option (in terms of formal semantics)
To clarify, I also think that if we go to SKOS we should also have a set of roles to start with, just as you mention "the provided set of sub-properties which is cheap". Whether we go for SKOS concepts or RDFS properties, we should have the same default roles captured.

[makxdekkers]

@aisaac But there is a difference in expectation on maintenance and governance. If I understand the processes correctly, if we published a set of general properties as @kcoyle proposed, those would be part of the recommendation and they would be fixed. Any subproperties that people wanted to define as specialisations would be outside of the DCAT/PROF namespace. If on the other hand we were to publish a SKOS concept scheme with some predefined roles, wouldn't people expect that someone managed that concept scheme and that they could write to someone to add a concept to it? Who would that be?
We had that issue with the DCAT-AP -- the ISA programme is responsible for the maintenance of the profile, but not for any of the controlled vocabularies; those are maintained by the Publications Office.

[larsgsvensson]

@makxdekkers scripsit:

If on the other hand we were to publish a SKOS concept scheme with some predefined roles, wouldn't people expect that someone managed that concept scheme and that they could write to someone to add a concept to it?

Can't we make the predefined concepts and the associated concept scheme part of PROF, just as e. g. OWL-Time has a list of predefined individuals?

[aisaac]

@makxdekkers @larsgsvensson yes I am fighting for a list of roles (the ones we identify to meet our requirements) to be indeed folded in the recommendation. Again this would be the same "level of inclusion" as for the subproperty-option. This is also what Web Annotation do with their motivations.

[makxdekkers]

@larsgsvensson Yes of course the group could publish a set of predefined individuals. As far as I see it, there is no semantic difference between defining a small set of generic properties and defining a small set of generic roles, especially if there is no maintenance agency for the role vocabulary. And if you can't add new roles in the SKOS concept scheme, you're losing the flexibility that I think was part of @aisaac's argument.
So you can only realise the added flexibility of a SKOS role vocabulary if it is maintained by someone, and I don't see an obvious candidate for such a long-term commitment.
My own rule is: don't create a vocabulary if you can't maintain it. Remember the Basic Semantic Register, UDDI and UDEF?

[aisaac]

@makxdekkers I don't understand "there is no semantic difference between defining a small set of generic properties and defining a small set of generic roles, especially if there is no maintenance agency for the role vocabulary". The fact that there is or not a maintenance agency is not about semantics. There is a semantic difference between SKOS concepts and RDFS properties, quite a big one actually. Or do you mean something else?

And I'm not sure that we have the same perspective on flexibility: I'm interested in the flexibility of the representation, and SKOS semantics makes it more flexible than RDFS. This said, SKOS doesn't solve all the data management issues of handling extensions, as we've noted in w3c/dxwg#536. But again the argument is a bit moot as a solution based on extending a small set of core RDFS properties (as proposed here) would have the same issues. Can we agree on this?

Maybe it will be easier if we can also agree on the two dimensions of the problem we're considering:

1. pattern for representing roles: (a) SKOS concepts vs. (b) RDFS properties
2. degree of inclusion of roles in core spec: (a) having a core list of roles in PROF and relying on future extensions for specialized needs vs. (b) entirely relying on extension(s).

To me these dimensions are to a great extent orthogonal: a choice on 1 doesn't dictate a choice on 2 and a choice on 2 does not dictate a choice for 1.
Well, I think SKOS makes it easier to handle extensions, but it's not an absolute pre-requisite, and it would benefit for 2a and 2b anyway.

[makxdekkers]

@aisaac Apologies, I probably shouldn't have said that the two approaches are not different semantically. I understand that word comes loaded with all kinds of formal connotations. I was simply trying to say that you can express the roles either way -- with RDF properties or with SKOS concepts -- and convey the same meaning, in the human understanding sense.
I guess the misunderstanding is that you are looking at the modelling issues and I am looking at the practical implications.
I do agree both approaches have the same issues. I just think that doing it with a SKOS concept scheme with some named individuals could create an expectation that someone can propose additional concepts to be included, and I think there is no way to do that if there is no organisation that commits to maintain the concept scheme over time.

[makxdekkers]

So on your options 1 and 2, I would vote for 1(b): modelling with RDF properties to cover a small number of generic types of relationships and 2(b) relying on extensions. That would remove the need for maintaining a SKOS vocabulary.

[smrgeoinfo]

another approach would be to have two properties: 1) an RDF property to cover a small number of generic types of relationships, for interoperability (ideally a required property); 2) an optional 'prof:roleConcept' property populated by skos:concept for semantic precision, that would probably have vocabularies defined by different communities and specified in profiles of prof.
Admittedly, since it rdf, anyone could include their own role concept property; the advantage of defining a property in the spec is that at least it would be queryable, even if the meaning of the values is not standardized.

[aisaac]

@makxdekkers thanks but I really don't understand why the SKOS pattern implies maintaining a SKOS vocabulary. One can use SKOS concepts in the core, and then have the extensions managed independently. Again, look at how the Web Annotation have done it. They don't manage a SKOS vocabulary for extensions.

[kcoyle]

@smrgeoinfo re:2 properties - that is close to what I was suggesting. I don't care if they are SKOS or RDF, but as @makxdekkers says we should supply a core of roles because in fact that's what people will use (Dublin Core being the proof of that concept). @aisaac I would like us to have some formal agreement that a core of roles must be in the PROF vocabulary as published. We can figure out later if they're defined as SKOS concepts or not. I'd like to set up a vote, so I suggest (vote will happen in a separate comment):
PROF will include in the PROF working draft a core of roles, to be determined.

Later we can specify those roles and their semantics. If no one objects strongly I will set up the vote - probably for early next week.

[kcoyle]

@rob-metalinkage

1. Why can't a resource have multiple roles? They obviously will have in many cases. The resource can be the subject of more than one RDF statement. If the PROF model doesn't allow this then we need to discuss.
2. @smrgeoinfo illustrates one way to create an extensible list. Another is to use subclassing of RDF or SKOS B/N, as discussed above.

[makxdekkers]

@aisaac I sort of understand that the choice of RDF properties vs. SKOS roles, or even a flat list like the motivations in OA, is a choice of style with pros and cons on both sides. I do agree that a core set of roles needs to be in the spec to avoid the situation that people will start creating their own sets of roles.
As I see it, in the relation/role style, Dublin Core could have been developed with object properties dct:agent+role and dct:relation+role. That would indeed make extensions for resource-agent relations (beyond creator, contributor and publisher) much easier and could have replaced all the resource-resource relations (replaces, requires, references, hasVersion etc. etc.) with a set of predefined roles.
And I wasn't saying that using a SKOS pattern 'implies' maintaining a SKOS vocabulary -- I was just saying that publishing a set of SKOS concepts might create an expectation that someone maintains that set in the sense of allowing people to request additions of new concepts. But maybe I am reading too much into this.
In any case, let's wait for @kcoyle to set up a vote.

[aisaac]

@kcoyle @makxdekkers I wholeheartedly agree to having a set of core roles in PROF, whatever be their representation! This was my position in w3c/dxwg#535 and w3c/dxwg#536 that have already discussed the issue a bit, by the way.

[andrea-perego]

@makxdekkers said:

@aisaac I sort of understand that the choice of RDF properties vs. SKOS roles, or even a flat list like the motivations in OA, is a choice of style with pros and cons on both sides.

Just to note that the two approaches are not mutually exclusive: the same term can be defined as both a skos:Concept and an rdf:Property - see [SKOS-REFERENCE], §3.5.1.

For me, however, the main point for deciding whether to use skos:Concept or rdf:Property depends on whether prof:ResourceDescriptor will be eventually defined as an association class (as per @smrgeoinfo proposal) or something analogous to an ADMS/DCAT distribution.

[rob-metalinkage]

@kcoyle - i am saying it can have multiple roles. using properties makes this harder to express IMHO

also - I think SKOS more naturally fits a register concept - and even if we dont want to maintain a register, communities may need to.

this is why i went for a SKOS model

I think we all agree we want a basic set of roles defined and an extension mechanism and not be forced to set up a mechanism to maintain it (for now)

OTOH, if we have a separate concept scheme artefact (as currently implemented) then its maintenance is more easily delegated to an appropriate control body (at the moment the control body is the W3C - and its mechanism is to spin up a group to act to update it)

that said - I'm happy we are debating the correct aspects

[kcoyle]

To begin to resolve at least some of the issues around PROF and roles, my next issue will call a vote. We've used this voting technique successfully in DCMI. I'll post more information to the group's list.

[kcoyle]

VOTE: Emoji's - thumbs up, thumbs down, or the frowny for no decision

PROPOSED: Include a core set of roles in the next working draft of the Profiles Vocabulary.

NOTE: This does not solve the problem of generic properties, but comes up frequently. This does not close this issue.

[aisaac]

A reminder to vote on @kcoyle 's comment above: this is a brilliant move to split concerns. If we could get positive votes from everyone who participated this discussion, then we'd have made great progress.

[rob-metalinkage]

@aisaac - actually its a vote to conflate concerns (individuals and classes in the same ontology). Still its a decision we can live with and move on.

[rob-metalinkage]

Merged - a decision has been made and acted on. Open new issues for specific comments.

[kcoyle]

@rob-metalinkage The vote did NOT cover the entire issue.