Why was "broader/narrower" included in the CRM? Similar arguments could
be made about that property, no?

T.

P.S. The example "Good->Average->Bad" and "Very good->Good->Bad" is
indeed a terminology matching exercise, but we still need to reason on
the fact that average condition objects rank before bad condition objects.
On 07/01/2019 09:18, Martin Doerr wrote:
> Dear All,
>
> On 1/7/2019 8:02 AM, Stephen Stead wrote:
>>
>> Hi all
>>
>> Happy New Year
>>
>> The property name: Perhaps we should borrow from the nomenclature of
>> ordinal statistics and use
>>
>> ranked higher than (ranked lower than)
>>
>> Hi Martin
>>
>> Excellent questions!
>>
>> 1] Research questions that are enabled:-
>>
>> I envisaged questions of the form that Athanasios has suggested as
>> well as the opposite; “Where are examples of “x” object type that have
>> a condition of “y” or better that I can have access to for comparative
>> observations”
>>
>> In the map world I also thought of the integration question “During
>> the planning of this expedition was there a map at “x” scale or larger
>> published and available within “y” distance of the expedition
>> headquarters”. This was the type of question envisaged in the Arctic
>> Cloud project.
>>
> I have the impression that these are indeed the only research questions
> at a factual level (about particulars), that are supported by such a
> property. The scope of the CRM is deliberately restricted to this level,
> in order to maintain a clear modularity against, in particular,
> terminological systems. With "broader/narrower" we maintain a minimal
> interface to such systems.
>
> The above examples are about inclusion of categories, yet another much
> more specialized case of getting something of type x and narrower. In
> case of a few qualities, the retrieval problem can easily be solved by
> enumeration. The underlying IT system will anyway do nothing else than
> expanding the "y" or better. The example also shows that the sense of
> the ordering is quite diverse: "better", or "higher resolution" etc.,
> are not implied by one general property. each ordered collection will
> have different senses.
>
> Any ordered collection can be expanded by a set of ((n-1)**2)/2
> "pyramid" of generalizations, which effectively represent the order.
> This solution is effective for smaller sorted sets. Map scales may be a
> different case, the only one I am currently aware of.
>
>>
>> 2] Reasons for CRM rather than SKOS:-
>>
>> As George says we control CRMbase and not SKOS 😊. More substantially
>> the solution of skos:OrderedCollection does not allow the integration
>> of different terms from different sources into the same term ordered
>> collection without physically merging them. While that could be
>> overcome (it scales like a bag of bolts) the more substantial problem
>> is it does not allow branching paths through the collection; for
>> example Excellent > Good > Poor and Excellent > Average > Poor is not
>> possible. Another concern is that all Collections are automatically
>> ordered by their position in the implemented list: that is all
>> collections are ordered even if there is no such ordering in the real
>> world.
>>
> The question of integrating different ordered collections of terms is
> definitely out of scope of the CRM, and a question of terminology
> mapping, and definitely not solved in any way by such a property.
>
> We cannot solve all the problems of the world. We explicitly recommend
> SKOS as complementary, in order to maintain some order between
> standardization efforts. We have discussed with the NKOS group for many
> years the need to standardized specializations of "related term", but
> never could mobilize any larger community to do so. There are some dozen
> candidates, and theoretical issues. Picking up now one of the most
> specialized, poses a serious methodological question, if we aware of the
> scope, relative relevance and further related issues to such a modelling.
>
> We already have to many open fronts in CRM-SIG. We encounter the danger
> not not to control SKOS, but to loose control of the CRM itself. Anybody
> can make a local extension to SKOS, and recommend it, without the SKOS
> team, exactly as anybody can make a local extension to the CRM. There
> may be other models already dealing with the problem.
>
>> 3] Coverage of problems:-
>>
>> Collection management: questions of collection morbidity, storage
>> effectiveness and process validation
>>
>> Museology: Do different collection management regimes materially
>> affect the short, medium and long term collection conservation
>>
>> Material Science: which materials have survived best
>>
>> Cultural Heritage Geo-informatics: What map scales were available,
>> when, for what and for/by whom.
>>
>> Risk Management: What is the current state across institutions. What
>> is the history of risk classification across the
>> domain/region/institution type
>>
>> Audience Research: Many institutions are starting to collect Likert
>> scale data as part of the feedback on exhibitions. This could then be
>> linked to exhibition content to gain insight into the affective museum
>> experience. This is what Erin Canning is working on.
>>
> We should not confuse the question of standardizing ordered value sets
> with providing a link between the terms. The link does not solve that at
> all.
>
> I would argue we are out of scope of CRMbase.
>
> Best,
>
>
> Martin
>
>> Rgds
>>
>> SdS
>>
>> Stephen Stead
>>
>> Tel +44 20 8668 3075
>>
>> Mob +44 7802 755 013
>>
>> E-mail [email protected] <mailto:[email protected]>
>>
>> LinkedIn Profile https://www.linkedin.com/in/steads/
>>
>> *From:*Crm-sig <[email protected]> *On Behalf Of *Martin Doerr
>> *Sent:* 03 January 2019 17:56
>> *To:* [email protected]
>> *Subject:* Re: [Crm-sig] **NEW ISSUE** Ordinal Property for E55 Type
>>
>> Dear All,
>>
>> Very nice all that, but the critical question for a concept to enter
>> CRM base is:
>>
>> What is the scientific question in an information integration
>> environment, that needs this property to make the relevant connection/
>> inference,
>>
>> and further:
>>
>> Why is that proposed for CRM base and not for SKOS?
>>
>> and finally:
>>
>> What is the coverage of problems that benefit from this property?
>>
>> These concerns are part of the methodology we follow, and most
>> substantial. We must make sure they appear in the "principles".
>>
>> Best,
>>
>> Martin
>>
>> On 1/3/2019 7:32 PM, Stephen Stead wrote:
>>
>>     Excellent then the revised property, scope note and examples would
>>     be:-
>>
>>     *Pxx conceptually follows (conceptually precedes)*
>>
>>     Domain: E55 Type
>>
>>     Range: E55 Type
>>
>>     Quantification: many to many (0,n:0,n)
>>
>>     This property allows instances of E55 Type to be declared as
>>     having an order relative to other instances of E55 Type, without
>>     necessarily having a specific value associated with either
>>     instance.  This allows, for example, for an E55 Type instance
>>     representing the concept of "good" to follow the E55 Type instance
>>     representing the concept of "average". This property is
>>     transitive, and thus if "average" follows "poor", then "good" also
>>     follows "poor". In the domain of statistics, types that
>>     participate in this kind of relationship are called "Ordinal
>>     Variables"; as opposed to those without order which are called
>>     "Nominal Variables". This property allows for queries that select
>>     based on the relative position of participating E55 Types.
>>
>>     Examples:
>>
>>       * Good (E55) /conceptually follows/ Average (E55)
>>
>>       * Map Scale 1:10000 (E55) /conceptually follows/ Map Scale
>>     1:20000 (E55)
>>
>>       * Fire Hazard Rating 4 (E55) /conceptually follows/ Fire Hazard
>>     Rating 3 (E55)
>>
>>     How does that seem?
>>
>>     Rgds
>>
>>     SdS
>>
>>     Stephen Stead
>>
>>     Director
>>
>>     Paveprime Ltd
>>
>>     35 Downs Court Rd
>>
>>     Purley, Surrey
>>
>>     UK, CR8 1BF
>>
>>     Tel +44 20 8668 3075
>>
>>     Fax +44 20 8763 1739
>>
>>     Mob +44 7802 755 013
>>
>>     E-mail [email protected] <mailto:[email protected]>
>>
>>     LinkedIn Profile https://www.linkedin.com/in/steads/
>>
>>
>>
>>     _______________________________________________
>>
>>     Crm-sig mailing list
>>
>>     [email protected]  <mailto:[email protected]>
>>
>>     http://lists.ics.forth.gr/mailman/listinfo/crm-sig
>>
>> --
>> ------------------------------------
>>   Dr. Martin Doerr
>>
>>   Honorary Head of the
>>   Center for Cultural Informatics
>>
>>   Information Systems Laboratory
>>   Institute of Computer Science
>>   Foundation for Research and Technology - Hellas (FORTH)
>>
>>   N.Plastira 100, Vassilika Vouton,
>>   GR70013 Heraklion,Crete,Greece
>>
>>   Vox:+30(2810)391625
>>   Email:[email protected]  <mailto:[email protected]>
>>   Web-site:http://www.ics.forth.gr/isl
>
>
> --
> ------------------------------------
>   Dr. Martin Doerr
>
>   Honorary Head of the
>   Center for Cultural Informatics
>
>   Information Systems Laboratory
>   Institute of Computer Science
>   Foundation for Research and Technology - Hellas (FORTH)
>
>   N.Plastira 100, Vassilika Vouton,
>   GR70013 Heraklion,Crete,Greece
>
>   Vox:+30(2810)391625
>   Email:[email protected]
>   Web-site:http://www.ics.forth.gr/isl
>
>
> _______________________________________________
> Crm-sig mailing list
> [email protected]
> http://lists.ics.forth.gr/mailman/listinfo/crm-sig
>
This email and any attachments are intended solely for the addressee and may 
contain confidential information. If you are not the intended recipient of this 
email and/or its attachments you must not take any action based upon them and 
you must not copy or show them to anyone. Please send the email back to us and 
immediately and permanently delete it and its attachments. Where this email is 
unrelated to the business of University of the Arts London or of any of its 
group companies the opinions expressed in it are the opinions of the sender and 
do not necessarily constitute those of University of the Arts London (or the 
relevant group company). Where the sender's signature indicates that the email 
is sent on behalf of UAL Short Courses Limited the following also applies: UAL 
Short Courses Limited is a company registered in England and Wales under 
company number 02361261. Registered Office: University of the Arts London, 272 
High Holborn, London WC1V 7EY

Reply via email to