Re: summary un/asserted

Hello everyone. Longtime lurker, first-time poster. :)

On 7/9/2024 3:43 AM, Thomas Lörtsch wrote:
> For example, we may want to document and comment on a statement without endorsing it. We write
>
>      << :s :p :o >> :a :b .
>
> If however that same statement is also to be part of the graph, for whatever reason, like so:
>
>      << :s :p :o >> :a :b .
>      :s :p :o .
>
> there is no way to express that the annotation is meant to refer to an unasserted statement.
> There are many situations in which this problem might occur: we might want to document different viewpoints or versions, graphs might be merged or updated, adding the fact, etc.
> Thomas

Apologies if this use case is already clear to most, but why would you 
need to express that an annotation is meant to refer to an unasserted 
statement"? I had a good go-round with ChatGPT on this question, and we 
couldn't come up with any satisfactory examples.

Similarly...


On 7/10/2024 5:55 AM, Thomas Lörtsch wrote:
> But I also want to be sure that adding that fact (because of/by some
> other reason, or circumstance, or context, or user) doesn’t overwrite
> the implication of my initial annotation to not
> endorse/state/assert/"fact-ualize" that statement.

What implication(s)? It seems like, given the open world assumption, 
people will just have to assume that their unasserted triple might get 
asserted down the road. But again, I can't think of examples of what we 
miss without being able express that an annotation is meant to refer to 
an unasserted statement.

My understanding is, if there no (or very little) value in being able to 
express that an annotation is meant to refer to an unasserted statement, 
we are all set with reification not triggering assertion, and you can 
just assert a statement if you want it asserted.

Thanks.

-dave