– DRAFT –
RDF-star Semantics TF

<enrico> I am in a train, so it would be better if somebody else chairs today

Which grammars for simple, RDF, and RDFS entailments?

enrico: the current baseline says that you have simple semantics (completely unrestricted),

<AndyS> https://github.com/w3c/rdf-star-wg/wiki/RDF-star-%22minimal-baseline%22

enrico: then RDF semantics is restricted to the well-formed syntax
… then there would be RDF-S semantics.
… Whether Simple RDF should be completely unrestricted is an open question.
… Another open question is whether the well-formed fragment is strongly constrained.

ora: when you say "completely unrestricted", you don't mean things like "literals in the subject position" right?

enrico: no, I mean unrestricted when it comes to triple terms.
… One option: capturing the semantics of rdf:reifies into the meta-model without any syntactic restriction.
… Another option is to constrain syntactically the position of rdf:reify.

tl: I sympathize with the idea to allow any term in any position, but in the case of triple terms, we decided to be very restrictive (only with the rdf:reifies predicate...).
… So I don't see any value in allowing them in the subject position.
… The reifier can be used in any position we like, so nobody is hurt by restricting triple-terms themselves in the object position.

enrico: RDF simple already allows you to do whatever you want.
… You simply do pattern matching over a meaningless graph.
… RDF semantics add more semantics, RDFS adds more (inc. the notion of types).
… Only in RDFS do some IRIs have a specific semantics.
… I suggest we do something similar for the semantics of rdf:reifies.

ora: RDF simple seems to justify some uses of RDF that I have seen,
… which I don't like, but you can't prevent people from doing what they want.
… To what extent do we want to *enfore* things.

enrico: in RDF semantics, there is no enforcement. Just new triple corresponding to the meta-model.
… + entailment based on blank node abstraction.
… Only in RDFS do IRIs have a special meaning, provisioning for more entailment.

pchampin: reacting to Enrico
… saying "pattern matching over a meaningless graph" worries me

<enrico> we agree p-a

pchampin: every IRI denotes something in the domain of discourse, predicates are binary relationships.

pchampin: just to comment on Enrico's calling Simple semantics "meaningless". There is a semantics, so there is a meaning, even if very weak.
… Happy to see on IRC that enrico agrees :)

niklasl: in Simple RDF, literals are not allowed in the subject position, not just because they are not allowed in RDF 1.1, but because they do not belong there.
… I don't think the same holds for triple terms.
… I'm not sure where we should draw the line here. Entailment could lead anything to end up in the subject position (with inverse properties).
… We should focus on the ergonomics of concrete syntaxes. We could *discourage* triple terms in the subject position, without strictly forbidding them.
… We could have a concrete syntax for the generalized abstract model -- e.g. N3.
… This would not be the general user interface, but some form of expert interface.

enrico: when I say that Simple RDF is meaningless, I mean that IRIs are not bound to any pre-defined entity.

<pchampin> +1 to this notion of meaningless

enrico: Even if you use an otherwise well defined IRI, in simple entailment, its meaning is lost.
… Now, about the position of tripe-terms: even when restricted to object position, we can make meaningless statements (e.g. "john buys this triple term").

<niklasl> +1 to concrete, full-fledged well-formed notion.

enrico: The only meaningful use of a triple-term is as the object of rdf:reifies.

gkellogg_: I can understand the arguments for allowing triple terms in the subject position.
… I'm concerned about the impact on vendors if people start to use it.

<enrico> :liz :spouse <<(:richard :loves :liz)>>. ????????

<Souri> +1 to restrict triple-terms to the object position only, and only when the predicate is rdf:reifies (or rdf:asserts, if we include that)

<niklasl> +1 to gkellogg_ ; it's about "guiding the usage" for me too

<AndyS> We need a "generalized-except-predicates are IRIs"

<niklasl> enrico, but is "not preventing all misuse" an argument for "not preventing misuse" ? Or am I missing your written remark here?

pchampin: I'm OK with restricting to object only like literals
… at the same time, someone may come up with a predicate where is makes sense in the subject position

<enrico> :liz :spouse rdf:type. ?????

<niklasl> +1 pchampin, another predicate can come along to making sense (e.g. imagining a possible future RDF 1.x for graph terms being composed of triple terms, akin to lists... But *not now*.)

AndyS: I am neutral on this.
… We have to align the concrete syntaxes with the RDF data model.
… If we put anything in N-Triples, in must be in Turtle as well.
… The simple should work, that what makes c14n, SHACL, SPARQL work.
… Forcing the complex on everyone will cause problems.
… Again, I'm neutral, we should have a strawpoll and see where everyone's opinion's are.

ora: are you advocating for less restrictive?

AndyS: SPARQL has literals in the subject position, as a natural consequence of variables.

<niklasl> I have no issues with SPARQL allowing that.

AndyS: but if your data is correct, SPARQL will work correctly.

ora: implementations can rely on the assumption that the data is correct.

<niklasl> It already allows "Alice" ^foaf:name ?alice .

AndyS: if we talk about enforcing, then we are considering that data can be wrong, and should be checked.

<niklasl> I'm not for "enforcing only sensible", I'm for "minimizing user error".

doerthe: I also agree with pchampin and enrico, I think.
… I would prefer triple terms in the subject position, but I can live without that.
… I would be opposed to restricting triple terms with specific predicates, such as rdf:reifies.
… If we consider rdf:reifies to be a predicate, then other predicates should be allowed as well.
… Otherwise weird things may happen with entailment.

niklasl: I agree. This kind of restriction should be a SHOULD at most.

gkellogg_: and that's what RDF concepts currently says.

enrico: ok for not restricting RDF Simple.
… In the meta-model, there should be a class of predicates that accept triple terms as objects.

[enrico breaking up, he writes what he wanted to say]

<enrico> I'll write. I propose to have in RDF semantics the restriction that only predicates instance of a class rdf:reificationClass can have triple terms as objects

<enrico> and that triple terms can be only in object position of such predicates

<pchampin> I can live with that

<enrico> So to leave open the possibility that anybody could have her own interpretation of rdf:reifies

<niklasl> Pedantic: rdf:ReificationProperty ?

<tl> looks good to me

<enrico> yes nikasl

ora: the question is then: if they are not, will there be crazy behaviour, or what?

<enrico> Not crazy, but the meaning would be left to the user

<tl> +1

<doerthe> what would be the advantage? Just to pint out

<niklasl> +1 maybe not spelled out "crazy" in the spec

<doerthe> point again ;)

<enrico> ANd we can have a RDF rule saying that A B tripleterm ==> B a rdf:reificationProperty

<doerthe> wishful thinking

<Souri8> If I say :r :myProp <<( :s :p :o )>> . Are we going to entail (using RDF entailment) that :myProp rdf:type rdf:ReificationClass . ?

<enrico> Yes

<enrico> Yes Andy

AndyS: to check my understanding,

<enrico> yes to all

AndyS: this mechanism (as described in the baseline document) would not go into a spec.

<enrico> This means no well formed syntax anymore

<enrico> but just the metamodelling rule above

<tl> yeah! :)

<doerthe> ah, ok, thank you enrico

Asking about this section - would it be removed -- https://github.com/w3c/rdf-star-wg/wiki/RDF-star-%22minimal-baseline%22#abstract-syntax-of-well-formed-rdf

<enrico> yes andy

niklasl: being pendantic, a better name would be "ReificationProperty"

ora: yes

<Souri8> Are we going to state in RDF1.2 spec that "to start with, rdf:reifies by definition is an instance of the rdf:ReificationProperty class"

<pchampin> +1 niklasl

<ora> STRAWPOLL: Do you support the idea that in RDF semantics only predicates that are instances of rdf:ReificationProperty can have triple terms as objects?

<niklasl> +1

<AndyS> +1

<ora> +1

<enrico> +1

<pchampin> +1

<gkellogg_> +1

<pfps> -1, what is an instance?

<Souri8> +1

<enrico> a instanceof b iff a a b.

<doerthe> 0 (not sure yet, need to think)

<niklasl> rdf:reifies rdf:type rdf:ReificationProperty .

<enrico> no pfps

pfps: what does "instance" mean in this strawpoll?

<tl> does the strawpoll mean that triple terms can appear in subject position?

<enrico> it is just a metamodelling triple from rdf, just like may others

<Souri8> "instance" => an individual in the rdf:ReificationProperty class

<enrico> :a :p :b ==> :p a rdf:predicate

<enrico> no no gregg

gkellogg_: it adds some complexity

<niklasl> Pedantic: :p a rdf:Property .

<pfps> True, but then there is no restriction.

enrico: whenever an IRI is used in the predicate position, it has rdf:type rdf:Property. Similarly, whenever a predicate has a triple term as object, it has rdf:type rdf:ReificationProperyt.
… No check to be done.

<Souri8> Is it okay to assume OWA? Which means due to typo, rdf:deifies, could become one such property.

tl: does it implies that triple terms can not appear in the subject position? or is it still an open question?

gkellogg_: it is an orthogonal question.

<tl> +1

<niklasl> +1

ora: I will have to drop for another meeting in 2 minutes. Are we happy with the discussion so far? Can we move forward in the agenda?

niklasl: if a property is used with a triple term, it is automatically inferred to be a reification property. Is that the case?

<Souri8> What will happen to Turtle shortcuts? Would that apply only to pre-designated reification properties (like rdf:reifies, for example)?

niklasl: if I have ":alice :knows <<( s p o )>>", does that make :knows a ReificationProperty?

enrico: yes

Turtle shortcuts only generate RDF TripleTerm <<(...)>> in the object position.

tl: I'd like a strawpoll on triple terms in the subject position.

and also only :r rdf:reifies <<(:s :p :o)>>

<ora> I need to drop, someone else maybe take over chairing

enrico: with this meta-model, if a triple term occurs in the subject position, then the property will be entailed to be the inverse of a ReificationProperty.

<Souri8> -1 on triple-terms in the subject position

Souri8 - We could add a way to have a property but need to consider whether it is a "short" cut anymore.

niklasl: enrico, would you be against N-Triples not allowing triple terms in the subject position?

enrico: strongly against it.

tl: we can have constraints in RDF in the abstract syntax, and I think we should.

gkellogg_: if we allow triple terms in the subject position in Turtle, we need to update N-Triples, and then the abstract syntax.

<niklasl> I dislike triple terms as subjects in N-Triples. I am *for* them in that position in SPARQL. Just as the case is with literals today.

gkellogg_: I would be more inclied to allow them in the subject position if there was no way to express that in concrete syntaxes.

<niklasl> It is easier to allow it later on than to prevent it later on.

<pchampin> -1 to have abstract syntax construct not expressible in concrete syntaxes

<gkellogg_> +1 to niklasl

enrico: the only reason that could convince me of disallowing triple terms in the subject position would be implementation concerns.

<Souri8> Should we say that a ReificationProperty cannot have an inverse property (similar to datatype properties)?

enrico: We should not assume that everyone implements things in a certain way, but if 99% of them do, them it would be a good reason.

I agree with enrico, but if the fact that a property is an instance of ReificationProperty because it happens to have a triple term, it is not a restriction at all. So why are we having it?

enrico: this is a restriction for the user.

<niklasl> It can be enforced in OWL? (disjointWith)

enrico: It can not have any other meaning.
… Just like using p in the predicate position forces it to be a property.
… This is just meta-modelling, but it is useful to tell the user what they are actually doing.
… People may not care about it, but it's there.

<pfps> But then this "STRAWPOLL: Do you support the idea that in RDF semantics only predicates

<pfps> that are instances of rdf:ReificationProperty can have triple terms as

<pfps> objects?" doesn't mean what most people think it means.

pfps: but then most people will misinterpret the word "can" in the strawpoll.

<pfps> STRAWPOLL: Any IRI used as the predicate of a triple whose object is a triple term denotes an instance/\ of the denotation of rdf:ReificationProperty.

<enrico> +1

<gkellogg_> +1

<niklasl> +1

<pchampin> +1

<tl> +1

<doerthe> +1

<pfps> +1, but this doesn't say very much at all

<TallTed> +0.5

<AndyS> +0.5

<Souri8> +1

<enrico> It allows to have arbitrary predicates as reification predicates

<enrico> opening the door to the different use cases, without problems about how to call such proeprties

STRAWPOLL: Do you support allowing triple terms in the subject position?

<pchampin> +0

<Souri8> -1

<tl> -1

<doerthe> +1

<gkellogg_> 0

<enrico> +1

<TallTed> -0.5

<niklasl> -0.9 (-1 for support in N-triples (and Turtle and TriG))

<pfps> +0.5

0

STRAWPOLL: do you support disallowing triple terms in the subject position

<pchampin> +0

<tl> +1

<enrico> -1

<gkellogg_> +1

<doerthe> -1

<Souri8> +1

0

<niklasl> +0.9 (+1 to disallow in N-triples (and Turtle and TriG))

<TallTed> +0.5

<pfps> -0

niklasl: I would prefer to disallow them in concrete syntaxes until we know we need them
… I do not include SPARQL in that.
… N3 is also different.

<niklasl> Ah, thanks Andy; the reality is more complex.

<niklasl> I (guess I) meant SPARQL Query

pchampin: I don't think that it is a good idea to allow things in the abstract syntax which can not be expressed in the concrete syntax.
… RDF/XML 1.0 had this issue with blank node.

AndyS: having N-Triples diverge from the absract syntax is a bad idea.
… People rely on the concrete syntax to understand the abstract syntax, because that's what they can see.

niklasl: if we had time, I would like to formalize the generalized abstract syntax.

pchampin: generalized RDF is well specified in a non-normalized section

<niklasl> Yes, semantics is based on the generalized syntax IIRC.

pchampin: and IIRC semantics uses generalized RDF

<niklasl> (well, no, but a way to implement it; I am not precise enough; I'll paste a link)

pchampin: this is a minor issue for semantics and no triple term in subject position adds to that
… but this is niche enough to not worry

<tl> +1 to pchampin

pchampin: this is how I made my peace with not in the subject position

<niklasl> +1

<Souri8> rdf:reifies owl:inverse :myReifiedBy . :r rdf:reifies <<( :s :p :o )>> . =[entails]=> <<( :s :p :o )>> :myReifiedBy :r .

AndyS: which implementations are relying on the restriction on literals in the subject position for their indexing strategy?

[crickets]

tl: is there a downside to making the triple terms opaque, if rdf:reifies is considered transparency-enabling?

enrico: there are strong reasons to not make triple terms opaque.

AndyS: the problem of opacity is how blank nodes work, even at the syntax level.

<niklasl> +1 we didn't go the TEP route