AW: possible stances with respect to multiple reification

Dear Enrico, all,


I think the examples are quite interesting because they reveal how you would want to understand the reified option for option#1:


So, basically, in your opinion we deal with a semantic condition here which mainly means that reifies is a functional property.


So, going back to your example:

<< :r | :a :b :e >> :c :d .
<< :r | :a :b :f >> :c :d .

could be written as

:r :c :d.
:r :reifies <<:a :b :e>>, <<:a :b :f>>.

But that would also mean, that I(<<:a :b :e>>)= I(<<:a :b :f>>) (if I is the interpretation function mapping the triple term into the domain).

I could live with that, but so far, I always assumed that this option would be a purely syntactical condition, that is, that the example above would be forbidden.
As you know by now, I have big issues putting syntactical condition to a semantic concept (and the fact that this has been done in the past does not make it better). We could either take your way out or go back to referential opacity (except for literals maybe).  I am in no way suggesting that, I am just saying that the syntactic restriction comes with a prize.

But: if we go for that kind of semantic definition (which is a clean solution), is that not too difficult to implement?  Reading again what Peter wrote, I think that was also meant there?

So, a general question: do we talk about a syntactic or a semantic restriction here?

Kind regards,
Dörthe


________________________________
Von: Franconi Enrico <franconi@inf.unibz.it>
Gesendet: Montag, 22. April 2024 17:11:08
An: Jos De Roo
Cc: Lassila, Ora; Peter F. Patel-Schneider; public-rdf-star-wg@w3.org; Thompson, Bryan
Betreff: Re: possible stances with respect to multiple reification



On 22 Apr 2024, at 16:53, Jos De Roo <josderoo@gmail.com> wrote:

On Mon, Apr 22, 2024 at 4:18 PM Lassila, Ora <ora@amazon.com<mailto:ora@amazon.com>> wrote:
Peter,

this is good. I have some questions/observations, though:

Option #1: On some level, we could say those examples are not RDF graphs, but the question in my mind is about how easy/possible is it to detect those cases? Detecting that "abc" :b :c is not an RDF graph is trivial, but the reification case maybe not so much (at least there is a very different implementation burden).

I gave it a try in eye and it is pretty straightforward to detect and throw an exception.
For instance uncommenting line 9 or line 16 in
https://github.com/eyereasoner/eye/blob/4c35d85322ecfe6c5a71e9e60a3cbfd964f7e9b3/reasoning/temp/edge.ttl

throws a malformed_edge_extra_reifies/3 exception.

Mmmhhh.
Let’s first try to understand via some examples what is “illegality” of “multiple reification”.

Is this graph illegal? I would say yes.
<< :r | :a :b 42 >> :c :d .
<< :r | :a :b 43 >> :c :d .

Is this graph illegal? I would say no.
<< :r | :a :b _:x >> :c :d .
<< :r | :a :b _:y >> :c :d .

Is this graph illegal? I would say no.
<< :r | :a :b :e >> :c :d .
<< :r | :a :b :f >> :c :d .

Is this graph illegal? I would say no.
<< :r | :g :h :e >> :c :d .
<< :r | :m :n :f >> :c :d .

—e.

Option #3: Saying "can cause problems" is somewhat vague. Again, when do you find out that there is a problem? What if we have an implementation that simply refuses to ingest the "single reifier multiple triples" -style graph? That would be a different kind of problem than the :range example you give (ingestion vs. reasoning).

I really would like to see how far we could take the idea of "well-formedness". I understand it may not be easy to formalize, but I am sure we could do better than what people say about pornography ("I cannot define it but I know it when I see it"). Implementations could accept non-well-formed graphs, or reject them. In case they do accept them, outcomes could be unpredictable (ranging from practically nothing to annoying or worse). People building systems that rely on predictable behavior on non-well-formed graphs would be "on their own".

Ora


On 4/22/24, 9:22 AM, "Peter F. Patel-Schneider" <pfpschneider@gmail.com<mailto:pfpschneider@gmail.com> <mailto:pfpschneider@gmail.com<mailto:pfpschneider@gmail.com>>> wrote:


CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.






I would find it useful to have an enumeration of the possible stances with
respect to multiple reification. I see four:


1/ Multiple reification is completely illegal so
<< :r | :a :b 42 >> :c :d .
<< :r | :a :b 43 >> :c :d .
is not an RDF graph, just as
"abc" :b :c .
is not an RDF graph.


2/ Multiple reification is possible but something to be avoided, like
:l rdf:first "abc" .
:l rdf:first "def" .
:l rdf:next rdf:nil .
is a valid RDF graph but is to be avoided or similar to
:age rdfs:range xsd:int .
:liz :age "abc" .
is a valid RDF graph but is to be avoided. That is, these graphs do not make
sense for any purpose.


3/ Multiple reification is possible but can cause problems and thus should not
be encouraged, like
:r rdfs:subPropertyOf rdfs:subPropertyOf .
:r rdfs:subPropertyOf rdfs:subClassOf .
is a valid RDF graph but can cause problems or
:age rdfs:range xsd:int .
:liz :age :f .
is a valid RDF graph but can cause problems. That is, anyone who creates
these graphs should understand the consequences of what they are doing.


4/ Multiple reification is possible and has no negative connotations, like
:liz :married :dick .
:liz :married :eddie .
is a valid RDF graph and has no problems as far as RDF is concerned.




I have a preferred stance here, a stance I cannot live with, one I can live
with, and one I am uncertain about.


peter


-- https://josd.github.io<https://josd.github.io/>