Qualified Relation subclasses?
Opened this issue · 5 comments
It looks like in the vocab, the preferred method of defining types of (in this case) relations is to create a subclass which then becomes part of the vocabulary. @elf-pavlik has examples: Membership (elf Pavlik member of Social WG), Following (elf Pavlik following Amy Guy).
My question is what to do with the proliferation of subclasses which can occur, and which in our case are user defined. Some examples:
- In w3c, more specifically, elf Pavlik invited expert of Social WG. Would InvitedExpertMembership or something similar be created as a subclass of Membership?
- We work with a local network of herbalists and farmers, and they have defined the following relationship types between agents (people or organizations) (partial list): Advisor, Owner, Supplier, Drying Site, Harvesting Site, Trainer, Harvester, FarmResponsibility.
- We know a network of software developers who have defined: Mentorship, Stewardship, both between 2 people. The also have Members and Contributors, between a person and an organization.
Our software could spit out the vocabulary that is defined by users, maybe as a vocab specific to the installation (to handle conflicts), but that is far short of a carefully documented vocabulary. So, if we do that, should we spit out the new user-defined relationships as subclasses of Qualified Relation? Or is some other alternative acceptable that would just have a different qualification without being a new subclass?
P.S. I like the option to use Qualified Relation or a simple object property to express a relationship/role, seems like a very positive direction.
Another way to do it is to have actions or activities with types (or subclasses) and the result could be many things - new relationship formed (e.g. follows), new item created, tag added, etc. Alex Passant and PM Champin did some work on mapping Activity Streams to SIOC Actions five years ago, see http://www.slideshare.net/mobile/pchampin/s-5112062 and http://rdfs.org/sioc/actions
John
http://Bresl.in
On 30 Apr 2015, at 19:57, Lynn Foster notifications@github.com wrote:
It looks like in the vocab, the preferred method of defining types of (in this case) relations is to create a subclass which then becomes part of the vocabulary. @elf-pavlik has examples: Membership (elf Pavlik member of Social WG), Following (elf Pavlik following Amy Guy).
My question is what to do with the proliferation of subclasses which can occur, and which in our case are user defined. Some examples:
In w3c, more specifically, elf Pavlik invited expert of Social WG. Would InvitedExpertMembership or something similar be created as a subclass of Membership?
We work with a local network of herbalists and farmers, and they have defined the following relationship types between agents (people or organizations) (partial list): Advisor, Owner, Supplier, Drying Site, Harvesting Site, Trainer, Harvester, FarmResponsibility.
We know a network of software developers who have defined: Mentorship, Stewardship, both between 2 people. The also have Members and Contributors, between a person and an organization.
Our software could spit out the vocabulary that is defined by users, maybe as a vocab specific to the installation (to handle conflicts), but that is far short of a carefully documented vocabulary. So, if we do that, should we spit out the new user-defined relationships as subclasses of Qualified Relation? Or is some other alternative acceptable that would just have a different qualification without being a new subclass?
P.S. I like the option to use Qualified Relation or a simple object property to express a relationship/role, seems like a very positive direction.
―
Reply to this email directly or view it on GitHub.
@elf-pavlik also mentioned about schema:Role in #1
Do these subclasses have additional properties? If not I would suggest to consider using a SKOS property of the superclass instead.
@akuckartz I like your point about keeping in mind if potential subtypes of QualifiedRelation/N-aryRelation class have any custom properties, even sub properties which specialize other properties. e.g. http://schema.org/participant
@akuckartz Thanks! These subclasses can be grouped broadly based on properties (which we haven't nailed down yet), but beyond that they do not have additional properties. Will see if I can figure out how to use SKOS properties. If you have a quick example and time, could you post it?
@parklize Yes, thanks. I think schema:Role has the same issue of proliferating subclasses, correct me if I'm wrong. And I don't know which existing structure is best, didn't mean to emphasize QualifiedRelation. Just trying to see how to deal with user defined roles or types. And happy that we have something that can have properties, is not just the relation.
@elf-pavlik Interesting example (participant). I can see we may need to distinguish between actions that don't really imply an ongoing relationship between agents, and explicit definitions of ongoing relationships. I think this is part of where you were going with your follows examples, which I now can't quickly find, but liked. :( In our case, we are giving people a way to record the shape of their network(s) in agent relationships.