Revamps in Hydrus

There are a list of things in Hydrus that I think needs some discussion. So I am opening a new issue about it.

1. When creating a GraphIAC relation, the value of property inserted by the client is a class name which could create conflicts in the meaning of the value (the client meant it as a string value, the server would interpret it as a reference to a class). I think it would be more appropriate to use an id or a value which has a clear semantic that it refers to a class.
2. The properties entered in the database are unique by name. We can have a property whose semantic would depend on the class it is used on. (eg. A property may be abstract for one class, an instance property for another)
3. A property entered in the database has no pre-defined type. Its type is dependent on its value, the first time it is used to insert an object in the server.
4. #226 made sure that all the required properties are present while inserting an object. But we have no checks to make sure that no property is inserted which are not supported by a class (i.e which is not present in the supportedProperty list of a class)

[chrizandr]

Here are a few comments:

1. GraphIAC uses the internal class IDs to link the classes, not strings, so there is no ambiguity there. If you see the models, it is listed as a foreign key. Also, like I said before none of the models that include classes: GraphCAC, GraphIAC; are accessed by the client. This data is not served at any endpoints so there is no actual need for them to have IDs. They are for internal use only to define the graph. We still don’t have a use case for them.
2. Most semantic properties, both RDF and OWL based ones have a domain and range attribute defined(http://www.linkeddatatools.com/properties), of course to implement these constraints on properties we would have to dereference the URIs and parse the property definitions to be able to find the correct subject and object for the defined property. Right now, all we need to make sure is that the property is used as per the API Doc, we need not worry about their “actual” definitions, more on this in point 4.
3. This is true, because we don’t really know the kind of subjects/objects that the property uses(It is not defined in the API Doc, not always). So we guess the properties type based on the data. This was more of a workaround back when I was trying to figure out how to assign a type to the property. I think we can find a more robust method for this. Let’s try and come up with some solutions and we can discuss on here.
4. This is an important thing that we need to work on. I have already mentioned in some previous issues that we can have a API_Doc.validate() method that does all the sanity checks needed for an object.

[Mec-iS]

About https://github.com/HTTP-APIs/hydrus/issues/358#issuecomment-477025040

This kind of long reply are really well suited to become part of the documentation, if they are not yet. Please consider opening a PR on http-apis.github.io adding this information in the right file or creating a new file.