– DRAFT –
RDF-star WG Semantics TF

Continuing the discussion on profiles

<niklasl> Opaque edges _without bnodes (to eliminate also the need for skolemization) for the LPG cases....

<TallTed> rdf:edge, another special predicate

<niklasl> So we would support both? In syntax? I don't *like* it, but I can _see_ it...

<niklasl> Use the D-entailment example instead "042"^^xsd:int

<AndyS> D-entailment is little unusual - numbers are "universal"

<niklasl> Yes. Use no uniqueness assumption...

<niklasl> Look at the types in my examples: https://niklasl.github.io/ldtr/demo/?url=../test/data/reifiers-misc-m2m.trig (no Wedding, since we've had that a lot).

<niklasl> .. follow your nose (and if you cannot, the data isn't properly published; or used in "good faith" (ex:ExampleStuff))

<niklasl> LPGs uses ambiguity as their formal semantics (like most humans, I guess)

<niklasl> No uniqueness assumption...

<niklasl> The only "completely described" resources are literals, and triple (terms)...

<niklasl> An exdurant notion of persons come to mind...

<niklasl> owl:sameAs or other entailments (FP, IFP, restrictions, ....)

<niklasl> _:e1 rdf:value "<urn:x-ns:s> <urn:x-ns:p> <urn:x-ns:o>"^^ex:tripleLiteral .

<doerthe> the opacity mainly had a problem with literals

<niklasl> A "TP" would some kind of an implicit property chain from the edge to the (if so defined) entailed rdf:Triple resource that the literal would denote? Pretty hard to comprehend and work with.

<doerthe> The point is, that you still have some syntactical restriction in the transparency case and that I always considered a problem, but I can live with that. I just want that to be clear

<doerthe> so even if :liz :married :richard. and :richard :married :liz. are semantically equivalent, the semantics at the moment do not take care of that (and that is good, this complexity was main main fear for transparency)

<doerthe> can you share the link again, I got disconnected?

<tl> doerthe I accept that there are problems w.r.t. symmetric properties, that example may be too far fetched. but co-denotation - :Liz and :ElizabetTaylor referring to the same person - should be a strong enough argument

<doerthe> basically, the <<..>>-brackets are interpreted as a ternary function symbol, not more and not less. To me, it felt artificial to do that, but I see that ternary functions can be powerful if we want them to.

<ora> "I love you as a brother"

<niklasl> "and also as a friend" two subproperties should be used, *or* an auxiliary reifier of the particular situations

<doerthe> ... if it is all about n-ary relations, then we might want to make lists first-class citizens

<doerthe> instead ;)

<niklasl> That's what I tried to illustrate in my examples -- most of them are "oh, you should have modeled it like that up front" cases!

<niklasl> We need two predicates and two types.

<niklasl> (one is a datatype, one is the class (Triple, or Statement, *really*)

<niklasl> We also have lots of "80% of the data is simple, 20% needs underlying details".

<tl> we could go for an RDF/LPG reasoning regime - completely opaque, Unique Name Assumption, Closed World Assumption etc - that can be applied to a named graph. that way we would give LPG users _everything_ the expect

<enrico> https://github.com/w3c/rdf-star-wg/wiki/RDF%E2%80%90star-semantics:-option-3

<AndyS> <<:e | :s :p :o >> :p 12 . :e :p 23 . vs :e :p 12 . <<:e| :s :p:o>> :p 23 . for { ?s ?p ?o . FILTER(SUBJECT(?s) ...) }

<AndyS> IF there is an explicit declaration, to separate declaration and use, it *may* be possible.

<doerthe> :s :p <<:i\:a :b :c>>. :s2 :p2 :i. I search for SELECT * where {?s ? p <<?i/:a :b :c>>.} what do I get?

<doerthe> (sorry for the / and \ :) )