[
https://issues.apache.org/jira/browse/TINKERPOP-3261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18095033#comment-18095033
]
ASF GitHub Bot commented on TINKERPOP-3261:
-------------------------------------------
spmallette commented on code in PR #3483:
URL: https://github.com/apache/tinkerpop/pull/3483#discussion_r3553034939
##########
docs/src/reference/the-graph.asciidoc:
##########
@@ -91,20 +91,29 @@ WARNING: Features of reference graphs which are used to
connect to remote graphs
graph to which it connects. It reflects the features of instantiated graph
itself, which will likely be quite
different considering that reference graphs will typically be immutable.
+[[optional-data-model-variances]]
+== Optional Data Model Variances
+
+The simplest property graph model consists of vertices and edges, each with a
single label and a set of key/value
+properties. This is the lowest common denominator that every TinkerPop-enabled
graph supports. Beyond that
Review Comment:
Do we want to say that "every TinkerPop-enabled graph supports" this level?
Seems like too strong a statement. Is it a "lowest common denominator" or the
most common widely supported setup consistent with labelled property graph? I
think there's some refinement needed here. good section though. Perhaps
described as "advanced" modelling options?
> Enable multiple label support on vertex with configurable label cardinality
> ---------------------------------------------------------------------------
>
> Key: TINKERPOP-3261
> URL: https://issues.apache.org/jira/browse/TINKERPOP-3261
> Project: TinkerPop
> Issue Type: Task
> Affects Versions: 4.0.0
> Reporter: Yang Xia
> Priority: Major
>
> Vertices are currently limited to a single immutable label assigned at
> creation. This prevents modeling common real-world scenarios where entities
> naturally belong to multiple categories (e.g., a person who is both an
> employee and a manager).
>
> Introduce a configurable LabelCardinality that controls how many labels a
> vertex may have and whether they can be mutated after creation. Three
> proposed modes: ONE (current behavior, default), ONE_OR_MORE (mutable,
> minimum one), ZERO_OR_MORE (fully flexible).
>
> New steps:
>
> - labels() — flatMap step emitting each label as a traverser
> - addLabel(String, String...) — add labels to a vertex
> - dropLabel(String, String...) — remove specific labels
> - dropLabels() — remove all labels
> Edge labels remain at cardinality ONE. The infrastructure would support
> future edge multi-label enablement without wire format changes.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
