– DRAFT –
RDF-star Semantics TF

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

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

<doerthe> I'll be away for 5 minutes

<niklasl> Is w3c/rdf-star-wg#127 relevant?

<gb> Issue 127 Material about `rdf:ReificationProperty` (by afs) [needs discussion]

pfps: We have two baselines - "minimal" and "alternative"

Issue and wiki page https://github.com/w3c/rdf-star-wg/wiki/Notes-from-the-Semantic-Task-Force-meeting-2024%E2%80%9009%E2%80%9013

pfps: we can take that issue to proceed with the alt semantics

souri issue 127 is the main issue to decide
… rdf:reifies vs rdf:reifies and other properties
… I have come back to either (1) rdf:refies or (2) a class of properties

<doerthe> back

pfps: I agree and I agree with the conclusions.
… I will add comment(s) to issue 127

<niklasl> +1

pfps: unlock concepts and semantics documents

niklals: vocabulary descriptions, maybe not just yet
… there is un-star-ing

<Souri> Choice spectrum: 1) rdf:reifies only; 2) rdf:reifies + rdf:asserts (I do not advocate this any more because it causes discussion about inclusion of s-p-o in the graph, as a side-effect); 3) rdf:reifies + rdfs:states (Thomas); 4) [rdf:reifies and] rdf:reificationProperty class -- any property may be used.

<Souri> My choice is either #1 or #4.

<gb> -> CLOSED Action 4 decide on the short names of the specifications (on pchampin) due 22 Dec 2022

<gb> -> CLOSED Issue 1 No activity (nor even README) since WG approval in August (by TallTed)

niklals: also need the range of rdf:refies ; the type of triple terms

AndyS: Would need text for rdf:reifies in RDF concepts - different from namespace description text

AndyS: Text for RDF primer?
… we have discussed describing some usage patterns
… primer not normative (can it be later than other docs?)

niklasl: I have material such as the TCAP'24 slides

AndyS: We have discussed in depth LPG.

Souri: for the choices - number 4 choice, any property to connect a reifier
… may have non-default properties for my data
… implications of rdf:reificationProperty on Turtle

<Souri> << :r | :s :p :o >> in Turtle ==> :r rdf:reifies <<( :s :p :o )>> .

<niklasl> AndyS: You can use specific types on the reifier to define particular kinds of reification.

<Souri> << :r :claims | :s :p :o >> in Turtle ==> :r :claims <<( :s :p :o )>> .

niklasl: One form of the class rdf:reificationProperty is "all properties in the data with object rdf:tripleType"

<Souri> I see :r rdf:reifies <<( :s :p :o )>> ; a :Claim . being shortened by the #4 choice to => :r :claims <<( :s :p :o )>> .

<gb> -> CLOSED Action 4 decide on the short names of the specifications (on pchampin) due 22 Dec 2022

niklasl: owl:sameAs ends up as a member of rdf:reificationProperty class

Souri: shorter path when using with a custom property

doerthe: I favour option number 4.
… the reification property class removes the need for "well-formedness" syntax restriction
… we are unclear about what we want from the reification property class

<Souri> IMO, to avoid complexity, we should avoid creating a subproperty relationship between custom properties such as :claims and rdf:reifies.

doerthe: also - what is the relationship of rdf:reifies to the reification property class

<niklasl> +1

doerthe: what do we need the ReificationPropertyClass for?

<AndyS> TallTed: Multiple forms may require the user to have to choose between different choices and they have to understand both.

<AndyS> Souri: User can already do complex things (e.g. subproperty rdf:type) - we can avoid putting in more of those points in.

<AndyS> niklasl: ReificationPropertyClass avoids the need to hardcode rdf:reifies.

<AndyS> ... additional members may be only ones defined by the app

<Souri> I have the same feeling about minimality

<doerthe> currently reading again, therefore the silence

<AndyS> pfps: We can explain good (and bad) usage of a very general mechanism.

<doerthe> I have an opinion now: I am against well-formedness, fine with the rest of the baselines

<Souri> I like minimality + well-formed (requiring tripleTerm to be present only in the object position) but without requiring that rdf:reifies should be the only predicate that can have tripleTerm as object

<doerthe> of course I am still against the object position only, but yu know that ;)

<AndyS> niklasl: Pierre-Antoine has suggested call it "triple term property" and I now favour that.

<Souri> +1 to using the term "tripleTerm property class" (instead of "reification property")

<Souri> What would be the replacement for rdf:reifies property then (that allows us to avoid the term "reification")?

<AndyS> niklasl: If the range of rdf:reifies is "triple term" , and call rdf:reifies " "tripleTerm property""

<AndyS> doerthe; Would your triple term class be disjoint from owl:datatypeProperty?

<AndyS> s/doerther;/doerther:/

<AndyS> ... in RDF - can a triple term property also be used with an IRI object?

<AndyS> Souri: want triple terms restricted to the object position.

<niklasl0> I agree. (Since I think of generlaized RDF as the "entailment space" where that object restriction does not apply.)

<Souri> Thanks. Bye.

<niklasl0> ex:claims owl:propertyChainAxiom ( ex:rolifiedClaimClass rdf:reifies ).

<niklasl0> ex:Claim owl:equivalentClass [ owl:onProperty ex:rolifiedClaimClass ; owl:hasSelf true ] .

<niklasl0> <a> a ex:Claim ; rdf:reifies <<( :s :p :o )>> .

<niklasl0> # Entails => <a> ex:claims <<( :s :p :o )>> .