- From: Franconi Enrico <franconi@inf.unibz.it>
- Date: Wed, 11 Dec 2024 09:42:38 +0000
- To: Thomas Lörtsch <tl@rat.io>
- CC: Andy Seaborne <andy@apache.org>, "public-rdf-star-wg@w3.org" <public-rdf-star-wg@w3.org>
- Message-ID: <AD315DF4-5DD0-4EBA-8B7F-1FA265897D20@inf.unibz.it>
On 10 Dec 2024, at 23:15, Thomas Lörtsch <tl@rat.io> wrote: IMHO, we shouldn’t have such an exception, so to capture the (debatable) case: :s rdf:reifies “John loves Mary” . I don’t understand what you are arguing for. In my understanding nothing but a triple term makes sense in the range of rdf:reifies. There are two issues here: * do we allow literals to be object of rdf:reifies? * IMHO, this should be possible in a “liberal” approach. Otherwise we go straight to some less liberal well-formedness - which is also fine. * should any object of rdf:reifies be a rdf:Proposition (or some other special name)? * I’d say yes, but of course if you expect that triple terms should appear only as object of rdf:reifies (which we should not!), then the notion of rdf:Proposition would be redundant in this case since it coincides with triple term. A triple term may play several roles. When object of rdf:reifies, it plays the role of being reified. In the future, we can imagine that a triple term plays (also) the role of an element of a named graph - and we should not block this possible future. For this reason, I believe that a triple term should be marked accordingly: 1. by using rdf:Proposition (if the name seems misleading, we can choose another one) if it is object of rdf:reifies; 2. in a possible future by using, e.g., rdf:TripleInNamedGraph, when used for this purpose. Example: _:r rdf:reifies <(:john :wife :mary)>. _:r rdf:reifies <(:mary :husband :john)>. _:r a :marriage. <(:john :wife :mary)> a rdf:Proposition. <(:mary :husband :john)> a rdf:Proposition. (in a hypothetical future) _:g rdf:hasTriple <(:john :wife :mary)>. _:g rdf:hasTriple <(:mary :husband :john)>. _:g a rdf:NamedGraph. <(:john :wife :mary)> a rdf: TripleInNamedGraph. <(:mary :husband :john)> a rdf: TripleInNamedGraph. Also, note that not all triple terms are also propositions: this happens only if a triple term appears as an object of rdf:reifies. Really? In my understanding a triple term always, in any position and with any predicate, describes a statement (of a certain type) without stating it. Sure, but here rdf:Proposition was meant to mark triple terms used by some reification process. Maybe we should change the name. And in exactly that way it is used in the range of rdf:reifies. So why give it another type there? I understood or discussion in last Friday’s Semantics TF that all triple terms are of type rdf:Proposition, to dismabiguate them from rdf:Statement. Sure, the idea was that triple terms used in a reification are rdf:Proposition, exactly to disambiguate them from rdf:Statement, but this does not imply that all triple terms, regardless from their use are rdf:Proposition. cheers —e. On 09/12/2024 17:23, Franconi Enrico wrote: We had an interesting Semantics TF meeting last Friday, and we concluded a couple of things: 1. It would be interesting to consider, instead of the currently approved alternative baseline, a simpler more “liberal” approach: a new property rdf:reifies is introduced, which is used to express reification - namely the relationship between a reifier (sometimes called “token") and an abstract triple term. In order to express reification, *only* the rdf:reifies (or any sub property of it) could be used. Other usages of triple terms (namely without being object of a rdf:reifies property or of any of its subproperty) is not forbidden (hence the name: “liberal” approach), but they would not be having the meaning of a reification. 2. We discussed the possible type of the object of rdf:reifies: it could be rdf:Proposition. This is captured - with many details still to be discussed - in <https://github.com/w3c/rdf-star-wg/wiki/RDF-star-%22liberal-baseline%22 <https://github.com/w3c/rdf-star-wg/wiki/RDF-star-%22liberal-baseline%22>>. —e.
Received on Wednesday, 11 December 2024 09:42:44 UTC