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

Is there any way to download the slides instead of viewing them in LinkedIn?

peter


On 12/14/23 04:12, Souripriya Das wrote:
> 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://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://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
> 
>

Received on Thursday, 14 December 2023 16:28:45 UTC