Open World Assumption reference not clear in note 2 in ¶3.4

[bblfish]

Given the nature of the notification payload, consumers may want to take precautions when ascertaining the veracity of the contents. The open-world assumption applies here.

I am not sure how the open world assumption is relevant to the point there.

[rhiaro]

Open world is in reference to AAA. This statement is intended to mean "anyone can say anything about anything, so be careful what you believe".

[bblfish]

I would refer to AAA in that case, since that is what you mean :-) The Open World Assumption is usually opposed to the closed world assumption which states that if a database does not make some statement about S then it is not true. If a database lists all the states in the USA then if something is not in that DB it's not a state. The point you are making is not I think related. Here you just mean that you should either try to authenticate the user and state that the user made said statement in the newly published resource, or if the server wishes to accept the content of the statement and integrate it into its knowledge base, make sure the contents have been verified. Or else suffer the consequences of a bad reputation.

[csarven]

Thanks, sounds good to me. Updated: s/open-world assumption/anyone can say anything about anything in d627e9b . Are we good to go with this issue?

[bblfish]

I found a reference to AAA in https://www.w3.org/TR/2004/REC-rdf-concepts-20040210/#section-anyone

I am not sure that Anyone can say Anything about Anything is a framework. Rather it was a design requirement of the semantic web.

What this does bring up though is the question as to how one can make sure one attributes to the person posting information in an inbox that the information posted there came from them, so that it is not mistakenly attributed to the web server owner for example.

[csarven]

The consumer doesn't need to make that inference i.e., the sender put something in the inbox and the receiver didn't touch it. The consumer simply comes across an inbox to find notifications. There may be constraints involved on the Inbox (set by the receiver) which address sender's verification etc.. If the constraint is advertised, the consumer can purpose it for their needs. I think this is orthogonal.

[bblfish]

I think this is orthogonal.

yes, I think that is why you have that note. It's actually something that needs to be thought through though.... If not in this spec, then somewhere else.

[csarven]

Okay, how about 044330d ? I think that covers the general intention of this note. If you have specific wording you'd like to see, happy to push that in.

[bblfish]

Writing specs is really difficult...

Given the nature of the notification payload, consumers may want to take precautions when ascertaining the veracity of the contents. The anyone can say anything about anything Web principle applies here.

Mhh I think you should specify the "nature of the notification payload" upfront, which is that depending on the restrictions placed on publication to the container, either anything can be posted
or very specific content can be posted. But there does not seem to be a convention as to how this is yet expressed so that the consumer has no reliable way of finding this information - ie. it's not part of the protocol - and so far as the protocol goes, anyone can write anything.

consumers may want to take precautions when ascertaining the veracity of the contents

that's oddly put. Why should they take precautions when ascertaining the veracity of the contents? Why is that moment a moment to take precautions, and what precautions should they take? It seems that the issue is one of proper attribution of the contents to someone. In a sense the
client reading this does not know who made the statement. Since anyting can be posted to an LDP Container, what seems to be missing is a way to specify who made the statement.

Perhaps that is where an extra "Author:" header would be very useful, where the server would be able to specify who the Author of the content it had verified was.

Unless otherwise specified, there is no indication as to whether the original payload was altered by the receiver.

I would write "inbox" instead of "receiver" as the inbox is the receiver, and the extra generality is confusing and does not add anything useful since every actor will at various stages be the receiver of information.

Btw. Do ldp:BasicContainers not presuppose that nothing gets altered?

It seems to me that because ldp:BasicContainers presuppose nothing gets altered, and since inboxes can receive messages from anyone, there needs to be an LDP way of making clear who wrote the message. An Author header would solve that problem.

[rhiaro]

Mhh I think you should specify the "nature of the notification payload" upfront

Okay, how about a rephrase to:

"Consumers should be aware that anything can be posted to an Inbox (depending on restrictions in place by the receiver, which are not defined by this protocol), so when it comes to making use of notification data consumers may want to take precautions when ascertaining the veracity of the contents."

It seems that the issue is one of proper attribution of the contents to someone. In a sense the
client reading this does not know who made the statement

Maybe I'm wrong, but I think that attribution is only one possible way of determining the truth of a statement. One might be able to verify it against claims in a datastore one already trusts, without needing to know who was behind the statement in question. So that's why it's more a general sense of "don't necessarily believe everything you read in an inbox, and maybe have something in place for deciding how you're going to use the content"

there needs to be an LDP way of making clear who wrote the message. An Author header would solve that problem.

I totally agree his would be useful, but should probably be discussed in LDPNext, rather than LDN.

[bblfish]

Maybe I'm wrong, but I think that attribution is only one possible way of determining the truth of a statement. One might be able to verify it against claims in a datastore one already trusts, without needing to know who was behind the statement in question. So that's why it's more a general sense of "don't necessarily believe everything you read in an inbox, and maybe have something in place for deciding how you're going to use the content"

You are right. Mathematical statements can be verified without needing to know anything about who wrote them.

But if you think of this as a game, then it become clearer why it is important to know who (or what agent/actor) said/wrote something. After all we are dealing with a protocol here, where an agent can POST something, and so also can be excluded from POSTing something. It is agents that can be allowed GET access or denied it. It is also agents that build up reputation.

So the issue here is not that agents give you access to truth, but that they are the players in the game of reading and writing, a game where increasing one's reputation with a group is at stake, as that is what gives you access to information.

Now it may be that you want your spec to be very minimalist, essentially only defining the meaning of ldp:inbox and how it ties into LDP basic containers. I wonder how much of an interoperable spec one can get in that case...

Still back to your proposed text:

"Consumers should be aware that anything can be posted to an Inbox (depending on restrictions in place by the receiver, which are not defined by this protocol), so when it comes to making use of notification data consumers may want to take precautions when ascertaining the veracity of the contents."

I would write instead

Consumers should be aware that within the limits set by each particular ldp:BasicContainer, any content can be posted to the inbox. Furthermore this specification does not require the Container to do any verification of the content. The Inbox owner should therefore be careful as to who can read the notifications as the contents of some may damage his reputation.

That may start to address the issue...

there needs to be an LDP way of making clear who wrote the message. An Author header would solve that problem.

I totally agree his would be useful, but should probably be discussed in LDPNext, rather than LDN.

Perhaps you can produce a note of a few things that would have made it possible for you to go further in your protocol, so that LDP next can have some idea as to why they need to focus on it.

[rhiaro]

Sorry for the delay on getting back to this.

I want to avoid explicit references to LDP in notes like this, as LDP isn't technically required for LDN, just compatible. I also think that mentioning "reputation" is a bit specific, and not the only thing at stake. Also the "inbox owner" and the consumer are not necessarily the same, and it is the consumer which 'uses' the notifications. So given that, I updated the wording with what I initially proposed; we resolved at the f2f that this best addresses the ambiguity without adding any additional complexity.

Perhaps you can produce a note of a few things that would have made it possible for you to go further in your protocol, so that LDP next can have some idea as to why they need to focus on it.

I imagine one of us will be participating in LDPNext after SWWG has wound down.

[bblfish]

fine to close this (though I have not been paying much attention to what is going on here since around the time of posting the initial report)