compared with
Key
This line was removed.
This word was removed. This word was added.
This line was added.

Changes (6)

View Page History

* Mitac: I probably don't fully understand the problem: crm:P2_has_type is not a chain property, only rso:PS2_has_type is. Thus when we fetch P2 for an object it will return its direct types (painting, coin). Both the explicit and the implicit triples match. So, we can simply show P2 while when searching we should search by PS2.
-- Vlado: PS2 will be removed in this iteraton, to be replaced by FR2. Anyway, we're discussing the direct properties here, not the property chains. We disentangled all "type" properties, but will you single out the "object type" to show it amongst the "search result display fields"?
* Joshan: I agree with the second solution also.  The thesaurus that the term belongs to defines what the semantics is (not just the predicate of P2_has_type).  Could this not be translated into a rule whereby if the ConceptScheme of a term used by P2_has_type is an 'object type thesaurus' (-this may differ from org to org) then assert an rso:PS2_has_type.  As I mentioned to Vladimir (and as he has mentioned on many occasions), there seems to be an issue of modelling using CRM & providing display/search functionality.  How do we add extra ontology vocab to allow display & search?  I was suggesting:
*# MODELLING: perform pure CRM modelling to model the dataset (irrelevant of display/search purposes)
*# ENGINEERING: use *rules* (like the one above) to assert research space ontology entities to allow display/search funtionality
- By doing this, would allow a clean separation between modelling and application requirements by using rules.  I'm aware this may be an ideal and too simplistic, but could it solve majority of issues like this?
-- Vlado: whether we implement the "singling-out" with with a rule or a query is a second decision. We're still discussing how to represent the "object type" field.
-- BTW Josh you *will* have to do the same disentangling as we did (eg by defining BMO extension properties of P2), else data annotation won't work over BM data. See the detailed explanation below.

By doing this, would allow a clean separation between modelling and application requirements by using rules.  I'm aware this may be an ideal and too simplistic, but could it solve majority of issues like this?



(!) Jana, can you explain here *why* one property should not have multiple properties from several thesauri?
- Jana: The reason was a design decision that I have never been too happy with - to recognize thesaurus for new values from the existing values.
-- That is, if we need to propose a new value for has_current_keeper, for example, we fetch existing values, get the thesaurus they belong to and present the user with autocomplete component that searches values exactly from that thesaurus.
-- Keep in mind that for Stage 4 this won't work as we will have to implement entering objects from scratch. As a long term solution, we need some meta information about what thesauri are suitable for each property.
-- As a short term improvement, we may suggest values from multiple thesauri in the new value autocomplete - if needed - similar to the way it will be done in the search sentence.
- Vlado: I know all this, but I wanted an in-depth answer to my question above.
What's the problem for P2_has_type to have value1 from thes1 and value2 from thes2? Can't the user propose a value new2 for value1 from thes1, and separately for thes2?
Now that I asked the question explicitly, I can answer it myself ;-) There's no problem to propose a new value, but two new values will get tangled. The system cannot know whether new1 applies to value1 or value2, since the association is by rdf:subject and rdf:predicate, but not by thesaurus.
- Jana, please comment which alternative above you prefer.

Jana: The reason was a design decision that I have never been too happy with - to recognize thesaurus for new values from the existing values.

That is, if we need to propose a new value for has_current_keeper, for example, we fetch existing values, get the thesaurus they belong to and present the user with autocomplete component that searches values exactly from that thesaurus.

Keep in mind that for Stage 4 this won't work as we will have to implement entering objects from scratch. As a long term solution, we need some meta information about what thesauri are suitable for each property.

As a short term improvement, we may suggest values from multiple thesauri in the new value autocomplete - if needed - similar to the way it will be done in the search sentence.

{status:colour=Red|title=spec}{status:colour=Red|title=diff}{status:colour=Red|title=mig}{status:colour=Red|title=rforms}