Meeting minutes
<AndyS> scribe?
<AndyS> and new people intros?
the unstar mapping
enrico: [thoughts on the semantic implications of the unstar mapping]
pchampin: we need to be clear about the purpose of the unstar mapping
Introductions
JeffreyFreeman: we (CleverThis) are a new W3C member, and are mostly here to listen, excited about RDF-star
… We are an Open-Source AI based company
… Interested about the ethics around AI, planning to launch a non-profit on that topic
Hanza: I'm a junior ontologist, with CleverThis. Trying to lear what you guys are doing.
Bilal: I was there in yesterday's meeting, I introduced myself there.
… Based in Morocco. Lead ontologist at CleverThis.
… Interesting in modeling vocabularies and solving modeling issues with RDF-star.
The unstar mapping
tl: I think the unstar mapping is a low hanging fruit, we should do it
… I don't know if we want to unstar the abstract triple terms, but this would need a new vocabulary.
… I did not understand the problems enrico pointed out.
… Reifiers are similar to standard reification, modulo the many-to-many relation.
… I think the use-case is very much aligned with what LPGs do.
niklasl: to answer enrico's questions, about my needs.
… We are using an OWL toolchain. For this, unstar would be sufficient.
… We want the OWL that we already have to preserve atomicity (?)
… It might be frugal to reuse the reification vocabulary, but I see more and more arguments against that.
… I'm fine with new terms if that's deemed clear.
… Using OWL, one could entail standard reification from a specific typed reifier. That's fine from my point of view.
enrico: to pchampin, I believe that unstar is not only syntactic.
<enrico> :a rdf:reifies <<(:b :c :d)>>.
enrico: from a semantics point of view, you have to prove the correctness of the unstar, prove that you get the same result.
<enrico> COMPILES TO (only in simple RDF):
enrico: If we have a reification statement (see above), this compiles to (see below)
<enrico> :a rdf:reifies _:t.
<enrico> _:t rdf*:subject :b.
<enrico> _:t rdf*:predicate :c.
<enrico> _:t rdf*:object :d.
<enrico> [with some proviso]
enrico: there is some proviso. You must map all equal triple terms to the same bnode.
… This is not only a syntactic check, because triple terms using semantically equal terms are also equal.
<enrico> ∀t1,t2,x,y,z. ((t1 rdf*:subject x) ⋀ (t1 rdf*:predicate y) ⋀ (t1 rdf*:object z) ⋀ (t2 rdf*:subject x) ⋀ (t2 rdf*:predicate y) ⋀ (t2 rdf*:object z)) → (t1 owl:sameas t2)
enrico: The implication above should always hold.
… This implication makes things complicated.
… I expect all languages on top of RDF 1.2, esp. OWL, to enforce this.
… If we stick to simple RDF, that's fine.
… If would not suggest to reuse the old reification vocabulary, because people have their own expectations about it.
… I think that the unstar mapping can be used for canonicalization.
pchampin: what do you mean by "being the same" for the graph and the unstarred graph?
enrico: I meant that an implementation using the unstarred graph does the same thing as an implementation using the original graph
tl: the first example you gave above, do you mean to map an occurrence?
… Why do you think it would be dangerous to reuse the old reification vocabulary?
enrico: because the original graph could use this vocabulary, this would mess things up.
<Zakim> tl, you wanted to ask if enricos "∀t1,t2,x,y,z. (...." etc formula refers to abstract triple terms
enrico: by occurrence, do you mean reifier?
tl: yes
enrico: so in my example, the reifier does not play any special role in the unstar mapping.
niklasl: if I get this correctly, this is great from my point of view
… given the constraints you add to these properties (the implication above) it is obvious that we should not reuse the old reification vocabulary.
pchampin: the unstar mapping would never produce duplicate bnode for the same triple, right?
… the problem would only occur when people merge two unstarred graphs
enrico: yes, but I don't even think that's a problem. People will merge RDF 1.2 graphs, not unstarred graphs.
pchampin: not sure I agree with that.
niklasl: you could avoid the problem with some kind of skolemization, I think
… but this could have its own problem, including with canonicalization
<tl> :r rdf:reifies <<( :Alice :buys :Car )>> ;
<tl> rdfstar:subject [ :age 18n ] .
TallTed: note that the "rdf*" is probably not a valid prefix, so we should aboid using it
tl: what would happen with the triples above?
<tl> :r rdf:reifies <<( :Alice :buys :Car )>> ;
<tl> rdf:subject [ :age 18n ] .
enrico: I would not allow people to use the "unstar vocabulary" directly. This should be reserved to the compiler.
<niklasl> Yes.
<AndyS> https://
tl: what about using rdf:subject (see above) then? Or do we need another vocabulary?
niklasl: I don't think that we need another one, nor that we want to model that kind of thing...
… This is bad modelling in my point of view.
tl: it is qualifying Alice in that relation
niklasl: I see that, but I'm pretty sure that rdf:subject would not convey that meaning.
tl: could we define a vocabulary to do that?
<AndyS> :a rdf:reifies <<( _:b :p :o )>> . _:b :age 18 ;
niklasl: I would not do it in the RDF vocabulary.
tl: I think it is in our charter to do that.
<Souri> Would having an Alice avatar work? ==> :Alice18 :age 18 . :r rdf:reifies <<( :Alice18 :buys :Car )>> .
<tl> @souri that would work, but its much more complicated
enrico: if we define an unstar mapping, we need to raise all these issues.
AndyS: our first decision would be whether to define it at all.
<tl> at times I used rdfx:onSubject/onPredicate/onObject in examples. maybe that's clearer
AndyS: We could decide not to do anything, that would be a WG decision.
enrico: it seems to me that if we do it this way ("compilation") it would work for c14n.
<pchampin> +1 enrico
<niklasl> +1
<niklasl> And keep them well-formed, ideally have a key on the spo, etc.
pchampin: I think that beyond c14n, we can provide guidance for people to implement RDF 1.2 full without implementing triple terms
… we should warn them about the issue with merge, but I don't think that we have to do more
gkellogg: I agree with pchampin
… it does not really matter who defines that mapping, but we don't different mappings to be define;
… that's what makes our group the right place to do it.
<niklasl> +1 to gkellogg on it needs to be defined, and on "unstarring" a query too
gkellogg: Unstar for SPARQL queries is also important.
tl: it is such a low hanging fruit that people will do it.
… By defining it for them, we can spare them the mistakes they are likeky to do.
<niklasl> +1 to AndyS
tl: Also to help people use RDF 1.2 graphs on legacy RDF 1.1 implementations.
AndyS: I also think we should do it, and we should also compile base direction (using the JSON-LD approach).
<niklasl> (only *almost*, if the results contained triples encoded in IRI:s ;P )
AndyS: More complicated for SPARQL, hard to convert back to RDF 1.2.
… select result containing triple terms need to be expanded back
pchampin: unstarring to RDF 1.1 makes sense for the purpose of reusing legacy implementations
<tl> reification vocabulary proposal: rdf:termSubject/termPredicate/termObject
<niklasl> Or rdf:tripleSubject , ... tl? (IRIs, bnodes and literals are terms too).
<tl> @niklas not sure...
pchampin: my other point was about unstarring to graph-only implementations (this was raised during TPAC)
… With the current proposal, a graph unstars to a graph, and a dataset unstars to a dataset.
… I can live with that.
AndyS: lets not make our life too hard by solving problems that do not exist.
<niklasl> +1 to AndyS
AndyS: I see traction for the dataset-based unstar, but it creates a risk of graph-name clash
… mapping graphs to graphs is more natural
<AndyS> w3c/
<gb> Issue 114 Un-star operation to support RDF Dataset Canonicalization? (by niklasl) [needs discussion] [discuss-f2f]
pchampin: the name-class risk of my previous approach (see github issue above) was rather low ;
<TallTed> (yes, I think something like rdfx:onSubject/onPredicate/onObject would be clearer and much less likely to be confused with rdf:Subject, etc.)
pchampin: here, people must refrain from using the rdf-star:subject / predicate / objects anywhere in their graph
… in practice not a big problem, but we need to carefully consider this trade-off
enrico: [question to niklasl]
niklasl: there is a connection between how unstar is defined and entailment regimes
… I would like to be able to use the same OWL axioms with RDF 1.2 or unstarred RDF 1.1
<pchampin> for me this is a much harder task!
enrico: I call it a compilation, because this is one-way. We don't need to care about the unicity constraint.
<tl> niklasl re: "Or rdf:tripleSubject , ... tl? (IRIs, bnodes and literals are terms too)." i agree (now, after a little thinking)
enrico: In OWL, the unicity constraints becomes explicit.
niklasl: I'm happy with using OWL as is. I don't want to start a new OWL WG.
tl: on the github issue above, there was a discussion on focusing on the reifiers rather than on the individual triple terms.
… I would prefer to go that way instead of mimicing the triple-terms.
… We got further from the many-to-many design. We have an opportunity to go closer to named graphs.
enrico: I see this development towards graph as appealing, but very dangerous.
<niklasl> I agree with tl that you *can* use the identifier of a reifier as a name for the graphs. Just because there is nothing preventing that. I'm not saying it's necessarily a good idea. It depends.
enrico: You would have named graphs violating the basic principles of graphs, namely the scope of bnodes.
tl: the rdf:reifies property would define the semantics of how I refer to this graph.
… It would define a precise semantics, but only when refering to the graph via rdf:reifies.
<enrico> +1 to niklasl
pchampin: syntactically, named graphs in a dataset are allowed to share bnodes.
… semantically, of course, it is undefined whether those "same" bnodes quantified together or separatedly
<niklasl> Divide by PI to get some idea of how much actual time we have to do the work? :P
AndyS: we need to prioritize, we have a tight schedule, even with the rechartering
gkellogg: I think the unstarring could be left to the maintenance mode
… I think it should be normative, but this does not impact the rest of the spec.
<Souri> IMO, we need to prioritize picking one of these: 1) rdf:reifies only, vs. 2) rdf:reifies + rdf:Reification property class, vs. 3) rdf:reifies + rdfs:states
pchampin: yes, even normative, it could be added as a "new feature" (class 4 change) as we made the decision to allow them, in the spec
… good point gkellogg, this could be defer after we publish the REC
AndyS: I would rather have it as a separate document
tl: are we talking about postponing the graph-based unstar mapping?
gkellogg: we need to prioritize work items, to decide what needs to be done before going to REC, and what can be addressed during maintenance
… I think this one can fall in the 2nd category
niklasl: I think those additional term be added in the RDF vocabulary
… this could be done in the coming months, even without publishing the unstar algorithm now.
AndyS: we could start a wiki page with the terms we are considering adding.
… Coming up with text for their description is going to take some work.
<Zakim> Souri, you wanted to say that picking one of these should be a prioritized: 1) rdf:reifies only, vs. 2) rdf:reifies + rdf:Reification property class, vs. 3) rdf:reifies + rdfs:states
pchampin: discussing the vocabulary is too coupled to discussing the algorithm in my view.
Souri: we need to make a critical decision about whether we are going to use rdf:reifies only, or rdf:reifies + rdf:reificationProperty properties, or rdf:reifies + rdfs:stats.
… This should be a priority item.
enrico: yes, this was the other topic for today :)