Re: possible stances with respect to multiple reification

Option 1 does change the definition of an RDF graph from "any set of RDF 
triples" to add a condition.  Checking this condition does require some 
resources and does change the computational complexity of the checking process.

Option 3 is somewhat vague out of necessity, I believe.   There are lots of 
potential problems that are covered here and I don't know of a succinct way of 
categorizing them all except in vague terms.

I did not discuss well-formedness because that adds a potential second choice 
and, I think, tends to muddy the waters.   My view is that the first thing to 
do is to determine the space of choices.

I am against stating that well-formedness is something that might be used to 
limit what an RDF implementation accepts.  In my view that will either split 
the RDF space or (worse) choke off non-wellformed RDF graphs.

peter


On 4/22/24 10:17, Lassila, Ora 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).
> 
> 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>> 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
> 
> 
> 
> 
>

Received on Monday, 22 April 2024 15:22:28 UTC