System.Uri is a very useful type in the framework and in most cases it does the job. Unfortunately, it's current implementation, Equals to be specific, complies with the RFC 2616 (HTTP) that states that that 'The URI MUST NOT include a fragment', thus all instances of the System.Uri that differs only with the fragment are considered as equal.
This behaviour is not welcome in our cases, thus we introduced the RomanticWeb.Entities.EntityId type to overcome this issue, but we built it upon the System.Uri, thus it's very tempting to use RomanticWeb.Entities.EntityId.Uri property rather than the EntityId instance itself leading to issues with Iri equality.
I think it might be improve the code readability and it would save us further issues if we drop (at least some) connections to the System.Uri class in favour of the current EntityId (which could in future be elevated to a true IRI implementation, as semantic web formally works on IRI's).
System.Uri is a very useful type in the framework and in most cases it does the job. Unfortunately, it's current implementation, Equals to be specific, complies with the RFC 2616 (HTTP) that states that that 'The URI MUST NOT include a fragment', thus all instances of the System.Uri that differs only with the fragment are considered as equal.
This behaviour is not welcome in our cases, thus we introduced the RomanticWeb.Entities.EntityId type to overcome this issue, but we built it upon the System.Uri, thus it's very tempting to use RomanticWeb.Entities.EntityId.Uri property rather than the EntityId instance itself leading to issues with Iri equality.
I think it might be improve the code readability and it would save us further issues if we drop (at least some) connections to the System.Uri class in favour of the current EntityId (which could in future be elevated to a true IRI implementation, as semantic web formally works on IRI's).