Re: [External] : labelled property graphs vs -star extension of RDFn vs -star extension of named graphs

Hi Thomas,

> I’m still not convinced by the way you name statements. Users that don’t think about the often not so obvious differentiation between type and token will probably annotate a statement via its autogenerated name, which is a function of SPOG, ergo referring to the type per graph. It seems also that this is what you want to be the default. Do you gain anything by making the auto:name a function of (and by extension a reference to) the type itself? Is this an optimization? Do you not expect the multi-edge case to occur very often?
Why not hand out only token identifiers (auto-generated or custom) from the get-go? How often do you expect users to actually want to annotate the type (and not just provide the first and expectedly only annotation on a token of that type)? What if users forget to check if other annotations to the statement already exist? I assume that there will always be a strong inclination to use the already existing auto:name, and that from the second annotation on it will put the soudnness of the new annotation and the pre-existing annotation(s) at risk.

Thanks for this question. I have posted slides for an extended (14-DEC-2023) version of RDFn [1] just now that accommodates "type" triples as well as "token" triples. I was somewhat influenced by your suggestion  "Why not hand out only token identifiers (auto-generated or custom) from the get-go?". Please take a look when you get a chance and let me know if this extended version resolves some of the potential issues you had identified.

> In the new slidedeck I noticed the first time that multiple statements, spread over different graphs, can have the same name. Is that new or did I just overlook it before? It seems like that would extend the expressivity of RDFn quite a bit. The next question would be if one statement can also have multiple names?

I revived this idea (from Spring 2020) after seeing the interest in supporting graph terms.

> One last question: why do the names have to come from specific namespaces? Have you considered using blank nodes?

It makes it easier to detect incorrect use of a tName (e.g., as a graph name or predicate). It can also make it simpler to enforce referential opacity, when necessary, by preventing inference that causes substitution of a tName (used as subject or object) with another tName inferred to be owl:sameAs of.

Thanks,
Souri.

[1] https://www.linkedin.com/posts/souripriya-souri-das-ph-d-48801911_rdfn-rdf-extension-for-unasserted-and-named-activity-7140987047795744768-iqi7?utm_source=share&utm_medium=member_desktop
[https://static.licdn.com/aero-v1/sc/h/c45fy346jw096z9pbphyyhdz7]<https://www.linkedin.com/posts/souripriya-souri-das-ph-d-48801911_rdfn-rdf-extension-for-unasserted-and-named-activity-7140987047795744768-iqi7?utm_source=share&utm_medium=member_desktop>
Souripriya (Souri) Das, Ph.D. on LinkedIn: RDFn: RDF Extension for Unasserted and Named Triples<https://www.linkedin.com/posts/souripriya-souri-das-ph-d-48801911_rdfn-rdf-extension-for-unasserted-and-named-activity-7140987047795744768-iqi7?utm_source=share&utm_medium=member_desktop>
RDFn: A Backward-Compatible RDF Extension for Unasserted and Named Triples (14-DEC-2023 version). These slides outline an extended version of RDFn, compared to…
www.linkedin.com