Meeting minutes
<niklasl> Are we clear about when we talk about bnode symbols in a graph and when we talk about bnode labels in an RDF source?
<niklasl> CDT: https://
<Souri> Are the two references to _:b1 in the following example denote the same bnode? ==> _:b1 :p1 :o1 . :r1 rdf:annotationOf <<(' _:b1 :p2 :o2 ')>> .
<niklasl> We don't know yet. If completely opaque; then no.
<pchampin> _:b :smurfs :t.
<pchampin> _:c :smurfs :t.
<pchampin> :t rdf:annotationOf <<' :alice :likes _:b '>>.
<AndyS> Add _:c rdfs:label "fred" .
<niklasl> :t ex:ref _:b . # ?
<enrico> I agree that the current semantics of opaque triple terms leads to this confusion.
<enrico> So, we should conclude that we need that bnodes are transparent within opaque triple terms
<niklasl> +1 to TallTed!
<enrico> +1 to TallTed!
<Souri> Would this set of annotations constitute a two-edge multi-edge (set of two parallel edges)? => :r1 rdf:annotationOf <<' _:b1 :p :o '>> . :r2 rdf:annotationOf <<' _:b1 :p :o '>> .
<AndyS> Yes (I hope!) - old speak "two occurrences, two uses of the concept of the triple _:b1 :p :o."
<Souri> I hope so too because that is the only way we can have multi-edge where parallel edges can use blank node(s) as subject and/or object.
<niklasl> ... require triple literals, when fully written out, to use skolemized forms?
<TallTed> quoting is different from paraphrasing
<pchampin> but then if they used bnodes, you can't possibly use the same "word" that they used
<Souri> Just to confirm: Can this be used to represent a path from alice to bob with annotated edges? => :r1 rdf:annotationOf <<' :alice :knows _:b '>> . :r2 rdf:annotationOf <<' _:b :knows :bob '>> . :r1 :linkNum 1 ; :cost 100 . :r2 :linkNum 2 ; :cost 200 .
<AndyS> souri - not quite sure what your asking here - add yourself to queue??
<pfps> When did opaque triple terms even get into the "requirements"?
<TallTed> Need to be explicit about what is meant by "opaque triple term" if we're going to talk about whether they're a requirement.
<AndyS> Hard opaque and soft opaque
<tl> @pfps to provide a not-many-to-many option to AWS
<pchampin> @pfps and https://
<AndyS> Need to be careful about numbers of UCs because we have also said "requirement X is equivalent UC Y" and not gone further.
<niklasl> +1 to not solve philosophical permathreads
<Zakim> TallTed, you wanted to remind that we haven't really built Use Cases & Requirements, so we still cannot evaluate well whether any proposal satisfies more or fewer requirements (and which differ) than any other proposal
<AndyS> Yes to -- "quote what they said" and "talk about what they said"
<tl> +1 to graphs...
<Souri> Just to confirm: Can this be used to represent a path from alice to bob with annotated edges? => :r1 rdf:annotationOf <<' :alice :knows _:b '>> . :r2 rdf:annotationOf <<' _:b :knows :bob '>> . :r1 :linkNum 1 ; :cost 100 . :r2 :linkNum 2 ; :cost 200 .
<pfps> https://
<AndyS> One triple at a time - isn't this because semantics/entailment in RDF works on triples?
<TallTed> _:b cannot be *understood* to denote the same node in both quoted triples, *however* just as any two blanknode references *could* denote the same node, those *could* denote the same
<tl> @AndyS it's possible to define that an annotation on a graph annotates each triple in the graph (forEach). that IMO solves that issue
<niklasl> But with these opaque, the fact that _:b owl:sameAs _:b .doesn't help, nor anything else?
<AndyS> Yes it can depending on the design. Parser wise it is the same object -- this is "below" denotation. The abstract graph has one bnode term.
<AndyS> ... then there is interpretation.
<AndyS> <<??>> :addToGraph "Tuesday" . <<??>> :factHappened "1850"^^gYear .
<pfps> In opaque contexts, one could arrange things so that the denotation of IRIs, literals, and blank nodes are themselves.
<enrico> pfps: yes, that' would be my "standard name assumption" I mention before.
<pfps> In some sense, this is the natural denotation in opaque contexts. But there is a lot of philosophical discussion on exactly what is the meaning of identifiers in various opqaquey contexts.
<AndyS> Niklasl - I 'm confused by your wiki page that says its a proposal yet you said it's an exploration.
<niklasl> AndyS - It's a proposal, based on Enrico's proposed baseline. But I'm not sure it works (it has issues).
<Souri> Thinking from a user point of view, my feeling is that a type of opacity that allows sharing of terms among opaque triple-terms would be useful, and simpler to understand, in practice. (The opacity of course has to still have many-to-one restriction by not allowing RDF entailment based on an opaque triple-term.)
<AndyS> https://