Re: AW: proposal: a reifier should reify only one "thing"

Hi Pierre-Antoine, all,

I could perhaps settle for this; I am just not entirely convinced that
it is *necessary* in general (and if it is, that means something very
important I want to draw out).

The important question is: what are the expected rdfs:domain classes
of the properties used to describe these reifiers? And I do very much
agree that it must be open-ended in the RDF spec (any resource with an
rdf:reifies relation to a(...) triple term).

The notion of "edge properties" (or hypergraphs for that matter) seems
misleading to me. The edge concept is so close to the graph structure
that it seems to put the domain of discourse in the background. And
that is where these reifier concepts belong. Only by assessing those
domain entities (pipe or flight connections, friendships, marriages,
collaborations) can we make sense of what is needed, even if only in
marginal edge cases (puns very much intended).

I'm looking for *examples* to test the "many-to-what" question (I
mentioned one about a book collaboration in Ora's LinkedIn thread
[1]). Here is another (admittedly made up, and hoping that it will be
"intuitively illustrative" enough, in spite of me not being much of a
plumber):

    <pipe/a> :connectedTo <pipe/c> .
    <pipe/b> :connectedTo <pipe/c> .

    <connection/abc> a :TJunctionConnecton ;
      :connectorType :TJunction5000 ;
      :control :GaugeValveC62 ;
      rdf:reifies <<( <pipe/a> :connectedTo <pipe/c> )>>,
          <<( <pipe/b> :connectedTo <pipe/c> )>> .

What I really don't want is to have to "lecture" practitioners that
their more concrete "annotation" entities have to be "sufficiently
binary in essence". Would it really be simpler--or easier to
explain--that "Yes, a socket is OK, but a T-junction is not; you need
to model those parts of the junction separately, linking to it, to
stay LPG-compliant"? Perhaps I'm exaggerating here to make my point,
but I honestly do worry about having to *unnecessarily* "lecture" (in
either case).

It *may* be better to model binary granularity up-front, but that does
not seem to have a clear, domain-independent method behind it, or does
it? (I can't see how it could, when we're decidedly going for *more*
granularity when we reify...) Or is the method just the line drawn by
existing LPG implementations?

I still wonder if the edge notion in LPGs is much more like option 4,
entailing option 1 (see [2]), if only in *structure*, not in *meaning*
(since examples tell a different story). And experience has shown that
the common *intuitions* about what an rdf:Statement is occasionally
fail to disambiguate between the "abstract relationship token" and
something more concrete in the domain. I would argue that the
intuitions about "edge properties" are effectively the same in this
regard. Graph edges do not have dates, right (unless you're, say,
animating a graph)?

Aside: I'm much more interested in potential interoperability between
datasets using different granularities, and whether these reifiers can
bring those cases closer together. A dataset rewritten using the more
granular model would reasonably make this a "thingified" N-ary entity,
replacing the too simple `:connectedTo` properties with:

      <connection/abc>
        :incomingPipe <a>, <b> ;  # and here be sockets to reify if
needs arise...
        :outgoingPipe <c> .

Taking proposed semantics for triple terms into account [2], I end by
leaving these sketched axioms as an exercise for the interested:

        :incomingPipe rdfs:subPropertyOf :reifiesSubject .
        :outgoingPipe rdfs:subPropertyOf :reifiesObject .

        :reifiesSubject rdfs:subPropertyOf :implicates;
            owl:propertyChainAxiom (rdf:reifies rdf:subject) .
        :reifiesObject rdfs:subPropertyOf :implicates;
            owl:propertyChainAxiom (rdf:reifies rdf:object) .

Best regards,
Niklas

[1]: <https://www.linkedin.com/feed/update/urn:li:activity:7183830084854632448/>
[2]: <https://htmlpreview.github.io/?https://github.com/w3c/rdf-star-wg/blob/main/docs/seeking-consensus-2024-01.html>



On Thu, Apr 18, 2024 at 9:55 AM Pierre-Antoine Champin
<pierre-antoine@w3.org> wrote:
>
> Hi Felix,
>
> On 18/04/2024 08:03, Sasaki, Felix wrote:
>
> About
>
> „
>
> I'm more and more convinced that 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

Received on Thursday, 18 April 2024 15:58:11 UTC