– DRAFT –
RDF Star WG Semantics TF

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

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

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

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

https://w3c.github.io/rdf-concepts/spec/#h-note-5 -- the SHOULD text in RDF Concepts

<doerthe> I would make rdf:TripleTerm instead of rdf:tripleTerm, but that is it :)

<niklasl> <<( :s :p :o )>> owl:sameAs <<( :s :p :o )>> .

<niklasl> owl:sameAs a rdf:reificationProperty, rdf:InverseReificationProperty .

<niklasl> <<( :s :p :o )>> a rdf:Reifier .

_: r rdf:reifies <<( :s :p :o )>> ; rdfs:label "Reifier?" .

<<(: s :p :o )>> rdf:isReifiiedBy _:r ; rdfs:label "What is this?" .

<Souri> I find having triple-term as subject confusing. For example, << :s :p :o >> :p1 "hello world" => "hello world" is a reifier. How critical is it to allow triple-term in subject position (instead of restricting it to object position only)?

<doerthe> I won't answer directly because I respect the queue, but I really like the subject position but I simply don't see that adavantage

<doerthe> I will queue :)

<doerthe> what if I want to simply put a label on my triple term?

<niklasl> Want or need? (I can actually sort of see that nicety in a very specific application, but I imagine it requiring at least symmetric RDF; e.g. labels for literals?)

<Souri> We cannot have an inverse datatype property. Why can't we put a similar restriction on reification properties?

<niklasl> "2024"^^xsd:gYear rdfs:label "Twenty-twentyfour"@en .

<tl> but uniprot would like to get away from RDF/XML, and use RDF-star to replace their reliance on RDF/XML's ID attribute

RDF/XML is used downstream of Uniprot in an ecosystem so it is very sticky.

ditto CIM FWIW (currently) although that has less of a need of reification.

<doerthe> I would be very happy with the should

<niklasl> ... jsOn too ;)

Is this for RDF entailment, not simple entailment?

<doerthe> but the XML-argument is of course something to think about... It is new

<doerthe> I would like to also hear Adrian

RDF/XML can be changed to have triple terms - it's not impossible.

<Zakim> Souri, you wanted to say MUST makes sense

RDF/XML can be changed to have triple terms in the subject position - it's not impossible.

<doerthe> mmm, I would like to know more because I have not enough background on RDF-XML

FYI One way is to allow rdf:parseType="TripleTerm" on rdf:Description.

<niklasl> Interesting... But rdf:parseType is on the predicate element now though?

<doerthe> I remember that Souri also made an implementation argument for their systems in general?

<Souri> In RDFn, I was proposing the name (reifier) as the (optional) fourth item: :s :p :o | :r .

niklals - rdf:parseType is only in the object (i.e. on a predicate) today but what it does is create a (nested) RDF term.

and is not predicate specific.

<niklasl> Ah; true. That and a reverse are interesting...

<Zakim> TallTed, you wanted to say We can't break "the appendix of RDF history" in RDF 1.2; that would require RDF 2.0.

<Zakim> pfps, you wanted to say that RDF/XML cannot represent all of RDF even now

<niklasl> E.g. predicates local name 123

<gb> MERGED Pull Request 123 Tweak language and markup for clarity (replicated) (by hartig)

<Zakim> tl, you wanted to say that the ID attribute in RDF/XML supports RDF standard reification very well. If we design the unstar mapping as a mapping t RDF standard reification (which is the way we'll most ptobably take, if we do it at all) , then there is a good bridge

<doerthe> maybe the json-ld argument by gkellogg is stronger?

I agree with doerthe - JSON-LD makes a stronger argument than RDF/XML (due to its growth on the web)

<enrico8> +1 on the JSON-LD argument

<doerthe> just to you tl: the whole json-ld and RDF-XML discussion could spare us from our discussion 8and we have strong opinions, so maybe more healthy for us :) )

<doerthe> I get that one :)

<doerthe> and you, niklasl, actually brought me to agreement on the SHOULD

Can we agree to define semantics in the symmetric case?

<doerthe> mmm, but are we postponing the discussion by that AndyS, apart from that, yes

<tl> option one, which i voted for, was based on reification :->

I hope it is a step forward for this group.

<niklasl> The potential power of rdf:reifies plus OWL to bridge different modelling granularity should not be overlooked.

<doerthe> OK, I support that

<niklasl> AndyS, yes I hope that can work.

If RDF/XML,JSON-LD are sufficient argument in the whole WG, it least then semantics is general. AKA an honest separation of concerns.

<niklasl> That (abstract syntax for concrete syntaxes, symmetric RDF for semantics) might clarity my (wobbly) "affordance/ergonomics" perspective.

three places (1) semantics (2) data model (3) syntaxes

<gkellogg> Should be "Any triple whose object ..." rather than "Every"

<doerthe> could we maybe also point out the problem with the syntaxes somewhere, maybe a small example why it is so difficult in JSON-LD and RDF-XML?

<Souri> Could you put the URL here?

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