LDP properties like member and contains should not promote or allow the use of literals. about carbonldp-workbench HOT 4 CLOSED

The Document Explorer is agnostic to particular restrictions on properties or classes. It will remain that way until the platform supports dynamic property validation.

Also, unless constrained by an ontology like owl, you CAN add literals. They may not make sense to an application but they may make sense to another one. That's why any application that uses linked data should never assume that a property will be of only a specific type or will hold only a specific number of values.

That being said, if you go ahead and add a literal, the platform should return a BadRequest because it does impose restrictions on some properties.

from carbonldp-workbench.

I disagree with this statement:

"They may not make sense to an application but they may make sense to another one."

Given that the property URI is from a specific vocabulary and the purpose of the property is known, it will make little sense for any application to use the property another way.

I can understand if the component used in the document explorer is agnostic. However, the component is not our product. In the context of the document explorer as used against Carbon LDP, the restriction should be enforced for the sake of usability.

You said, for example:

"That being said, if you go ahead and add a literal, the platform should return a BadRequest because it does impose restrictions on some properties."

An element that cannot be used should not be available. It creates visual noise, makes the user think, and can confuse the user. If the user tried an interaction using an element that has no chance of succeeding, it makes no sense at all for the element to have ever been shown.

This is also based on concrete feedback from a user who spent significant time in this area being confused. They were trying to figure out how to add children to a document and could not find the functionality to do it. They assumed that, since the labels were "member" and "contains" that this might be the area to do it. Not being familiar with LDP concepts, perhaps also not even familiar with the difference between "literal" and "pointer", the user attempted to use the elements to create a child document and wrestled with that particular area for several minutes.

from carbonldp-workbench.

I don't disagree on implementing the restriction of the values of properties like ldp:member, ldp:contains, etc.

My point is, right now we haven't implemented the dynamic validation of resources. Without that system, the workbench wouldn't have a way to tell if the property can only have URIs, strings or something else as values. Meaning that we would need to hard code the rules on the web application, hard coupling it to the logic of the platform.

This may seem simple in cases like ldp:member or ldp:contains, but it won't be so simple with other validations the platform makes. For example, should the user be allowed to add to <agents-container> ldp:member a resource that isn't of type cs:Agent?

Or should we restrict the user from modifying the vcard:email unless the value is a proper email address (even if that would still mean it is of the right xsd:string type)?

Basically, if you start hard coding rules, how do you define where should you stop?

Because of this, I think it is better to wait for the platform to have the dynamic validation system in place. That way the workbench could download the rules and based on that restrict what you can do in the Document Explorer.

Also, there's an upcoming feature for creating child documents on any particular document which I think will remove our users original confusion.

from carbonldp-workbench.

Closed in favor of #69

from carbonldp-workbench.