Everything is node - Human sample

Hi Team,
Here is my first post !

To get started with myReach, a small example is essential.

Everything is node.

Based on Human (workspace), this is how I understand the use of myReach.





Am I in the right one ?

Thank you in advance for your comments.

Vinamis

Hi! (Also, Welcome!!!)

It is not for me to say whether you are developing a stable and functional framework. I struggle with these questions all of the time too!

I wanted to review the screen shoots to be sure I understand your flow. The first two are the Note nodes you have established in the Human workspace, yes? 3 and 4 show the relationships for the Note nodes within the Human workspace representing/storing the properties of “Maria” and “John”. #5 shows the 2 relationships (John & Maria) that exist to the 2015 Note.

If I have interpreted that correctly, it does make sense. I am not sure that I fully understand how the right column for the individuals is populated. Where do you indicate who each is married to and the Year of birth? Within custom or selected properties that are populated in the creation of each Human note? Are these the labels of the properties you have entered for the Human notes?

Do you require specific notes (nodes? I stumble over identification of elements in my own head.) for the Years (1985, 1990, & 2015)? For convenience of quick selection or some other purpose? Did you create those notes yourself or was it done by myReach? The Brown, Blonde, & Hair color notes/nodes are similarly confusing. Do you need all three? I imagine a relationship is created -by you or myReach? It seems to me that you could just enter a Year of Birth & Hair Color property for each Human and then use filters to drill down. (Based on labels shown -Hair color & Sex- maybe you do but then where/why are the notes -Blonde, Brown, Male, Female- created?)

Which suggests that there may be an alternative strategy. Your Human workspace could include Note Nodes for individuals. Following your example, there would be 2 notes: John & Maria. These could be based on a template that has been modified to include the Hair Color, Sex, & Year of Birth properties, customized to your needs for format and items in list. I wonder if you could just parse out Year of Birth from a standard mm/dd/yyyy (dd/mm/yyyy in Europe, I think) entry?

Maybe my questions and possible alternatives are resulting from my interpretation of display. I hope I am not confusing you. I, too, am a relatively new user and I struggle with these structure questions in my own interpretation. I think it would be (is?) very helpful to talk about work- and data-flows with others. The entanglements (real and in the head) are part of why I (and others like yourself?) seek tools like myReach.

I’m also a person who needs to understand where things have come from. Random node & relationship creation (i.e., ones I don’t understand) can make me very nervous. I hope Sofia, Chris, or others on the team will respond to both of us.

Best, Julie

1 Like

If it was me, I i’d have:
hair.null=false
hair.length=int
hair.color=‘brown’

I just skimmed - as long as you have a base set of props, and they are inheriting into the child entities as expected, that pattern should scale.

1 Like

Hello Julie and Mario and thank you for your comments and questions.

Yes, everything was created manually.
Only Notes and relationships.
Labels added manually on relations.

Here are some additional views.








I am also waiting for additional informed opinions.

A precise definition of terms would be essential to avoid confusion between the usual notions: entity, class, attribute, property, etc. but that should be another post.

Best regards, Vinamis

2 Likes

Vinamis,

I completely agree about term definitions. They are important to establish capacity and set expectations. It is up to us (users) to understand and build appropriate uses for software. We are able to adapt to programmed behaviors, but it helps to know what will happen when actions are taken. For most of us, the volume of data and the complexity of relations is such that mistakes can be very costly or very depressing. In the worst case, both.

Regards, Julie :slight_smile:

P.S. Yes, awaiting “additional informed opinions” is very wise. In the case of myReach, my opinions may overreach my information. I’m still learning!

1 Like

Hi @Vinamis ,

Thanks for your post and thank you @JulieI and @supermario_ai for giving your feedback!

MyReach is fully customizable to meet the workflow that each user needs, that being said there are some pointers that you might find useful and could help you with building your own workflows.

  • A node can be any type of data or knowledge – that being said there are multiple types of nodes, each of which has been optimised for its data type (websites, files, notes, pictures, audios, tags, etc…).

  • A property is a descriptor of a node – essentially provides details. This can be for example the creation date, status, an address, a price, description, date of birth, or whatever you would like. There are more than 18 different types of properties you can choose from.

  • It has come to our attention that many users like you are requesting more tutorials and examples of best practices on how to use myReach – which is why in the next coming weeks we will be releasing more tutorials and an interactive chat where you can ask questions directly to our handbook. In the meantime you might find some useful information in our handbook as to how everything works and the variosu functionalities of myReach.

In your current workflow it appears you have created everything as a note… a more optimal approach would be to create many of those concepts as “Tags” as it would help you differentiate them from actual notes – for example all individuals should be created as Contacts rather than notes.

Without enough context it might be a bit hard to understand your exact use case, but from the information available it would probably be better to create many of those relationships as Properties of the node, for example I would have the following properties on each of the relevant contacts

  • Year of birth (property type : date)
  • Hair color (property type : select)
  • Gender (property type : select)

I would however keep exactly as you have done the relationships between contacts (Married to)

Hope that helps – let me know if you have any further questions

Keep Reaching

Chris

1 Like