Meeting minutes
pchampin: news since we last talked. new charter has been approved on last steps by w3c management.
… changes were sufficient to address concerns. need to draft announcement. rechartered for 2 years.
… as discussed, implemented change of name. new name will be "RDF and SPARQL WG"
… URLs and mailing list will remain the same.
ora: chairs decided not interested in taking on change of URLs and mailing list.
… those can happen after we go to REC.
map the annotation syntax to rdfs:states 1
tl: mostly negativie discussion, not in support of proposal.
… ambivalence in my proposal which I hadn't recognized. now I recognize why pfps said it was propositional attitude.
… If you want it clearly expressed that reification is stated in graph, why not add a type "this is stated reification"? I thought that was unreasonable. You can't expect that to be added all the time.
<pchampin> something missing is *never* expressing anything in RDF; Open World Assumption
tl: But now I thought maybe we can do it the other way around. If I reify the propisition, just add a "not endorsed" class. Expect that to be much more seldom.
… Could be a reasonable burden.
… If you want people to know this annotation doesn't endorse, then you've got a way to express it.
… Maybe that's good enough. I'm now thinking about that. Much less burden on everybody else.
… It would have other traps. Still open questions. Would this be required for mapping from reification shorthand?
… When we use chevron in subject position, should that be expected to map to a new type "unendorsed propisition"?
ora: You're still thinking about it? Should we not be discussing this today?
tl: I don't want to waste time, but comments now ... happy to listen.
james: I have noto been able to comprehend all the comments in last 24h. Want opportunity to do that before reaching any decisions.
<enrico> A+
ora: any other strong feelings?
enrico: My problem is that these decisions are moving targets. Is this about shortcut? I don't know.
ora: Not is not the time to discuss this.
pchampin: I agree with enrico. It has become a moving target. Would it make sense to close this issue and open a new one with a specific proposal?
… for the sake of clarity.
… I would rather close the perma-issue. Title and lots of the discussion are moot.
tl: Not really. Initial comment still stood until late tonight.
… not that much moving.
… One ore two proposals to react to criticism. The reactions are moving.
… Others did endorse rdfs:states in the past. Just not mapping from the annotation syntax.
… Moving target is not entirely fair. I adjust to responses.
… A very strong thing if the triples are in the graph or not. If you're annotating things in the graph or not.
… That's so important. Can't imagine we don't have a way to say that.
… That hasn't changed at all.
… I can open a new issue, write a new summary.
… I fear we will have the same discussion again in the new issue.
ora: I like what pchampin suggests. Why don't we do that. Open new issue. Write a new succint summary.
… Important for everybody to get a clear understanding of the proposal and why.
enrico: I insist that the new proposal should be clearly distinguished from what is proposed in the text.
… Why do you want that? What is not clear is what is the change that is proposed.
… We need to discuss the proposal, and you need to convince why the proposal makes sense or not.
ora: Almost never a good idea to bring a half-baked proposal. Much better to have a very clearly thought-out proposal that answers all the questions.
naming RDF 1.2 without triple terms 2
<pchampin> w3c/
ora: the two agenda items (this and next) are related.
AZ: The issue is about naming 1.2 graphs that do not contain triple terms.
… something that would be similar to RDF 1.1 graphs.
<pchampin> w3c/
<gb> Issue 70 Define RDF 1.2 Basic profile (by gkellogg) [needs discussion] [spec:enhancement]
<pfps> I'm here, but I only recorded the issue
AZ: issue was opened almost a year before we had resolution about this. Including the naming of RDF graphs without triple terms.
… the choice was to name this part of RDF "1.2 Basic". Therefore there isn't an issue. We already decided.
ora: This is my recollection.
… What do people think? Have opinions changed?
tl: What do you say about the conversion?
one needs a verb: "classify" works, "basicify" doesn't
AndyS: Does RDF 1.2 Basic graph allow text direction?
AZ: I think proposal was that yes, it does, because RDF 1.2 Basic was only disregarding triple terms.
… idea is to include everything but triple terms.
ora: why would we come up with a name? Wouldn't that be RDF 1.1?
pchampin: I confirm that's what the resolution said.
ora: we have decided. don't need to decide again unless objection.
… next item is to define what it is. Seems we also have a good understanding of what that is.
ora: why do we need a verb?
tl: can be "convet to basic".
<niklasl> I think the verb is "classicise"though? (Successor to "unstar"...)
AndyS: does this imply that the property rdf:reifies is not used in such a graph?
… does it exclude the vocabulary? or just no triple terms?
… I would prefer rubish in, rubish out.
ora: If you have A reifies B, what would that mean?
AndyS: I don't think that has a sensible meaning.
enrico: It has a very precise meaning.
<niklasl> :a rdf:reifies :b . :b a rdfs:Proposition .
enrico: A refies B, even if B is not a triple term, is a proposition.
… we could have that.
… rdfs:reifies range implies a proposition.
… it's still meaningful.
ora: 1.2 Basic disallows triple terms and nothing else.
… already discussion next agendum
<tl> only disallowing triple terms sounds reasonable to me as well
pchampin: we have a resolution that dates a year ago. this resolution was never implemented. makes sense to ask ourselves why.
… one way is to create an action to implement the resolution.
… as for AndyS's questions, maybe we can check with strawpoll to restrict definition to just no triple terms.
… maybe that's not needed as it was already resolved.
<ora> STRAWPOLL: RDF 1.2 Basic is RDF 1.2 without Triple Terms
<tl> +1
<ora> +1
<gtw> +1
<pchampin> +1
<gkellogg> +1
<AZ> +1
<doerthe> +1
<fsasaki> +1
<olaf> +1
<niklasl> +0.75
<william-vw> +1
<enrico> +1
<james> +1
<pfps> +1
<AndyS> +1 with VERSION "1.2-basic"
niklasl: probably +1, but regarding motivation.
<TallTed> ±0 I haven't considered this framing in quite some time
niklasl: versioning of syntaxes. it's not entirely orthogonal to this.
… if we have someone who is asking for data from dataset which contains RDF 1.2 (triple terms) and literals with direction.
… and they say "I only understand 1.1", you might want to provide consumer with as much data as possible anyway
… so you would turn it into RDF 1.2 Basic and serialize. But that doesn't work for direction.
… not entirely certain use-case for having this basic profile is only about the triple terms.
… might also be about direction.
ora: If we were to exclude direction also, why wouldn't the server respond that it's RDF 1.1?
niklasl: because rdf:reifies is not in 1.1.
ora: and RDF is a closed namespace.
niklasl: we've added things into the namespace since 1.1, right?
AndyS: rdf:JSON
james: the implications of enrico's description, what would be the meaning of having a reifies statement that has as object the subject of a 1.1 reification?
… does that have any significance?
enrico: we have deprecated the old reification. you can write it, but from newer perspective, this is not advisable or meaningful.
james: even in Basic?
enrico: use case for Basic is you can keep older implementations.
<niklasl> I think the possible meaning is related to the informal "classicised" form.
enrico: otherwise there are so many small details that have changed from 1.1, what do we leave from 1.2 for basic?
… this was born because people not willing to implement triple terms.
james: if you only exclude triple terms type, and have 1.2 deprecated form, would it be acceptable as having meaning of naming the reification (again)?
… or would that itself be deprecated?
pchampin: number of subtle differences between 1.1 and 1.2.
<niklasl> [ a rdf:Statement ] rdf:reifies [ a rdfs:Proposition ] .
pchampin: my understanding for need for Basic profile is that triple terms add significant complexity to model. flat to recursive.
… some implementations might not want to take on that burden.
… to james' point, doing what you suggest is legal syntactically, not semantically inconsistent.
… does not have same meaning as the similar use of triple terms with same components.
gkellogg: I'm mostly inline with what pchampin just said. Compatibility with 1.1 is defined by 1.1 specs. Not our job to provide a way to seamlessly transition between 1.2 and 1.1.
… the purpose of a basic profile is not to deal with minor changes such as base direction of text. the structural differences that triple terms bring.
… we need to focus on motivation for that. stop thinking overly about needs of people that have implemented 1.1 to do the least they need to to claim 1.2 compatibility.
niklasl: I wrote out clarification. Meaning would not be the same as classic reification. RDF 1.1 reification is a statement. That can be seen as reifying a proposition.
… related to that procedure... formerly known as unstarring.
… those terms are tricky to use right. you should upgrade to 1.2 and use triple terms. otherwise you'll use them wrong eventually.
AndyS: we've always talked about the issues around 1.1, will a system be able to ingest 1.1.
… the step of fetching and using may not be the same.
… I think we can do something like have explicit version label for RDF 1.1.
… can be meaningful. can add to code request. know what you're getting back.
… if you're going to republish data, you might be able to cope with 1.2. but maybe downstream clients won't be able to handle 1.2.
<niklasl> +1 to AndyS
AndyS: need a strict 1.1 ability.
ora: somebody needs to write a proposal on exactly how we want to define this.
<pchampin> accept: text/turtle?version=1.1 could be used, and makes sense to me
ora: then it can go into Concepts.
<AZ> "rdf:reifies" does not do much anyway, it's just a property that makes the object an instance of rdfs:Proposition
<pchampin> +1 AZ
<AZ> (at least in the current version of RDF 1.2 semantics)
AndyS: if we can do that as part of defining the labels, I can do that.
… if it's open-ended, I haven't got the time.
ora: it's fairly contained.
<niklasl> +1 to pchampin; +1 to AZ
ora: will await writeup
<gb> Issue 135 naming RDF 1.2 without triple terms (by pfps) [needs discussion]
Define RDF 1.2 Basic profile 3
ora: already discussed this.
what properties can or should link to triple terms? 4
ora: Semantics TF discussed this?
AndyS: I raised the issue. Not sure it's still valid.
ora: there is a conclusion from TF from two weeks ago.
<enrico> sorry I was disconnected
niklasl: I believe we agreed that liberal baseline - we are not forbidding using any property with triple term as object.
<pfps> yes, a formal resolution appears to be indicated
<tl> w3c/
<gb> Issue 127 what properties can or should link to triple terms? (by afs) [needs discussion]
niklasl: related was an issue from Souri, nesting triple terms.
… I think closing this would not block that.
<tl> Franconi
<tl> left a comment
<tl> (w3c/rdf-star-wg#127)
<tl> We discussed at the Semantics TF and we reached this conclusion:
<tl> Conclusion 1: we discussed about restricting (or suggesting to restrict) the usage of triple terms only as object of rdf:reifies, but we believe that their usage should be unrestricted.
<tl> This conclusion will be brought forward for discussion in the WG.
pchampin: I think the issue raised by niklasl is orthogonal to that one.
… even if we restrict triple terms to only rdf:reifies, we can still make a triple term where predicate is rdf:refiies.
… nesting is orthogonal to whether we allow other predicates.
… I personally agree with conclusion of TF.
<pchampin> https://
pchampin: How does it impact this note [linked]?
… enrico said is fine with semantics already.
enrico: my argument is that triple terms are orthogonal to reification.
… may not use rdf:reifies.
… can use rdf:reifies without triple terms. perfectly fine meaning.
<william-vw> I don't think they're orthogonal with the restriction of triple terms to the object position ...
enrico: I would just never mention the fact that we discourage these combinations. Leave complete freedom.
… that's what semantics says. Don't want to block future of more creative uses.
… Any reference to SHOULD or MUST should just disappear.
<tl> +1 to enrico
pchampin: This NOTE contains normative language which is a mistake. This will be fixed.
<niklasl> The issue (by Souri) I mentioned: w3c/
<gb> Issue 155 Would compliance require support for arbitrary recursion in a triple-term? (by sdasoracle)
<william-vw> ... as that is specifically tailored towards encouraging reifiers, I believe
pchampin: not suggesting to make this normative.
… still good to have this guidance. I agrees sky is the limit.
… rationale to introducing triple terms was to have better way to do reification.
… I don't think we have clear use-cases or best practices to use them otherwise.
… I'd be against making this normative, but having a note with proper language is still a good idea.
ora: You are suggesting some other language?
pchampin: I suggest we keep the note but fix the normative language.
ora: Do we express any kind of guidance?
… If I interpret enrico correctly, maybe there shouldn't be any guidance.
niklasl: we do by having syntax that encourages rdf:reifies. annotation syntax in turtle.
… proposed in RDF/XML, JSON-LD. All cater to using rdf:reifies.
… I thikn that's aligned with NOTE language.
<TallTed> s/palces/places/
james: I prefer recommendations that say only what they need to. This NOTE doesn't add any meaning. Doesn't help the user.
… the rest of the recommendation does that.
tl: Will we have a NOTE explaining the new triple term reification mechanism?
… An extra document?
<Zakim> AndyS, you wanted to suggest "a common pattern is to ..."
<AZ> I don't see why there should be guidance for rdf:reifies while we don't have guidance about rdf:List, rdf:first, rdf:rest, rdf:nil, for instance
AndyS: Trying to come up with different terms to say a pattern could be used.
<pchampin> I like the notion of pattern
AndyS: doesnt' say "should". Less directive force than "should" even in informal sense.
enrico: I believe this NOTE should just not be there. We spent a lot of time in Concepts to explain how to write reifications.
… it's explained everywhere. Main point of RDF 1.2.
… NOTE does not say much more about how to do reification.
… It does suggest only using triple terms for reification.
… may hamper some future.
ora: any objections to the NOTE going away?
william-vw: That restriction that was voted on... triple terms only in the object position. That was done to encourage the use of reifiers?
… for me, this was restricting too much. Clearly points towards the intent of WG to push for reification.
… two issues are not orthogonal. Not from a practical viewpoint.
… I do feel there should be guidance on how to use this particular construct. Always with reification.
niklasl: I do agree with that. I think the primer does something to that effect. We can work more on that.
… We do not encourage any other way to use triple terms.
… We don't want to discourage that. One way is to say nothing.
… Perhaps only information needed is already in there. Wouldn't mind informative language in there.
ora: Maybe we should have some explanation.
<pchampin> william-vw as niklasl and enrico pointed out, this "encouragement" to use rdf:reifies is in many other places, starting with the syntactic sugar and the examples in the primer
niklasl: not sure we can give clear guidance at this point on other uses.
… relationship with named graphs and reifiers, lists, etc.
<william-vw> pchampin why not make it clear by having a separate NOTE?
<william-vw> * even clearer
niklasl: without clear explanations, there is something for having some informative text on reifiers as the way we know how to use.
<william-vw> instead of spreading it across documents
ora: need some sort of explanatory text.
<AndyS> RDF-star SPARQL TF : https://
<AndyS> Meeting slot will reuse the SemanticsTF slot (Fridays, 4pm CEST) starting 2nd May.
<AndyS> (i.e. not tomorrow 25/April)
<pchampin> m2gbot, link issues with transcript
<m2gbot> comment created: w3c/
<m2gbot> comment created: w3c/
<m2gbot> comment created: w3c/
<m2gbot> comment created: w3c/
<m2gbot> comment created: w3c/