Meeting minutes
ora: before we start,
… Adrian and I gave a presentation last week about RDF 1.2 at the Knowledge Graph Conference
… the talk was very well attended, people were forced to listen from the hallway
<ora> https://
ora: link to our slides above
naming RDF 1.2 without triple terms 1
pfps: it appears that it has already been decided, and this is our next agenda item.
… there is an official resolution I guess
https://
<niklasl> +1
Define RDF 1.2 Basic profile 2
<pchampin> s|subtopic: https://
<AndyS> Summary -- w3c/
<gb> Issue 70 Define RDF 1.2 Basic profile (by gkellogg) [needs discussion] [spec:enhancement]
ora: AndyS, you have summarized in the issue thread what RDF 1.2 Basic is
… what is the status of rdf:XMLLiteral, rdf:HTML and rdf:JSON in this?
<pfps> The only change for rdf:XMLLiteral and rdf:HTML is that the documents that they pointed to are now recommendations.
<pfps> I don't think that any other change is needed.
<pfps> This means that they are part of RDF, but implementations don't need to include them.
<pfps> rdf:JSON could end up wth the same status.
niklasl: I have been wonder about the relationship between the RDF 1.2 basic profile and the version tags
… not sure we all have the same notion about what the basic profile is for
<pfps> THere is an editorial question - should the description be moved from Concepts to Schema?
niklasl: is it only about specifying what syntaxes are supporting?
… or is it a version of RDF which has no special meaning for propositions? (as defined in semantics)
pchampin: I believe the profile represents a subset of the abstract syntax, which reflects the concrete syntaxes.
… AndyS's summary goes a bit beyond this, but the point is that it represents a syntax without triple terms.
… I think we need to update the Conformance section; arguably, the class and the profile could be separate things, but I think they should be the same thing.
ora: if people in this group are confused, then other people will be even more, and we don't want that
<pfps> +1 to using the same "tag"
ora: we need to make this very straightforwad to understand, to avoid losing our audience
<Dominik_T> +1 to using the same tag too
AndyS: the semantics is not different. There is nothing in the Semantics document that distinguishes between the profiles.
… I could have been clearer in the summary.
<pfps> +1 to RDF 1.2 Basic is just a syntactic limitation - the semantics is the same
enrico: a warning: if we take this definition of the fragment,
… if I have a rdf:reifies b, b becomes an instance of rdfs:Proposition
<pchampin> agreed, and I don't see this as a problem
<pfps> I'm OK with the entailment of rdf(s?):Proposition happening.
enrico: and rdfs:Proposition is an RDF 1.2 specific feature
niklasl: enrico's point covers the strongest part of my concern
… the "unstar" or "classicize" algorithm is used to remove triple terms;
… it may look as redundant with the basic profile
… same for the version markers;
… my understanding was that their role was to signal "my parser can not understand anything beyond 1.1"
ora: are you implying that the profile should not exist;
… instead, people may simply want to stick to RDF 1.1
AZ: if people use rdf:reifies, you have the entailment Enrico mentioned
… but it is not because of the addition of triple terms; it is because the addition of rdf:reifies
… it is easy to add this to existing reasoners
… The goal of RDF 1.2 is not to allow previous implementation to work "out of the box", you still need to add things like rdf:reifies, rdf:Proposition, base dir, etc.
ora: you are saying: we need to make sure that people are not just slapping a 1.2-basic version on their 1.1 impl
AZ: yes
<pfps> +1 to andy
pchampin: The role of unstar/basicify is to encode RDF 1.2 Full into RDF 1.2 Basic.
… It describes a way of encoding graphs with triple terms without using triple terms.
… We could have defined a mapping to RDF 1.1, but we didn't do that.
… I don't see why this is problematic; maybe it needs to be rephrased.
gkellogg: it is not simply about what parsers support or what systems can represent;
… for me it is also about the RDF-CANON canonicalization
ora: just, let's not use the term "basicify"!
<tl> "turned basic"
niklasl: my understanding is that RDF 1.2 basic was RDF 1.2 semantics with RDF 1.1 syntax
… canonicalization does not work with base direction
enrico: it is not enough to kill rdf:reifies and triple terms
… we need to understand the consequences on reasoning of just restricting the syntax.
<pfps> I don't think that Enrico's concern has any implications, but this should be checked.
enrico: Another point: I don't like how the "unstar" algorithm.
… It does not prevent semantics, why should people use it?
… I believe that "unstar" should only unstar the Turtle syntactic sugar.
… This really question why we want to have RDF 1.2 in the first place.
ora: I've heard many people ask "what about old-style reification?"
… we need to have a very clear answer to this question.
… I understand that this is not only a syntactic restriction.
pchampin: I don't understand enrico's concern.
<AndyS> https://
enrico: see 3rd rule in appendix A of RDF semantcis
<AndyS> https://
enrico: this rule generates triple terms
<AndyS> rdfs14 -- only if <<()>> occurs in the data
<doerthe> I also think these rules won't harm
pchampin: but it generates them in the subject position, so that's generalized RDF, so not part of the abstract syntax :)
niklasl: I think the explanations about reification and the relationship to "old-style" reifications are meant to be in RDF-Schema
… I have not progressed on this
<doerthe> depending what you want, I can help you to go through the semantics, Niklas
niklasl: I want to show that "old-style" reification can be isomorphic to new reification with some inference
<niklasl> My explanation/reasoning is also in w3c/
<gb> Issue 152 Explain how classic RDF reification relates to triple terms and rdf:reifies (by niklasl)
<doerthe> I'll check
ora: niklasl, when do you think we can have this explanation. This would be something we could vote on.
niklasl: I think we can not make "unstar" semantically interoperable, RDF-Schema is too weak.
ora: I think we need a description of what basic is, its relationship with full, and explanations about the unstar algorithm
<niklasl> There is also an rdf:Statement _as a reifier_ in https://
ora: I'm not so concerned about having a note document ready, but I would like some text that we can vote on
… I'd like to have this in 2 weeks, to continue the discussion.
<niklasl> (specifically https://
enrico: I think we should rather work on mapping triple terms to old style reification and drop unstar
… having two transformation would confus people
ora: +1 to enrico on this
pchampin: The idea of unstar mapping is to have something as simple as possible.
… I agree that if we have a semantics-preserviing mapping, that would be best, but I don't think we can do that with old-style reification.
… I'm all for trying. We didn't try to be semantics preserving, but to have an encoding that would work for C14N.
<niklasl> I have one, but I fear it's too loose: https://
<tl> old-style reification needs an intermediate mechanism to deal with multi-tripleterm propositions
pchampin: This is not needed if there is a more elegant/semantics preserving way, we should do that.
… But, we don't have this at the moment.
niklasl: I pasted a link with the one I've been toying with
… it is based on the fact that if you have a proposition, you have a token about it
… I think what we need is a way to encode RDF 1.2 data into RDF 1.1 concrete syntaxes
enrico: I believe that we can find an entailment preserving (not semantics encoding) encoding only for the syntactic sugar
… that is a strong thing, because we encourage the use of the syntactic sugar
ora: would this make the syntactic sugar we have a syntactic suger for classic reification?
enrico: no; it would not have the same semantics
ora: and this would be using a different vocabulary than the classic reification
enrico: yes
ora: that would be great, but then we still have the question of the old reification
enrico: the answer would be counter examples: things that were confusing with the old way, and are better with the new way
tl: one main difference is the ability to reify multiple triples for one reifier
ora: how do we move forward?
… I like the idea that a basic reasoner could produce the same entailment that a full reasoner?
… Does this address the problem of canonicalization?
enrico: intuitively yes, but the devil is in the details :)
AndyS: canonicalization is merely about the syntax. All it needs is a form of flattening triple terms.
gkellogg: as long as there is a single way of turning triple terms in RDF 1.2 classic, that would work properly
… canonicalization does not require semantic equivalence
<niklasl> :a rdf:reifies <<( :x :p :y )>> .
<niklasl> #= >
<niklasl> :a rdf:reifies _:tt .
<niklasl> _:token rdf:reifies _:tt .
<niklasl> _:token rdf:tokenSubject :x .
<niklasl> _:token rdf:tokenPredicate :p .
<niklasl> _:token rdf:tokenObject :y .
pchampin: my only concern is that then RDF that can not be expressed using the syntactic sugar could *not* be canonicalized
… this is not unreasonable, but I'm not entirely happy with it
ora: we need to document that
… we are out of time.
… There will be a SPARQL TF tomorrow.
<Souri> What is the RDF1.1 equivalent of the following? :r1 rdf:reifies <<( :s1 :p1 <<( :s2 :p2 :o2 )>> )>> .
<niklasl> s/rdf:refifies rdf:refifies/rdf:reifies/
<TallTed> Souri — I suggest raising that question via email