Meeting minutes
https://
<Souri> "present" in graph vs. "asserted (to be true)" in graph
LPGs and "asserted" triples
<Souri> (v1) -[e:p]-> (v2) => :e rdf:asserts <<( :v1 :p :v2 )>> .
<Souri> multi-edge=> (v1) -[e:p]-> (v2), (v1) -[e2:p]-> (v2) => :e rdf:asserts <<( :v1 :p :v2 )>> . :e2 rdf:asserts <<( :v1 :p :v2 )>> .
<Souri> +1 to such reasoning not being in RDF
<enrico> :e rdf:asserts <<( :v1 :p :v2 )>>. |= : v1 :p :v2.
<enrico> :a rdfs:subClassOf :b. :b rdfs:subClassOf :c. |= :a rdfs:subClassOf :c.
<Souri> :countryA rdf:asserts <<( :potus45 rdf:type :Villain )>> . :countryB rdf:asserts <<( :potus45 rdf:type :Angel )>> . Automatic inclusion of the asserted triple-terms as triples in the graph could cause issues. We are going into a different scope.
<AndyS> Will rdf:asserts be a sub-property of rdf:reifies? Which makes query easier for the user to ask for all info that refers to a triple via it's triple term.
<gkellogg> +1 rdf:asserts is a sub-property of rdf:reifies which entails the triple term is also assserted in the graph.
<enrico> +1 :a rdfs:subClassOf :b. :b rdfs:subClassOf :c. |= :a rdfs:subClassOf :c.
<enrico> ops forget
<enrico> +1 rdf:asserts is a sub-property of rdf:reifies
<enrico> https://
<thomas> https://
<Souri> My preference is to keep rdf:asserts and rdf:reifies as unrelated properties (instead of having a subproperty relationship). Instead of "upgrading" a triple-term from "reified" to "asserted" (or "downgrading" from "asserted" to "reified"), one can replace an asserted triple-term with a reified one or vice-versa, if needed, using SPARQL
<Souri> DELETE-and-INSERT.
<AndyS> INSERT { ?x rdf:states ?T } WHERE { ?x rdf:reifies ?T . ?s ?p ?o }
<AndyS> Discussion on 2 properties rdf:assert and rdf:reifies or 3 properties rdf:assert, rdf:describes and rdf:reifies
<Souri> I am okay with rdf:states replacing rdf:asserts to avoid confusion with the idea of "present in graph" as assertion.
<Souri> LPG edge with annotation=> (v1) -[e:p {prop=val} ]-> (v2) <==> RDF1.2=> :e rdf:states <<( :v1 :p :v2 )>> . :e :prop :val .
<AndyS> or (syntax wise) :v1 :p :v2 ~:e {| :prop :val |} .
<thomas> i’m trying to make sense of today’s meetings results.
<thomas> is the following a possible consensus (that would need more thinking, to be sure):
<enrico> forall x,y. works-for(x,y) -> emp(x) \and company(y)
<thomas> 1) rdf:states rdfs:subPropertyOf rdf:reifies
<thomas> 2) SPARQL will find rdf:stated triple terms when queried for rdf:reified triple
<thomas> 3) the annotation syntax is mapped to rdf:states, not rdf:reifies
<thomas> 4) any properties that want to more specifically describe without stating will have to be defined outside of RDF
<thomas> 5) actual entailment, e.g. rdf:states _entails_ the triple from the triple term it refers to, is impossible in RDF
<thomas> right?
<Souri> 111 | john | companyA | 100K, 222 | john | companyA | 200K
I don't think this meeting has "results". We've talked about a lot of things, with very sparse notes.
<AndyS> yes to (1) , (2) is not so simple
<Souri> :e111 rdf:states <<( :john :worksFor :A )>> . :e222 rdf:states <<( :john :worksFor :B )>> . :e111 :sal 111K . :e222 :sal 200K .
<AndyS> (3) maybe - it has pros and cons.
<thomas> @AndyS (3) would depend on (2) to happen
<Souri> :e111 rdf:states <<( :john :worksFor :A )>> . :e222 rdf:states <<( :john :worksFor :A )>> . :e111 :sal 111K . :e222 :sal 200K .
<Souri> CORRECTED=> :e111 rdf:states <<( :john :worksFor :A )>> . :e222 rdf:states <<( :john :worksFor :A )>> . :e111 :sal 100K . :e222 :sal 200K .
<AndyS> Quite - that's building an entailment into SPARQL.