search

valueflows / forum.valueflo.ws

forum.valueflo.ws has moved to https://lab.allmende.io/valueflows/forum-valueflo-ws
3 stars 1 forks source link

Relation(ship) #24

Closed elf-pavlik closed 4 years ago

elf-pavlik commented 9 years ago

Since all components of this vocab will work with relationships, I see benefit with defining their generic form on this level and crating more specific ones in separate repositories as needed.

Use cases:

See also:

Elsewhere:

WORK IN PROGRESS

(currently reusing diagrams from here)

Direct relation

direct relation

Qualified relation (using same property in both directions)

relationship

inverse/reverse

relationship reverse

based on Reification

reification

Proposals

QualifiedRelation

bhaugen commented 9 years ago

@elf-pavlik thanks, useful, to be referenced often.

fosterlynn commented 9 years ago

@elf-pavlik very helpful to gather these in one place, I know you feel like you are repeating yourself! I think your teachings are slowly taking hold, though. :smile:

I have concerns, or maybe hesitations is a better word, about over-generalizing what we are doing though. Using the general name, really the pattern name, doesn't say anything about the domain. I think we need to describe the domain so that people understand at that functional level. We can refer to the pattern class in the doc, or even formally with some sort of subclassing, that might be helpful.

(This is discussion in process, not a proposal.)

fosterlynn commented 9 years ago

For example, instead of

vf:property instead of vf:relationship (from valueflows/agent#46 )

I would go in this direction

vf:agentRelationship instead of vf:relationship

and define the constraints in terms of domain: and range:.

elf-pavlik commented 9 years ago

@fosterlynn could you please point us to example where you need agent specific definitions? I already started adding examples of Agent <-> Resource relationships to have a common pattern that handles at least those two cases. We can soon test it against examples of Resource <-> Resource relationships.

I believe that at some point we will need to start adding those specializations but would prefer that we drive it by needing them to add concrete real world examples to one of the repositories here.

fosterlynn commented 9 years ago

@elf-pavlik It's hard to define real world examples in code without the vocab being stable, and I'm not so fast at it either. :smile:

Also I don't see why not to define as specifically as we agree is useful right now, I don't want to go back later if we have an understanding now. And I think we do, from working in depth with networks through our software, and in much less depth with networks using other or no software. And you probably have some too. (I do btw agree with your general premise, we can only use the understanding we have in real examples.)

I'd like to discuss and work out the general level of abstraction we want to be at. If we need a separate issue, we can go there, but relationship is a great example to work with. And understanding we we need to meet in the middle, you immersed in LOD and its data structures, me (and Bob and others) immersed in the functional domain, me with conceptual modeling background, only codes when has to. :smile:

Examples from real world, don't worry about the naming or formatting:

Here is the general thinking.

It is a matter of what is the vocab for and who uses it. The examples above use the same general LOD pattern, it is true. And that is useful for understanding of developers. They have very different meanings though, and that is useful for users, developers, ontologists, everyone. Many vocabs are actually created for a different pattern level, even ActivityStreams is more about how the data flows in computers, and supports any collection of activity feed, like through rss. I think ValueFlows is more about representing what is happening on the ground in networks of people and less about what is happening in networks of computers.

Both perspectives are useful of course. But I think where we need to go with Valueflows is nudged more towards the domain understanding, that is the real contribution of this vocab.

Your thoughts?

elf-pavlik commented 9 years ago

Daniel (Agent, Person) isAffiliateOf (agentRelationship) Sensorica (Agent, Network) Daniel (Agent, Person) isCertifiedTechnicianFor (agentResourceRelationship) this3dFDM3000Printer (EconomicResource) Sensorica (Agent, Network) isCustodianOf (agentResourceRelationship) this3dFDM3000Printer (EconomicResource)

I like it @fosterlynn ! Just added to description of this issue link to https://github.com/valueflows/agent/blob/master/use-cases/resource-agent-relationships.md

If you really see need to start clearly specializing different types of relationships now, let's simply focus on that! (I guess you may think already about filtering stuff for select boxes or auto complete inputs...) In my case I didn't have problem with just using for now generic role:maintainer to relate

Could you in similar way add .jsonld example files (even hand made) for the cases which you just listed?

@bhaugen

Daniel (Agent, Person) isCertifiedTechnicianFor (agentResourceRelationship) this3dFDM3000Printer (EconomicResource)

I would imagine having certifications for any instance (EconomicResource?) of a printer from the same model (EconomicResourceType?) Does case above states that Daniel takes role of a kind of... technician/maintainer(?) for a particular schema:IndividualProduct since he has appropriate certification (proven skill claim) for general schema:ProductModel? We could link to this certification from qualified version of that technician/maintainer relationship.

@fosterlynn do you also use isUncertifiedTechnicianFor? or isTechnicianFor? If so, how do they differ from suggested isCertifiedTechnicianFor?

Daniel (Agent, Person) isAffiliateOf (agentRelationship) Sensorica (Agent, Network)

could we capture in agent repo how we see Network different from Group? (maybe in Agent.md file for now?)

bhaugen commented 9 years ago

@elf-pavlik I think the answer to all of your questions about Daniel's certification is probably yes. But whether he acts as a technician or maintainer might be a role or might be just an input to a process of making some parts on the printer as a technician or maintaining the printer as a maintainer.

But I think the certification itself probably ties into that LOD vocab you mentioned awhile ago about credentials. Just says he is certified to be a technician, not that he actually does it. That would be an EconomicEvent (or ValueFlow, or whatever we are calling it today), most likely an input to a Process. But the access rules for the printer might say you can't use it unless you are certified or have somebody who is certified to supervise your work.

fosterlynn commented 9 years ago

I would imagine having certifications for any instance (EconomicResource?) of a printer from the same model (EconomicResourceType?)

@elf-pavlik very good, you are exactly right :exclamation: In Sensorica (where the example came from), it hasn't mattered because they don't have more than one of any equipment expensive to need people to be correctly trained in it's use. So we have not needed to support Agent - ResourceType relationships. So the example is cheating a bit. I think for the vocab, we would want to support both, when we get there. And use the example properly.

@fosterlynn do you also use isUncertifiedTechnicianFor? or isTechnicianFor? If so, how do they differ from suggested isCertifiedTechnicianFor?

They have not had a need for those distinctions. Actually, I added the Certified part into the label, because I wanted it to clearly say that this is a role assigned before use, not something that can be derived from economic events. They use isTechnicianFor, or something similar, I'd have to look it up.

Just so you picture it, this is how these things happen: They spend a lot of time community funding for a good 3d printer, finally get enough money, order and receive it, with great excitement. They realize, hey we don't want just anyone running the printer, it was really expensive. So they quickly throw in an agent - resource relationship, and define in their access rules for the resource that only someone who has that relationship can run the printer. Then they start experimenting with it, they spend a lot of time on that. They don't spend more than 15 seconds thinking about what they call the relationship.

And, maybe Bob and I see what is happening, maybe we don't, we're not there. So nobody who is interested in vocabulary is actually creating this stuff. Or more accurately, they are interested in vocabulary, but from the perspective of what communicates best in their network situation.

At one point, Sensorica was trying to get a space to house several open hardware organizations, which unfortunately failed. But if it had worked, they wanted a resource sharing app developed, and would develop vocabulary useful within that space, again pretty specific, one space in Montreal, but a step more generalized than just one network. And so it will happen, over time.

fosterlynn commented 9 years ago

Another example: Sensorica used to call members "member". They changed it to "affiliate". It is certainly what most people would consider membership, but to them it is important to create the network level vocabulary that expresses the nuances they want to express. So "affiliate" is slightly more distant than "member", implies something subtle around P2P concepts to them. So I want to say to them, discuss it among yourselves, and go for it!

elf-pavlik commented 9 years ago

I would like to suggest using this basic graph diagram template

template

And start with simplest possible definition of relationship between two entities e.g.

elf-h4p

elf-vf

Later we can see what kind of additional information we would like to include and possibly reuse QualifiedRelation based on Reification approach. Even further we can start specializing further but I see benefit in making it an iterative process and keeping track of why we see need to add more constructs.

fosterlynn commented 9 years ago

@elf-pavlik said: If you really see need to start clearly specializing different types of relationships now, let's simply focus on that! (I guess you may think already about filtering stuff for select boxes or auto complete inputs...)

I really do! So cool.

ahdinosaur commented 9 years ago

@fosterlynn said:

Just so you picture it, this is how these things happen: They spend a lot of time community funding for a good 3d printer, finally get enough money, order and receive it, with great excitement. They realize, hey we don't want just anyone running the printer, it was really expensive. So they quickly throw in an agent - resource relationship, and define in their access rules for the resource that only someone who has that relationship can run the printer. Then they start experimenting with it, they spend a lot of time on that. They don't spend more than 15 seconds thinking about what they call the relationship.

And, maybe Bob and I see what is happening, maybe we don't, we're not there. So nobody who is interested in vocabulary is actually creating this stuff. Or more accurately, they are interested in vocabulary, but from the perspective of what communicates best in their network situation.

At one point, Sensorica was trying to get a space to house several open hardware organizations, which unfortunately failed. But if it had worked, they wanted a resource sharing app developed, and would develop vocabulary useful within that space, again pretty specific, one space in Montreal, but a step more generalized than just one network. And so it will happen, over time.

Another example: Sensorica used to call members "member". They changed it to "affiliate". It is certainly what most people would consider membership, but to them it is important to create the network level vocabulary that expresses the nuances they want to express. So "affiliate" is slightly more distant than "member", implies something subtle around P2P concepts to them. So I want to say to them, discuss it among yourselves, and go for it!

really love these comments, i feel it captures the importance of local > global vocabulary and why we should focus on building an abstract vocabulary that local networks can use to define local vocabularies rather than us focus on defining a global vocabulary. am keen to bring these in to our use-cases/ directory.

ahdinosaur commented 9 years ago

moved the comments into valueflows/agent/use-cases: https://github.com/valueflows/agent/commit/499a47c24c5e39c029daa26dfc10d865d16c59b6 and https://github.com/valueflows/agent/commit/6b469dca12d77aa1e9f11ea898cb091ab738461d

ahdinosaur commented 9 years ago

Later we can see what kind of additional information we would like to include and possibly reuse QualifiedRelation based on Reification approach.

from our previous vocab design, i reckon we want to include the additional Relationship object properties of context, startTime, and endTime.

elf-pavlik commented 9 years ago

from our previous vocab design, i reckon we want to include the additional Relationship object properties of context, startTime, and endTime.

I see no problem with that, so far they didn't appear in any example which suggests that no one needed them so far :wink:

For startTime and endTime, one can join a group as member, then leave it after some time, then join it again, and leave it again... We may need to find a way to have 'persistent' relationship between two entities which links to a log of relevant interactions (~ has stream of activities)

elf-pavlik commented 9 years ago

Daniel (Agent, Person) isCertifiedTechnicianFor (agentResourceRelationship) this3dFDM3000Printer (EconomicResource)

@fosterlynn in context of #52 do you consider defining both specializations agentResrouceRelationship and resourceAgentRelationship ?

fosterlynn commented 9 years ago

@fosterlynn in context of #52 do you consider defining both specializations agentResrouceRelationship and resourceAgentRelationship ?

@elf-pavlik I hadn't thought about it that way. But let's see what we come to in the directions of agent relationships discussions and see if we can apply it here. It has some similarities and some differences.

ahdinosaur commented 9 years ago

For startTime and endTime, one can join a group as member, then leave it after some time, then join it again, and leave it again... We may need to find a way to have 'persistent' relationship between two entities which links to a log of relevant interactions (~ has stream of activities)

yes, keen to model around append-only logs of interactions (~stream of activities) instead of mutable objects, but that means significant changes in how we represent our data, i.e. no more 'persistent' relationship objects, instead we have separate objects to invite to relationship, accept invitation, leave relationship, modify relationship, accept relationship modifications, etc. which i think is a great route, but i'm curious what others think.

fosterlynn commented 9 years ago

separate objects to invite to relationship, accept invitation, leave relationship, modify relationship, accept relationship modifications, etc. which i think is a great route, but i'm curious what others think.

@ahdinosaur I think it is asking too much to have to reason over some quantity of activities or events to figure out if an agent relates to another agent, although it might be more "correct" in some sense. NRP doesn't even have the dates, we just have a state. It's also a matter of what data people care about enough to record. If some people do record all those interactions, then they do care, and I hope it can be represented with somebody else's vocabulary. :) (Or we can add it to ours later of course.) But I think most people don't care for what we are trying to do, which is use agent relationships to visualize and follow the graph, and to constrain choices in apps.

Re. startDate and endDate, I am fine with including them or not, at this stage. We could wait and add them as soon as someone needs them. In the NRP feed, I just selected for "active" relationships for now. Or not.... see edit below.

Edit:

For startTime and endTime, one can join a group as member, then leave it after some time, then join it again, and leave it again...

Edit: Actually, to @elf-pavlik 's point, maybe best to just leave the dates off for now, not introduce something that will cause problems for someone.

fosterlynn commented 9 years ago

@elf-pavlik @ahdinosaur On the other hand, I think we do need context now. Otherwise you can't tell if Mikey stewards Simon in Craftworks, or in life in general. :)

ahdinosaur commented 9 years ago

@fosterlynn makes sense, i'm fine with our vocabulary for now being the "computed view" as opposed to immutable activities (what do i mean by that?). there's user value in immutable activities, since then you can implement time travel (imagine a slider at the bottom to scroll through time) and better auditing (every update is a recorded activity) as many folks want, but i'm happy to do those as experiments outside of the vocab before we take on too much scope here.

agreed that context is necessary, Holodex depends on it for exactly the example you mention.

bhaugen commented 9 years ago

This is so far from a requirement that I hesitate to even mention it, but if everything was in version control, we wouldn't worry about all those past changes...

ahdinosaur commented 9 years ago

This is so far from a requirement that I hesitate to even mention it, but if everything was in version control, we wouldn't worry about all those past changes...

if i understand you correctly, version control is basically what i'm suggesting with append-only immutable data logs (e.g. git is an append-only log of snapshots of files and directories). but yeah, i don't think we should at the moment focus on that being a requirement here, in the best case it can be solved at a data layer underneath our vocab via something like secure-scuttlebutt (ssb).

elf-pavlik commented 9 years ago

yes, keen to model around append-only logs of interactions (~stream of activities) instead of mutable objects, but that means significant changes in how we represent our data, i.e. no more 'persistent' relationship objects, instead we have separate objects to invite to relationship, accept invitation, leave relationship, modify relationship, accept relationship modifications, etc. which i think is a great route, but i'm curious what others think.

I don't see it as either-or choice! I really like in modeling data as graphs, that one can choose to draw some additional edges between nodes to make traversals and pattern matching easier. I would still prefer to keep our work focused around systematically adding more and extending existing .jsonld examples and not trying to run to much ahead of ourselves...

On the other hand, I think we do need context now. Otherwise you can't tell if Mikey stewards Simon in Craftworks, or in life in general. :)

agreed that context is necessary, Holodex depends on it for exactly the example you mention.

looks like we only miss https://github.com/valueflows/agent/tree/master/examples/simon.jsonld and small addition to mikey.jsonld, qualified versions of such relation could go in both of them (by switching to "@graph": [] https://github.com/valueflows/agent/issues/7 or for now just putting it in something like enspiral.jsonld (also using "@graph": []. We will need to iterate on how we manage those files with examples anyways, so I no problem with putting things for now where we think they belong... Let's also always make sure to check examples in JSON-LD playground, looking at Compacted and Extended tabs!

elf-pavlik commented 9 years ago

from https://github.com/valueflows/process/pull/4

first attempt at drawing a graph, for now with direct relations(hips) (all qualified one collapsed)

BusTrip (collapsed)

now also graph with reified relations, this way we can use them as qualified relations

BusTrip (full)

please notice that instances of rdf:Property usually get used as labels for edges but sometimes as nodes (object of vf:relationship)

ahdinosaur commented 9 years ago

This is so far from a requirement that I hesitate to even mention it, but if everything was in version control, we wouldn't worry about all those past changes...

ahhh, late last night i had an idea: what if we embraced git as our database, in a similar style to linked-data-creator-api, enspiral-data, etc, so we did have proper version control right now without having to bake it into our vocab or commit to anything too experimental. this is off-topic though, we should move this convo somewhere else, sorry.

ahdinosaur commented 9 years ago

@elf-pavlik made you a better example for Enspiral: https://github.com/valueflows/agent/pull/48.

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/forum-valueflo-ws/-/issues/24.

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