Meeting minutes
going back to use case: is there any use case that needs opacity?
<enrico> https://
pfps: Uses cases - opacity needed only for the delta use case
<enrico> pfps: the only use case requiring opacity is the commit-delta
pfps: but that also needs blank node identity (exactly the same bnode, i.e. same system implementation object)
<niklasl> I agree with that assessment.
<enrico> https://
<pfps> What I proposed was a fundamentally different way to change RDF graphs, instead of adding a new kind of node to handle embedded triples it adds an optional triple to the existing nodes.
<pchampin> just to be sure: we are talking about this proposal, right? https://
<niklasl> Yes.
<pfps> In some strong sense, this is a "cleaner" way of handling standard RDF reificiation. Think of pulling the three reification triples into one node, with a subject, predicate, and object plus an IRI or blank node. You should be able to see the correspondence between this and the reification node for standard RDF reification plus the values for rdf:subject, rdf:predicate, and rdf:object.
<pfps> If you are thinking in RDF/XML terms, instead of using the rdf:ID as a new node and three triples just create one of these new kinds of nodes with rdf:ID and the three values.
you can use the id without the three values
<pfps> Things aren't quite this simple, as you probably need to be able have multiple triples on one node to allow for the id to be used multiple times. With standard reification (and rdf:ID) you just get a standard RDF reification potentially with multiple subjects, predicates, or objects, but with a unitary solution you have to allow something different.
<TallTed> ":a :b :c"^^rdf:triple_term
<niklasl> rdf:reifies would be special just like rdf:type, no more no less
<doerthe> I also don't get why we need a syntactic restriction
<niklasl> The same rationale as for not allowing literals as subjects.
<doerthe> isSourceOf
<doerthe> but what do we win?
<niklasl> "Niklas" :isNameOf <niklas> .
<Zakim> pchampin, you wanted to ask enrico to develop what people would have to ignore in triple terms?
<pchampin> what about "foo"^^ex:superman vs. "foo"^^ex:clark ??
<niklasl> By that logic, shouldn't literals in RDF always be sugar for `[ rdf:realValue BOXED-RAW-LITERAL ]` ?
<pchampin> 12: it is even, it is not prime, it is positive
<niklasl> 12 rdf:type xsd:integer .
<pchampin> you broke the entire universe only for people who chose to believe you :)
<doerthe> I still don't see the problem what is the exact poblem. What could I do?
<doerthe> I would be happier with that
<niklasl> I would not. That's for the generalized syntax.
<tl> @niklas i'm not too religious about the generalized question
<niklasl> I have no *objection* to discourage use of triple terms for other things than rdf:reifies. To try to shift angle, I *could* see that as an entailment from Peter's proposal. I just don't see how that would be simpler.
<Souri> Could someone say, in gist, what is: {restrictions for well-formed} MINUS { triple-term in object position only and only when rdf:reifies is the predicate }?
<niklasl> I'm surprised that we've arrived at the simpler baseline and then we're not happy still.
+1 to pchampin/W3C-hat-on
<Zakim> pchampin, you wanted to emphasize, W3C hat on, that we need to find a solution with which everyone can live with, not something that satisfies entirely everyone
<pfps> +1 to pchampin - these are good reasons to be leery of the triple-in-node change
<pchampin> ok :)
https://
<niklasl> Well, :r rdf:reifies <<(:r :r :r )>>.is "OK" (albeit.. well...)
<enrico> But, Niklas, this can happen also for lists...
yes-: r is a name for an object and it's not nested/containment which would be problematic.
<niklasl> "OK" like `:r rdf:type 12 .`
<niklasl> Yes, it's too loose...
<enrico> data structures should be "well founded" (aka finite and non circular)
<pchampin> do "normal users" read N-Triples ? :->
<niklasl> :anything rdf:reifies <<( :anything :anything :anything )>>. *shrug*
<niklasl> pchampin Do normal users intersect with AWK users? Then yes. ;)
<doerthe> (I will be away for a moment)
Jena has several output forms for specific formatting and appearance of Turtle. It only needs one reader though.
<doerthe> (back)
<doerthe> what does blank node as type mean?
<pchampin> "reifies" is the product of consensus: nobody loves it, but everybody (I think) said they could live with it :)
<niklasl> doerthe <x> a [ rdfs:label "Heffalump" ] .
<niklasl> Library data, alas, is full of [ rdf:value "X123" ; a [ rdfs:label "X-System-DatabaseID" ] ].
<Zakim> AndyS, you wanted to ask about subproperties
<niklasl> pchampin, not exactly as horrible, but on a slipperly slope towards those, yes
I can accept the minimal baseline and feel that we have gone as far as we can by discussion only. We need text (and proposed diffs to text) + start the companion note.
<enrico> +1 AndyS
<tl> I would certainly +1 the functionality of the minimal baseline as sufficient. as I tried to explain I think it could be streamlined even more. I am worried that IMO it still doesn't define properly what "reifies" actually means (or maybe I don't get it but then I'd like an explanation
<Souri> (before my computer died I was trying to write this) I am hoping for a simple/restricted N-Triple syntax that allows=> :r1 | :s :p : o . =(which maps to)=> :r1 rdf:reifies <<( :s :p :o )>> .
<doerthe> @niklasl can you post a link to the mail you want us to re-read? Then I answer to that directly (I am lost in our e-mail discussions :D )
<pchampin> Souri: what about using a "simplified Turtle" instead (e.g. without "," or ";"), rather than making N-Triples more "magic"?
<niklasl> doerthe it's https://
<doerthe> thank you :)
<niklasl> I agree on that concern.
<Souri> Pierre-Antoine, let me think a bit about such a "simplified Turtle" idea.
<niklasl> doerthe here is a related example of the "power of OWL" https://
<Souri> Standalone occurrence in Turtle may work (I think Andy mentioned this one of his earlier emails), if it supports: :r1 | :s :p : o . (or, at least << :r1 | :s :p : o >> .)
<doerthe> thinking about syntactic restrictions, we can still do (<<:s :p :o>>) :isSubjectListOf (<<:s :p :o>>). (only playing around thinking about what can and cannot be done), but not <<:s :p :o>> a rdfs:Resource.
<tl> @dörthe :isSubjectListOf - what vocab is that?
<niklasl> Yes; specifically that would be (_:r1) :isSubjectOf (:r2). _:r1 rdf:reifies <<( :s :p :o )>> . _:r2 rdf:reifies <<( :s :p :o )>>.
<doerthe> just an invented predicate, it does not matter, it was more about the construct
<tl> ok
<niklasl> (itself shorthand of those two distinct list (bnode-identified))
I'd like to consider standalone declarations Separating declare and use makes writing programmatic data generation easier (which means less error prone!). c.f. (1 2 3 ) -illegal in Turtle but OK in N3 ( ?? ) Turtle does allow [ :p 123 ] .
<pchampin> https://
<gb> Issue 28 not found
<enrico> +1 AndyS
<gkellogg> +1 AndyS
<pchampin> +1 AndyS
<Zakim> tl, you wanted to quickly ask for comment on "unasserted assertions" (as we're approaching the end)
<niklasl> +1 to Andy
<Souri> +1
<tl> +1 to andy
<TallTed> PROPOSAL: bring https://
PROPOSAL: Bring https://
<pchampin> +1
<gkellogg> +1
<niklasl> +1
+1
<TallTed> +1
<Souri> +1
<doerthe> +0.9 (but I will also read once agaon, to make it 1)
<doerthe> again, I meant
RESOLUTION: Bring https://
<doerthe> comes back to rdf:instantiates and rdf:reifies
<doerthe> as rdf-star entailment
<gkellogg> w3c/
<gb> Pull Request 51 Grammar updates for triple terms and occurrences. (by gkellogg) [spec:substantive]
<tl> thanks!
<doerthe> I also have to leave, Bye