Open ExarcaFidalgo opened 3 years ago
Further commented on https://github.com/weso/rdfshape-client/issues/59 . I like the second option.
For starters, there were some problems with the usage of symbols (".", ":", "/", "<"...) and Mermaid, which was unable to process any of them. The original solution involved the codification of such symbols: therefore, the following Shape:
:User {
:name xsd:string;
:age xsd:int ?;
:gender [:Male :Female];
:knows @:User ;
:worksFor @:Company ;
:buys @<Product> {1,10};
}
Would be transformed to:
class ___dp___User {
___dp___User : ___dp___name "xsd___dp___string\\"
___dp___User : ___dp___age "xsd___dp___int\\"
}
___dp___User --> ___dp___User : ___dp___knows
___dp___User --> ___dp___Company : ___dp___worksFor
___dp___User --> " {1,10}" ___anga___Product___angc___ : ___dp___buys
___dp___User <|-- ___dp___Ultrauser
___dp___Titanuser *-- _Blank1 : AND
___dp___User <|-- ___dp___Titanuser
After creating the diagram, the terms would return to their original state by a search and replace method, looking for the codes. However, whereas this makes the symbols usable, the UML boxes would remain unnaturally wide, due to the trimming of the terms. There was some work behind the scenes to adjust the texts, but it was noticeable that something was off.
It became clear to me that this was not the chosen path when I played around with patient.shex, which possessed things like:
<http://hl7.org/fhirpath/System.String>;
It transformed into this horrific monstruosity from the plains of Oblivion.
___anga___http___dp______bar______bar___hl7___dp___org___bar___fhirpath__bar___System___pt___String___angc___
Truly a sight to behold. Obviously, the resulting class was insulting.
So, I have made an strategic, unprecedented move such as using my cognitive abilities. Now we replace every symbol with "_" (the single one accepted) so that the length remains unbothered. We save the original value in a Map, with the sanitized value as key. Therefore, after generating the diagram, we just look in the Map for the original terms. Nice and clean:
class _User {
_name "xsd_string\\"
_age "xsd_int\\"
}
_User --> _User : _knows
_User --> _Company : _worksFor
_User --> " {1,10}" _Product_ : _buys
_User <|-- _Ultrauser
_Titanuser *-- _Blank1 : AND
_User <|-- _Titanuser
class _Blank1 {
_titancode "xsd_string\\"
}
And even with common shapes, the visual upgrade is noticeable. Original vs corrected:
(Yes, there have been changes about the way logical operations work when there is only one shape involved)
By clicking a class, one can now highlight it as well as the relations which have such class as source, as well as their end class. It provides a way to clearly see a subset of shapes in a bigger diagram.
Algunas sugerencias de Labra:
There are some clear limitations to the standard SVG output. Large inputs, such as the infamous genewiki.shex, result in a excessive quantity of entities and relations, which make for a complex and hard to navigate diagram.
Labra suggested this, which is quite an interesting option, myself being inclined to it.
I'm afraid such utility will have to be done from scratch, and looking at the way relations are done... we're in for a ride.