* Andrew Hyatt <ahyatt@gmail.com> [2022-11-03 05:39]:
> Yes, this is in theory possible depending on how you use this
> library!
Not only, but it should be possible. Relationship is also subject or
object. I find UUIDs fantastic tool for relationship management. It is
something that spans over specific databases to many other digital
things on the planet. So I have created this one:
CREATE TABLE uuid2uuid (
uuid2uuid_uuid UUID PRIMARY KEY DEFAULT gen_random_uuid(),
uuid2uuid_datecreated TIMESTAMP DEFAULT CURRENT_TIMESTAMP NOT NULL,
uuid2uuid_datemodified TIMESTAMP,
uuid2uuid_usercreated TEXT NOT NULL DEFAULT current_user,
uuid2uuid_usermodified TEXT NOT NULL DEFAULT current_user,
uuid2uuid_uuidobject UUID NOT NULL,
uuid2uuid_uuidpredicate UUID NOT NULL,
uuid2uuid_uuidsubject UUID NOT NULL,
oid2oid_description TEXT
);
> I've seen this done as CVTs (Compound Value Types).
I do not know that abbreviation.
If you look at the table above, you will see UUID created for each
entry. It means again you may relate relationship UUID to other UUID
and how you define values for UUID is left to programmer.
For example ID 3 in the database:
ID 3
First name "Vicente"
Last name (People List Name) "Ramirez"
People type "Individual Person"
UUID "f2832aa3-8cbd-4d2f-87c3-2887c41d22e2"
Thus UUID "f2832aa3-8cbd-4d2f-87c3-2887c41d22e2" may be related to
other UUID "2fc8ebd6-c24e-4a91-aaf9-42970c15866c"
One could say
Entry 7150f343-1c54-43f7-9838-414724b93bda says that:
UUID "f2832aa3-8cbd-4d2f-87c3-2887c41d22e2" is married (predicate) to UUID
"2fc8ebd6-c24e-4a91-aaf9-42970c15866c"
Now we got UUID for marriage: 7150f343-1c54-43f7-9838-414724b93bda and
UUID for child 6d7b0daf-2a6e-4fcc-9b7a-b83208fc4c5f and we can say:
Entry 0e1cdfd9-7248-4c08-8cf8-a66eae51ea3a says that:
UUID "7150f343-1c54-43f7-9838-414724b93bda" are parents (predicate) of
"6d7b0daf-2a6e-4fcc-9b7a-b83208fc4c5f"
It looks not readable, though the programming algorithm is to solve
the representation.
> To take your example,
> (Joe HAS employee status) SINCE 2012-10-28, it'd be something like:
>
> Subject: Joe
> Predicate: /employment/status
> Object: "6988a214-368c-40a2-9e51-8a7f5549de44"
I think that /employment/status as predicate shall be simple
relationship:
Entry d7b270ba-65cb-46ba-9702-34e9bf102c47 says that:
employment (UUID) has status (another UUID)
and then
Entry e65b3519-1009-4812-a15d-151f1627fdd9 says that:
Joe (in reality UUID) has d7b270ba-65cb-46ba-9702-34e9bf102c47
Which would mean Joe has employment status.
> Subject: "6988a214-368c-40a2-9e51-8a7f5549de44"
> Predicate: /employment/start
> Object: "2012-10-28"
That for me would rather be:
Entry 11e7bb1b-ebe0-46c4-8706-53cceeae7b76 says that:
Employment (UUID like c9d17440-d165-49d3-b545-cd0dd0f9f4d6) has Start date
(UUID)
Then
Entry 8186ab12-fbe6-40e5-b266-49d71350eb30 says that:
e65b3519-1009-4812-a15d-151f1627fdd9 (Joe's employment status) is 2022-11-03
(but again as UUID)
With or without UUID, or ID, one shall minimize the types of
predicates, maximize the relationship definition, as that personally
seem to be easier for artificial intelligence programming.
Type shall not be defined strictly in the database, but rather be
defined in triplets.
Entry abac4ea3-c534-42d3-a3e4-921ce99e7c49 says that
Start Date (11e7bb1b-ebe0-46c4-8706-53cceeae7b76) IS Date
(11e7bb1b-ebe0-46c4-8706-53cceeae7b76)
then:
Date (11e7bb1b-ebe0-46c4-8706-53cceeae7b76) is Type
(68ad33a3-c4f1-4781-8123-cefc31ba6de7)
then you can easily get information like "list of types", types may
have its "formats", one can see which information is "Date" or list
employees by date.
Now I am thinking it should be even simpler:
subjectobjects should by something like:
UUID
Value
triplets should be:
UUID with predicate also being UUID relates to UUID
Then
UUID "Predicate"
UUID "Is"
UUID of "Is" relates to UUID of Predicate
That way you get even predicates as objects/subjects
If we use IDs as integers, it may get problematic.
CREATE TABLE objects (
objects_uuid UUID PRIMARY KEY DEFAULT gen_random_uuid(),
objects_datecreated TIMESTAMP DEFAULT CURRENT_TIMESTAMP NOT NULL,
objects_datemodified TIMESTAMP,
objects_usercreated TEXT NOT NULL DEFAULT current_user,
objects_usermodified TEXT NOT NULL DEFAULT current_user,
objects_name TEXT NOT NULL,
objects_description TEXT
);
With those 2 tables like "objects" and "triplets" one should be able
to describe anything, and due to UUIDs, even anything across the
databases, objects need not exist or be referencable in the single
database, they can be anything in that case.
Everything else on upper level remains for programmer to define its
representations, inputs, editing, etc.
--
Jean
Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns
In support of Richard M. Stallman
https://stallmansupport.org/
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4