Dear Robert, all,
On 1/7/2019 7:00 PM, Robert Sanderson wrote:
I agree with Thanasis. If ranked_higher_than / ranked_lower_than is
out of scope when there are clear use cases across the range of
domains covered by the CRM, then it seems that narrower and broader
should be deprecated in favor of SKOS and simply leave E55 Type as the
merge point.
Well, I think that needs a more detailed discussion. broader/narrower is
the fundamental semantics of thesauri, and can hardly be compared in
relevance to the ranking property proposed, or others such as BTP etc.
But indeed, we explicitly declare in the CRM that detailed modelling of
terms, i.e., meta-properties, is not intended so far in the CRM.
Another need that we have for this is description of material
qualities for conservation reference collections, where some materials
are more/less flammable, acidic, dangerous or similar than others
without a clear scale. My original proposed modeling solution was to
use a dimension but that was not deemed appropriate due to the lack of
reproducible measurement, however in order to find “more flammable
than” we need to either use a dimension or to have this ranking.
Sure, I have *NOT questioned at all* the need for this property. I have
argued for keeping CRMbase in a reasonable frame. I am further not
convinced that this property is actually the cure for all fuzzy and
discrete ranking problems. I simply find it not yet well studied.
One absolutely vital question of methodology is how to restrict by
functional criteria a module of an ontology. Otherwise, we end up in a
great mess many other teams have encountered, and we started with in the
first days of the CRM.
I disagree with Martin’s assertion about what information systems will
do. If the property is declared as transitive, then with inferencing
in a graph store, all you need to do is search for ranked_higher_than
to find all of the higher ranked resources. Compared to using an
rdf:List, which is notorious for being hard to use in queries.
My argument was different: a) we can use broader/narrower if we add a
"pyramid" of broader terms on ranked lists.
B) If the properties is transitive, the triple or graph store will
collect all respective terms internally, and then query them. That was
my argument. About difficulties using a list in queries, well, it is a
question of UI.
By the way, the scale of maps is defined in LRM as a property. So we
should look at this first. Why do we need a scale of a map? Because on
paper, it is an indication of the resolution, but not the actual
resolution. This becomes more and more obsolete with digital maps, and
is equally inadequate for very old maps.
All the best,
Martin
And a Happy New Year to everyone ☺
Rob
*From: *Crm-sig <[email protected]> on behalf of Athanasios
Velios <[email protected]>
*Reply-To: *Athanasios Velios <[email protected]>
*Date: *Monday, January 7, 2019 at 1:59 AM
*To: *"[email protected]" <[email protected]>
*Subject: *Re: [Crm-sig] **NEW ISSUE** Ordinal Property for E55 Type
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]>
<mailto:[email protected]>
LinkedIn Profile https://www.linkedin.com/in/steads/
<https://www.linkedin.com/in/steads/>
*From:*Crm-sig <[email protected]
<mailto:[email protected]>> *On Behalf Of *Martin Doerr
*Sent:* 03 January 2019 17:56
*To:* [email protected] <mailto:[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]>
<mailto:[email protected]>
LinkedIn Profile https://www.linkedin.com/in/steads/
<https://www.linkedin.com/in/steads/>
_______________________________________________
Crm-sig mailing list
[email protected]
<mailto:[email protected]> <mailto:[email protected]>
http://lists.ics.forth.gr/mailman/listinfo/crm-sig
<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]> <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] <mailto:[email protected]>
Web-site:http://www.ics.forth.gr/isl
_______________________________________________
Crm-sig mailing list
[email protected] <mailto:[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
_______________________________________________
Crm-sig mailing list
[email protected] <mailto:[email protected]>
http://lists.ics.forth.gr/mailman/listinfo/crm-sig
_______________________________________________
Crm-sig mailing list
[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]
Web-site: http://www.ics.forth.gr/isl
