Refactor the property management to make them independent from the OClass and unique by pair:"name:OType" in the whole database.
The OClass should refer to the global properties and not have them embedded.
The properties should be kept stored in the metadata independently to the OClass reference, together with the "schemaless property".
Similar pattern is used in the Semantic Schemas ex: http://schema.org/address
+1 for this, this way RDF concepts can map even more neatly to OrientDB
Could you please take a look into following issue?
This issue seems to me the first step for discussed in that issue. Is this right? Are you supporting ideas described in that issue?
Thanks for your reply in issue #2521!
But I have some concern regarding this one. It seems to me that moving property management from class to DB significantly narrows functionality. Let me explain.
For example we have several classes ("ClassA" and "ClassB") and each of them have property "name" of STRING type. It looks OK to have "links" from ClassA and ClassB to a single property "name:STRING".
But you are loosing ability to specify meta parameters on a properties on per class basis. For example if on application layer you should store somewhere in a meta model "validation rules" or "visialisation characteristics" on per class->property basis - you can't do that! It'll not be possible, for example, to have max 25 chars in name for ClassA and max 100 chars in name for ClassB.
I'm working on data-warehousing system Orienteer (https://github.com/PhantomYdn/Orienteer). This system use pretty natural for OrientDB notation and approach. And on other hand, I'm trying to provide quite generic functionality to work with objects in the system: for example user is able to select "property" which will play role of name of a object (object's name is used in links to a object) or select other "property" which play role of "link to parent" or "links o child". Alos it's possible to specify on a property how that property should be "rendered" and how it can be "modified". And it's done through custom parameters on properties, but it's assumed that properties managed on class layer. If they will be "shared" among classes: that will break functionality a lot...
But I have proposal.
To have ability to "share" properties between classes is cool in any case. It'll be helpfull even in Orienteer to let users "make less" in properties configuration if they can be share between classes. But there should be a possibility to have different properties with the same "name" on different classes. To allow that: some other field a long with "property name" and "property type" should be used in PK. I recommend to let users manually specify that additional "thing" if they want to limit visibility of that property to some particular class or even subset of classes. Something like "PK suffix".