concrete, real world examples

bhaugen commented 8 years ago

From https://github.com/valueflows/agent/pull/37#issuecomment-147174325

...concrete, real world example, which shows that you can not achieve something what you need using already commonly used pattern based on rdfs:subClassOf and common references like foaf:Person. And which currently you can only think of a way to implementing by introducing into the open environment of The Web completely new construct...

Good challenge. I don't know. Here are some concrete cases that have come up.

Sensorica "affiliate": semantically same as member, but the different name is important to them. Can we allow different names for a common construct?
Enspiral "steward" and "mentor": do common constructs exist with the same meanings?
DHEN "harvester", "harvesting site", and "drying site": these might be relationships between agents and services, rather than between agents and agents.
Is there common construct for "trading partner"? It is semantically not the same as member.
Likewise I have some difficulty understanding subordinate subgroups in a group agent as members, but could live with it.

I'm sure I am missing some cases...

elf-pavlik commented 8 years ago

Sensorica "affiliate": semantically same as member, but the different name is important to them. Can we allow different names for a common construct?

I suggested on gitter how to define custom vocab terms as needed. Question here comes about its semantics, do we want to define rdfs:Class - nrp:Affiliate , which used on person would mean 'this person is an Affiliate (period)' or we want to define it as rdfs:Property - nrp:affiliate which would relate person with another entity, and mark this relation as 'affiliate' (label on directed edge in a graph). We can always qualify this triple by using pattern equivalent to reification (current example vf:Relationship which uses vf:subject, vf:relationship and vf:object).

Enspiral "steward" and "mentor": do common constructs exist with the same meanings?

While enspiral may start with defining such relations - instances of rdfs:Property in their namespace. They don't sound to me that specific to enspiral and make a lot of sense to include in some commonly shared vocabulary, very generic https://w3id.org/role/ could become one of them, also schema.org, it doesn't matter as long as we recognize them as possibly not enspiral specific concepts... Relevant use case: Converging vocabulary terms which constructs like schema:supersededBy can address

@bhaugen I have impression that we don't talk about the same issue as in #37

bhaugen commented 8 years ago

I have impression that we don't talk about the same issue as in #37

@elf-pavlik - you could explain, or I could just follow along and see how things develop.

But I didn't list steward and mentor because they were Enspiral-specific, but because they are different from member. I am happy about however many concepts we could promote to "commonly useful".

bhaugen commented 8 years ago

General question for everybody: are we all happy how these conversations are developing? Is anybody really frustrated? I know they are difficult, and we are all at different stages of our learning curves. But I love all the momentum and interaction and keep everybody in a state of flow as much as possible. Except for days of rest. Can't keep up flow state forever...

fosterlynn commented 8 years ago

@bhaugen I'm not frustrated, but I also fear others are..... and yes although I also love the momentum, I am very behind, still reading emails that arrived during the night.... and I need to take a couple days off this week to do some NRP coding again.... so hopefully we can all proceed as our personal pace allows, and I really think this whole process is incredibly positive!

Since there is a lot of work to do, I think it is OK if we don't have to resolve some of the more confusing issues until the next meeting. They can just sit to some extent, and we work around them, understanding we need to make a few changes later when decision is reached.

ahdinosaur commented 8 years ago

Question here comes about its semantics, do we want to define rdfs:Class - nrp:Affiliate , which used on person would mean 'this person is an Affiliate (period)' or we want to define it as rdfs:Property - nrp:affiliate which would relate person with another entity, and mark this relation as 'affiliate' (label on directed edge in a graph).

in that specific case, i think "affiliate" is a RelationshipType not an AgentType.

in general we want to define either a AgentType (rdfs:Class) or a RelationshipType (rdfs:Property), depending on what makes the most sense. Open OS is an example user-defined vocabulary in Enspiral that defines AgentTypes (which are more uncommon), i imagine more user-defined vocabularies will define RelationshipTypes.

ahdinosaur commented 8 years ago

While enspiral may start with defining such relations - instances of rdfs:Property in their namespace. They don't sound to me that specific to enspiral and make a lot of sense to include in some commonly shared vocabulary, very generic https://w3id.org/role/ could become one of them, also schema.org, it doesn't matter as long as we recognize them as possibly not enspiral specific concepts...

yes, these aren't specific to Enspiral but for example, Enspiral came up with 'steward' independently of any existing vocabulary and we're trying to seed it to other organizations. i think it's more important to focus on how users can define and share their own vocabularies rather than how we define and share "standard" vocabulary definitions, since the latter is a subset of the former (we are an agent "Value Flows" who wants to share our favorite vocabulary definitions built on top of the general abstract vocabulary).

elf-pavlik commented 8 years ago

yes, these aren't specific to Enspiral but for example, Enspiral came up with 'steward' independently of any existing vocabulary and we're trying to seed it to other organizations.

{
  "@context": [
    "https://w3id.org/valueflows/",
    { "ens": "http://enspiral.org/ns/" }
  ],
  "@id": "ens:steward",
  "rdfs:subPropertyOf": "role:steward",
  "rdfs:label": {
    "en": "has steward (da og enspiral way!)"
  },
  "owl:inverseOf": {
    "rdfs:label": {
      "en": "is steward by (da og enspiral way!)"
    }
  }
}

This way systems which 'understand' very generic role:steward can still get some meaning of this property and degrade in graceful way, while systems who 'understand' more specific specialization ens:steward can fully support it.

Of course each app, and data space can provide (eg. via deployment config) their own overwrites for all the labels in any known vocabulary as they wish, which will take precedence in this particular app or data space. We should also always keep in mind AAA Slogan (Anyone can say anything about anything), this way anyone can augment any information published 'elsewhere' in a way which meets one's own needs.

almereyda commented 4 years ago

We have moved the ValueFlows organization from GitHub to https://lab.allmende.io/valueflows.

This issue has been closed here, and all further discussion on this issue can be done at

https://lab.allmende.io/valueflows/agent/-/issues/44.

If you have not done so, you are very welcome to register at https://lab.allmende.io and join the ValueFlows organization there.

valueflows / agent

concrete, real world examples #44