– DRAFT –
RDF-Star Semantics Task Force

<enrico> Item propose for discussion by Andy: Discuss a roadmap for producing content for the RDF specifications and also identify any WG Notes. Objective: bring this roadmap to the full WG.

enrico: If we start from the baseline
… we touch RDF Concepts, RDF Semantics, SPARQL, syntax documents

AndyS: including RDF/XML esp. rdf:ID.

enrico: talked to Steffen Staab about an improved reification based on RDF-star/CG
… believing we have the syntax of the of the GC

gkellogg: N-triples, N-quads updated to latest syntax; Turtle partly done, more to do
… to do - TriG
… the WG has suggested we might not touch RDF/XML.
… some work in JSON-LD

<enrico> https://www.ki.uni-stuttgart.de/institute/news/Representing-Subjective-Facts-with-Epistemic-Knowledge-Graphs/

<niklasl> https://w3c.github.io/rdf-turtle/spec/#reified-triples

<gkellogg> https://w3c.github.io/rdf-turtle/spec/#triple-terms

AndyS: We should scope a "note" to get a sense of how much work is involved.

niklasl: hope to contribute
… also material in the RDF Primer

thomas: could put the material in the primer

niklasl: will ask around at workplace for suggestions

thomas: RDF/XML - don't need to touch it
… but in the note need to refer to rdf:ID and explain why it's different

niklasl: named graph can be used for some purposes not covered by transparent RDF-star
… and there is "unstarring"

AndyS: where does "unstarring" go?

gkellogg: in RDF-Concepts?
… because in the RDF namespace

AndyS: Impact on canonicalization - in the note?

gkellogg: yes

<niklasl> +1 to "re-starring" thoughts

gkellogg: and consider classical reification -> RDF-star -> unstar
… and RDF-star -> unstar -> RDF-star

niklasl: may be a subclass of rdf:Statement for RDF-star -> unstar -> RDF-star

(discussion about subclass + domain)

niklasl: will take stab at an outline

enrico: baseline - syntax
… full unrestricted

Discussion on open problems in the semantics of the baseline

enrico: well-formed for RDF entailment
… open - triple terms only in the object position which could mean start with the well-formed syntax
… personal - I prefer not to have the triple term - object restriction at the lowest level.

thomas: prefer object restriction in the abstract data model

<doerthe> can you post again the current version of the baseline? I am back from holidays and wonder whether we changed

niklasl: not in favour of unrestricted triple term in the data model
… there is generalized RDF (non-normative)
… lots of variations - confusing?

<doerthe> https://github.com/w3c/rdf-star-wg/wiki/RDF-star-%22working-baseline%22?

gkellogg: currently RDF Concepts - object restriction + notes on use of triple terms with rdf:reifies

<doerthe> I am actually against the restriction

<doerthe> I also don't get it

enrico: not seeing the harm of triple terms in the subject at the data model level ... wanting to see a concrete illustration

<doerthe> how does object position prevent that?

thomas: (spoken example)

<niklasl> The seminal example mistake.

(discussion)

<doerthe> ok, what makes the object position so special?

enrico: examples are outside the well-formedness

<niklasl> The well-formed syntax is good and needed, yes; especially if the "unrestricted" allows too much in "user space".

pfps: I agree with Enrico
… one of design philosophy of RDF is that you can do some really stupid thing with it

<niklasl> Why don't we want to be consistent here then?

pfps: with inconsistencies

tallted: no way to handle literal-as-subjects at scale

gkellogg: literals-as-subject may be an implementation
… impact

niklasl: maybe well-formedless is the solution - not clear to me ATM.
… RDF/XML does not have literals-as-subject

gkellogg: at the moment (RDF-concepts), abstract syntax does not allow (literals or) triple terms in the subject position
… reified triples can be in the subject position in syntax
… and we expect/hope that most use is via "agreed syntax" not raw rdf:reifies.

enrico: Triple terms are not like literals (not self-denoting)

<niklasl> Literals are tuples too (and denote resources).

enrico: RDF is not an object oriented language - RDF is neutral to class and object-ness
… often people write data in an object-like way but it is not required.
… Turtle - maybe have only the shortland syntax

NT is a syntax subset of TTL.
… encourage the well-formed syntax restriction

<niklasl> +1 for *at least* pushing well-formed; but yes, NT is the base

<doerthe> I remember why I dislike the well-formed syntax, but I think that should better be discussed in mails. I will write one.

<enrico> yes, doerthe

Souri: as I see it, it is associating a URI/bnode RDF term with a triple term. Then use that RDF term as you like.

<doerthe> so, I am against the restriction with the object position and even against well-formedness at all, but if we discuss these matters separately, I am with Enrico here

Souri: I like the restrictions.

gkellogg: good points about consistency concerns

<thomas> +1 to Souri

<niklasl> I agree with Souri that it seems simpler to add as little as possible to the RDF 1.1 abstract syntax.

doerthe: I don't think of the object position being different to the subject position

Souri: about the inverse

<niklasl> It's a directed graph, so I'd say it "affords" only pointing *to* more complex structures of literals and triple terms. But that's not a "logical" position, it's an "ergonomic".

Souri: if rdf:reifiies domain & range is defined then this restricts the subject

<doerthe> :isReifiedBy inverseOf :reifies ?

Souri: my emphasis is for rdf:reifies as identifier association.

<doerthe> so, reified is simply not a "normal" propoerty?

<niklasl> Same as ex:nameOf owl.inverseOf foaf:name

enrico: thought experiment
… if we define "rdf:isReifiedBy"
… well-formedness gives the intent on position.

thomas: not heard a use case for subject-triple terms.

<doerthe> just reverse the predicate you use?

doerthe: to Souri
… rdf:reifies is a property which can be reversed.

<niklasl> Is that an argument for also allowing literals in the subject position too?

doerthe: could define it specially but then it have sub-property
… to thomas

<Souri> rdf:type does not have an inverse defined in RDF, rdf:reifies/rdf:states could be treated similarly

doerthe: I agree with Enrico - subject is not special compared to object

niklasl: one last thing - there is nothing special about the subject
… it is wellformedness that is important
… for me, it is the affordance of the graph
… an ergonomic argument

<doerthe> it makes people using triple terms less?

enrico: this is what I mean by object oriented thinking.

<niklasl> Yes doerthe

<Souri> terms used as objects today can be more complex than subject, so we keep subject simple like today by allowing this complex thing -- triple-term -- to be only in the object position

<doerthe> ok

<doerthe> that point I get

gkellogg: three cases:

<niklasl> And yes to Souri, I think like that too.

gkellogg: full unrestricted syntax - triple terms in subject position

<Souri> from an implementation point of view=> parsers today have a complex logic for recognizing objects, so we just increase the complexity a bit more there to recognize triple-terms -- this allows subject parsing to stay simple

gkellogg: RDF concepts current restricts triple terms to object position
… wellformed - only use with "rdf:reifies triple term"

<doerthe> so, you have an implementation argument here, Souri? That is something I would have to trust you on, but you really think it would be far more complex to program?

At the terminals level, nothing is content sensitive.

SourI: argues for simple parsing.

thomas: update on rdf:states

gkellogg: further implication of subject usage. If possible, people will use it.

<doerthe> thank you for answering Souri (I like to understand all points of view :) )

<enrico> 🍺

enrico: implementations reflect an object-oriented POV

<doerthe> ... wishful thinking, Enrico ;)