added relationship *member* with examples

[elf-pavlik]

added missing JSON-LD idioms for ObjectProperties

[ahdinosaur]

uhhh... isn't this in conflict with our existing definition of a relationship (a relationship is an object that has vf:relationshipType, vf:subject, vf:object, vf:context)? or am i missing something?

[fosterlynn]

long story.... see issue #38 .... more discussion needed i'm sure....

but briefly, elf corrected the subject, object, relationship to be @id's, which they are I think; and we added vf:member to the vocab itself, that is where the long story is

[ahdinosaur]

i'll need some time to digest #38, so many words, not much time. i'm keen with adding a few "standard" relationships like member to our vocab (as per https://github.com/valueflows/agent/issues/26), but i don't want this to mean we add special cases for how we represent relationships (as far as i can tell, this new property vf:member introduces a special case), since i feel that goes against our simple abstract model powered by user-defined type objects (in my opinion one of our core design principles).

[elf-pavlik]

@ahdinosaur please see diagrams on https://github.com/w3c-social/social-vocab/wiki/Verbs---owl:Class-vs.-rdf:Property#proposed-alternative

I will soon propose to delegate all relationships(types) to https://w3id.org/role/

and replace in examples vf:member with role:member

If I don't want to qualify this relationship, I can assert only one triple using direct relationship. vf:member / role:member act as label for the edge in a graph which you can reify (make qualified relation) or just use directly. Both mean the same and we should support both options seamlessly!

[fosterlynn]

@elf-pavlik @ahdinosaur Note that the role concept (according to elf's example) is using the split relationship. For example there is are separate role instances for buyer and seller.

I also think some of the examples in elf's roles are not relationships agreed upon by 2 agents, they are more reflections of economic events - buyer and seller are like this. So they are indeed roles in one or more events. Where customer and supplier are more like the agreed upon relationships (or could call them roles).

[fosterlynn]

I will soon propose to delegate all relationships(types) to https://w3id.org/role/

@elf-pavlik looks like we still need to iron out the question of user defined relationships(types).

@ahdinosaur @elf-pavlik @bhaugen Maybe we should have a call on this? Can it wait until our next call or should we do it sooner to get this hashed out?

[ahdinosaur]

@elf-pavlik i think i understand, but just to make sure, you're saying that using member as a property on the Agent object is the same as creating a property object that references the Agent object? as in a proper linked data reasoner would understand these are the same and we're not adding additional non-"standard" sugar for our apps to implement?

[ahdinosaur]

@ahdinosaur @elf-pavlik @bhaugen Maybe we should have a call on this? Can it wait until our next call or should we do it sooner to get this hashed out?

i prefer we wait until the next expected call slot, i'd rather we build up a slow and steady rhythm with our calls than try to rush anything.

[fosterlynn]

i prefer we wait until the next expected call slot, i'd rather we build up a slow and steady rhythm with our calls than try to rush anything.

@ahdinosaur cool

[elf-pavlik]

@elf-pavlik i think i understand, but just to make sure, you're saying that using member as a property on the Agent object is the same as creating a property object that references the Agent object? as in a proper linked data reasoner would understand these are the same and we're not adding additional non-"standard" sugar for our apps to implement?

Example you show uses only subject, relationship (predicate/property), object

{
  "@context": [
    "https://rawgit.com/valueflows/agent/master/context.jsonld",
    {
      "dex": "https://holodex.enspiral.com/api/"
    }
  ],
  "subject": "dex:people/mikey",
  "relationship": "member",
  "object": "dex:groups/enspiral-craftworks"
}

Since it has no additional qualifications for that relationship (I really find term QualifiedRelationship least confusing), we can shortly state the same as

{
  "@context": [
    "https://rawgit.com/valueflows/agent/master/context.jsonld",
    {
      "dex": "https://holodex.enspiral.com/api/"
    }
  ],
  "@id": "dex:people/mikey",
  "member": "dex:groups/enspiral-craftworks"
}

_NOTE_: schema:member has definition as hasMember, which I follow in my examples included in this repo. In your example you seem to use it in opposite direction as isMemberOf.

If we reverse member to mean hasMember, we get

{
  "@context": [
    "https://rawgit.com/valueflows/agent/master/context.jsonld",
    {
      "dex": "https://holodex.enspiral.com/api/"
    }
  ],
  "subject": "dex:groups/enspiral-craftworks",
  "relationship": "member",
  "object": "dex:people/mikey"
}

(just swapping values of subject and object)

and in short

{
  "@context": [
    "https://rawgit.com/valueflows/agent/master/context.jsonld",
    {
      "dex": "https://holodex.enspiral.com/api/"
    }
  ],
  "@id": "dex:people/mikey",
  "@reverse": {
    "member": "dex:groups/enspiral-craftworks"
  }
}

Defining relations/relationships as instances of rdf:Property (label for an edge in directed graph), allows as to use it as property in JSON-LD serialization. Coming back to #21 I see no case where one would use 'agent type' as property name in JSON-LD!

[ahdinosaur]

@elf-pavlik thanks for the extended examples. so what connects rdf:Property with as:subject and as:object that an RDF reasoner would know that these different ways of defining relationships are equivalent? i want to make sure we aren't adding more work for ourselves (having to implement multiple cases for how to parse relationship data) just to get some sweet sugar.

[elf-pavlik]

Above subject, property, object pattern follows http://www.w3.org/TR/rdf-schema/#ch_reificationvocab

All instances of rdf:Property (mostly used for labeling edges of directed graph) one can consider relationship data, especially ones declared as owl:ObjectProperty, in JSON-LD using "@type": "@id" construct

I guess we may need to discuss how to discover those qualified relations. Having only as starting point https://holodex.enspiral.com/api/people/mikey how do you find

{
  "@context": [
    "https://rawgit.com/valueflows/agent/master/context.jsonld",
    {
      "dex": "https://holodex.enspiral.com/api/"
    }
  ],
  "subject": "dex:people/mikey",
  "relationship": "member",
  "object": "dex:groups/enspiral-craftworks"
}

We shouldn't assume, that by dereferencing (making HTTP GET request) to URI which denotes an agent, we will receive included response which includes all the relations(hips) to other agents, resources, events, concepts etc. Dedicated issue for that concern: https://github.com/valueflows/valueflows/issues/59

[ahdinosaur]

Above subject, property, object pattern follows http://www.w3.org/TR/rdf-schema/#ch_reificationvocab

cool, i think i get it now. i appreciate you spending the time to explain this to me. :) although still kinda scared since the OWL document describes itself as being "a very expressive language (both computationally and for users) and thus can be difficult to implement well and to work with", hehe.

[elf-pavlik]

cool, i think i get it now. i appreciate you spending the time to explain this to me. :)

happy to share my current understanding, IMO while we need pieces of code to do their work, we may even more need to build shared understanding wherever possible :)

although still kinda scared since the OWL document describes itself as being "a very expressive language (both computationally and for users) and thus can be difficult to implement well and to work with", hehe.

I just linked to OWL document to show where I take, from already established and formalized references, terms like ObjectProperty, DataProperty (shared understanding again!). For now I don't see much need to implementing OWL based reasoning, we may still need to deal with reasoning based on owl:inverseOf based on resolution of https://github.com/valueflows/valueflows/issues/52

So far I've heard that only rdflib.js (bit old lib, but web pros wrote it back in a days) implements reasoning over owl:inverseOf in JS. While TimBL (one of its contributors and users in projects like tabulator) openly encourages to use single relation definition and than leverage (in|re)verse features of particular syntax https://github.com/mnot/I-D/issues/39#issuecomment-89789736