Per discussion with @elf-pavlik we are thinking that we should define some core relationship type rdf:Properties. Like "member", .... Then if people want to add more, those can be sub-propertied. This will allow networks to define their own (which they do freely in NRP), as well as allow apps using the data to default to a known property if it matters to them. For example if they need to treat a "member" differently than a "supplier", or whatever we come up with for the core.
What do others think?
Here is an old issue where we discussed this: #2 . I thought there was another one too, but I can't find it. (@ahdinosaur EDIT: we discussed this in #26 (closed) as well)
Here is the gitter discussion:
@fosterlynn i commented on your PR
looking at Relationship, I think around using role:member, role:mentor, role:steward as value of proposed vf:relationship
this pattern very much relates to https://github.com/w3c-social/social-vocab/wiki/Verbs---owl:Class-vs.-rdf:Property
and I experiment with it in https://github.com/hackers4peace/plp-test-data/blob/master/w3c-social.jsonld
@elf-pavlik are you saying we should have both role and relationship, or use "role" instead of "relationship"? Or was my text confusing around relationship covering both concepts, which are very close?
@elf-pavlik I am not trying to go away from using rdf:Property for the logical Relationship Type, just don't know how else to show it on a logical UML diagram
I tried to explain that in the verbage
I'm fine with it being a property, but still the property has properties.....
so to speak
my bad: "relationship": "vf:mentor" (I used role:mentor since for now I use https://w3id.org/role/ mapped to that prefix)
ah ok
property has properties
let me see examples in your PR...
the properties of the verb are the labels
and i think in holodex there are also some query patterns or something like that
when i say properties of.... I am speaking logically, just that we need to group the properties, as you did in an example a long time ago... and also in the PR example
but those properties stay on vocab level not data expressed with this vocab level
oh, i got it
when you define you own properties you consider it as part of your data...
not part of your extension to the common vocab
no
well, maybe....
people have to be able to define their own agent subclasses and relationship verbs, true?
to my understanding in RDF(S) properties are instances of rdf:Property class
yes
that is what i mean too
so we would have vf:RelationshipType rdfs:subClassOf rdf:Property
no need for RelationshipType as I understand it, at least you had persuaded me of that a while ago 😄
although that is a very interesting option!!
in your example I see affiliate (looking for more)
yes, that is creating new verbs
so we provide software to networks and allow them to create their own types of agents and their own relationship verbs, we don't control that
and member
yes
no matter how many verbs we define in our vocab, or other existing vocabs, which have a lot, networks will still want to define their own
~ https://schema.org/member & https://schema.org/affiliation
yes, but our software doesn't know that
i'm ok with defining or referencing a whole bunch of common verb relationships
but still there will be more
do you really need those particular ones defined in http://nrp.webfactional.com/accounting/agent-relationship-type/member namespace ?
i would suggest picking something very uncommon if you want to put it in some very specific namespace
http://nrp.webfactional.com/accounting/agent-relationship-type/my-snowflake-type-of-relationship
@elf-pavlik - Lynn and I don't need them, but each network (so far) has been very picky about relationship names, as well as the names of a lot of other things.
if you follow the ones i created, the link will work
They become moral or religious issues.
ha
because many apps (eg. holodex) will understand semantics of properties defined in common vocabs eg. member, mentor etc. may need to gracefully degrade in some cases to deal with terms which semantics they don't understand
@bhaugen semantics of those relationships or labels which people see in UI?
yes, although i think @ahdinosaur is also in the user-defined verbs category
(in holodex)
one can also define wf:vip-member rdfs:subPropertyOf vf:member
this way app can gracefully degrade to consider it a member but not understanding further specification
in our app we also have a basic behavior flag (code) which says that kind of thing, because we do have to treat members differently than say suppliers (outside the network) for example.
i see no problem with that, just if you don't define your 'user defined' terms as specifications of some common terms, you shouldn't expect apps using them to degrade gracefully, they may just show you the most raw form of data with no UI
main benefit of using terms defined in common (shared) vocab comes to shared understanding
but in a place like holodex (or NRP), it would want to be able to treat any verb in the same way, true? shouldn't matter if it comes from a stable vocab or some network made up their own
I would suggest defining vf:member and you could use it in your system as long as you don't need something with different semantics
so, the herbal network we work with uses "harvesting site", "harvester", "drying site", etc
@fosterlynn I agree in such generic (very shallow semantics) UI like holodex we can do that
yes
for herbal network, the names are more practical than religious
IMO most challenging part, which requires technological solution and social processes - https://www.w3.org/wiki/Socialwg/Social_syntax/User_Stories#Converging_vocabulary_terms
maybe a way to go is for us to define a base set of verbs that exhibit a kind of behavior, and have networks subclass from them, what do you think?
👍
to work on that you could define very generic ones (like member) on level of vf:
ha i like "joker"
yes over time things can converge and be stabilized
and create you own namespace for some wf:snowflake-type-member
but in the meantime, we in NRP have to let people define their own, even if it only works in shallow semantics type UIs
but we also need our "behavior" flag, so i like defining the base set for that reason quite a lot
ok, let's make a use case out of that and for now let's just add examples with wf:member
ha u sure, it was good to push that envelope, no?
yeah!
i'll start an issue tho
so you want vf:member to be added to the context? and fix the examples to use that?
@fosterlynn let's leave it for later, capturing issue does it for now