- From: Pierre-Antoine Champin <pierre-antoine@w3.org>
- Date: Thu, 18 Apr 2024 09:54:42 +0200
- To: "Sasaki, Felix" <felix.sasaki@sap.com>, RDF-star WG <public-rdf-star-wg@w3.org>
- Message-ID: <2a600f6a-3929-46c0-a742-33eef55f4444@w3.org>
Hi Felix, On 18/04/2024 08:03, Sasaki, Felix wrote: > > About > > „ > > I'm more and more convincedthat a reifier _should_ not reify several > things > > „ > > And > > „ > > * it is not enforced syntactically (the following is valid RDF: :t > rdf:object :s1, :s2. ), > * it is not enforced semantically (the example above does not entail > :s1 owl:sameAs :s2 ). > > “ > > What RFC2119 language would you then use for the “_should_” in your > statement? > At this point I'm not advocating for any RFC2119 language about this constraint, if it has no impact on compliance as suggested above. I could however live with something in the line of "For a given subject, rdf:reifies SHOULD not have multiple values. Note however that this does not prevent a graph to contain several triples with the same subject, the rdf:reifies predicate, and syntactically distinct objects, if these objects are considered to denote the same thing." best > Best, > > > Felix > > *Von: *Pierre-Antoine Champin <pierre-antoine@w3.org> > *Datum: *Donnerstag, 18. April 2024 um 01:18 > *An: *RDF-star WG <public-rdf-star-wg@w3.org> > *Betreff: *proposal: a reifier should reify only one "thing" > > Hi all, > > after writing my response to Phil [1], which is a refinement of the > arguments I made last Friday [2], I'm more and more convinced that a > reifier should not reify several things, because it would lead to > wrong expectations ("this is similar to a named graph, right?") and > counter-intuitive inferences (again, see my example in [1]). > > That being said, I would have this constraint /only/ expressed the > "intended meaning" of the rdf:reifies predicate -- in a way very > similar to rdf:subject, rdf:predicate and rdf:object. Reading the > description of these predicate in [3] strongly hints at the fact that > they are supposed to have only one value each ("[rdf:subject] is used > to state *the* subject of a statement"), but > > * it is not enforced syntactically (the following is valid RDF: :t > rdf:object :s1, :s2. ), > * it is not enforced semantically (the example above does not entail > :s1 owl:sameAs :s2 ). > > The arguments against such an enforcement (syntactic or semantic) have > been largely discussed already, I won't repeat them here. > > Finally, I want to emphasize that, although I advocate that a reifier > should reify only one thing, I would like to remain very vague on what > kind of "thing" that is, and how many (syntactically) distinct triples > would actually identity that thing. > > For example, from the following graph > > :r rdf:reifies > <<( dbr:Linköping dbo:populationTotal 104232 )>>. > > it would seem appropriate to infer (under D-entailment where > xsd:integer ∈ D) > > :r rdf:reifies > <<( dbr:Linköping dbo:populationTotal 104232 )>>, > <<( dbr:Linköping dbo:populationTotal 00104232 )>>. > > (I believe that it would be the case with the semantics currently > proposed by Enrico). > > From the following graph > > :r rdf:reifies > <<( :alice :knows :bob )>>. > :knows a owl:SymetricProperty. > > MAYBE it would be appropriate to infer > > :r rdf:reifies > <<( :alice :knows :bob )>>, > <<( :bob :knows :alice )>>. > > From the following graph > > :r rdf:reifies > <<( :alice :worksWith :bob )>>. > :worksWith rdfs:subPropertyOf :knows. > > MAYBE it would be appropriate to infer > > :r rdf:reifies > <<( :alice :worksWith :bob )>>, > <<( :alice :knows :bob )>>. > > I don't have a definite answer for the two examples above, and I don't > think that we need to answer them urgently. I'm just pointing out that > we have some leeway even if we settle on "a reifier reifies only one > thing". > > pa > > [1] https://www.w3.org/mid/d39fcb64-66d6-4cbe-9453-a52d1cbd5259@w3.org > [2] https://www.w3.org/2024/04/12-rdf-star-minutes.html#x169 > [3] https://www.w3.org/TR/rdf11-schema/#h3_ch_reificationvocab >
Attachments
- application/pgp-keys attachment: OpenPGP public key
Received on Thursday, 18 April 2024 07:54:45 UTC