Okay, my last message on the topic and I’ll move on.
By overloading P2 to describe the state of a separate resource from the one
that the type is associated with, any instance in which there are multiple
relationships to the resource with the Type will result in ambiguity.
The dimension is tied to the object in a 1:1 relationship, thus there is no
ambiguity. But as soon as you have 1:n, such as if there are several
properties or the same property with several different resources, it’s
ambiguous as to which of the related resources the type applies to.
Imagine a photograph of three paintings, two of which are framed. The image
carried by the photograph is a representation of the first two paintings in
their framed state, and the third in an unframed state. So I have to record
the meaningless Image P2 framed-state, unframed-state :(
It is certainly arguable that CRM is too complicated where it doesn’t matter,
and not complicated enough where it does.
Rob
On 4/13/17, 12:37 PM, "martin" <[email protected]> wrote:
Dear Robert,
I do not get the point. The frame has a URI, and the frame of the frame
another. The aggregate painting - frame-1-frame2 has another URI from
the painting-frame-1. If you measure painting-frame1, you do not measure
painting, etc. How many frame-frames do you have? Do I miss something?
Anyway, any ambiguity is local to the object, a simple photo is much
better than a great logical model.
This is a principle by the way: Do not overmodel details that have no
bearing beyond the thing itself.
The important thing is to model relations to distant things correctly,
for instance, who may have seen this object in the past, does someone
keep a part of it I do not know, where may it come from? where does the
technique come from?
Half of the potential CRM clients do not use it because it is too
complicated, and the other half, because it is not complicated enough;-)
Best,
Martin
On 13/4/2017 9:10 μμ, Robert Sanderson wrote:
> I agree… and the activity is the non-identity-changing manipulation of
the object, resulting in an outcome. I can describe the activity (opening the lid,
framing/unframing the painting), but I can’t describe the outcome of that activity.
>
> And I was unclear about Photograph as MMO versus Image carried by an
individual print … Images can have frames in the same way that physical carriers
do. You do make my point though – there is ambiguity when multiple distinct things
(the object as a persistent entity, the state of the object at a point in time)
are described in one cluster of attributes.
> The state of the object at a point in time is a distinct intellectual
resource from the persistent entity because assertions made about it would not be
true of the object as a whole, and vice versa.
>
> Consider the trivial assertion: The framed painting is composed of two
parts, the canvas and the frame.
>
> Following the P2 method to the logical conclusion:
>
> Painting a ManMadeObject ;
> is_composed_of Frame, Canvas ;
> has_dimension D ;
> has_representation I .
>
> D a Dimension ;
> has_type Framed . // meaning the dimension describes the framed
painting
>
> I a Image ;
> has_type Framed . // meaning the image is of the framed painting
>
> Frame a ManMadeObject ;
> has_type Framed . // meaning this part is part of the framed painting.
>
>
> Now imagine you take that Frame and put it inside another Frame…
>
> Frame a ManMadeObject ;
> has_type Framed . // meaning this frame is framed, not that the
parent painting is framed
>
> And we have resulted in an ambiguous state of what is framed.
>
> QED?
>
> Rob
>
> On 4/13/17, 10:31 AM, "Stephen Stead" <[email protected]> wrote:
>
> The integration point in your first scenario is the set of
activities that are done together: The measurement and the creation of the
immaterial object that documents the measurement activity. It is an interesting
step to move away from the object centric modelling we have done for years to
event-centric modelling paradigm of the CRM.
>
> In your second example I would suggest that there should be a clear
distinction between the immaterial object that documents one part of a complex
object and the physical carrier of that immaterial object. Then there is no
ambiguity. The ambiguity only comes when to many distinct things are described in
one cluster of attributes.
>
> HTH
> SdS
>
> Stephen Stead
> Tel +44 20 8668 3075
> Mob +44 7802 755 013
> E-mail [email protected]
> LinkedIn Profile http://uk.linkedin.com/in/steads
>
> -----Original Message-----
> From: Crm-sig [mailto:[email protected]] On Behalf Of
Robert Sanderson
> Sent: 13 April 2017 17:15
> To: martin <[email protected]>; Dominic Oldman
<[email protected]>
> Cc: crm-sig <[email protected]>
> Subject: Re: [Crm-sig] ISSUE: States and Situations
>
>
> The potential for ambiguity comes in when the pattern is adopted
more generally for resources other than Dimension. Consider this scenario:
>
> As a conservator, I measure the [now wearing thin] chest with the
lid closed, and I take a photograph of it in that state. I then open the chest’s
lid, measure the chest with the lid open and take a photograph in that state.
>
> Without an entity to represent the state of the chest, as a data
modeler, I have to use the Type as the integration point between the dimensions
and the photograph. Thus I associate the lid-open type with the Dimension
(meaning that the Dimension is of the Object in the state Lid-Open), and with the
Photograph (meaning that the Image depicts the Object in the state Lid-Open) so I
can cross-reference with the Dimension). If there is a type that applies to both
Image and Object, it would be ambiguous which it applied to… and the same for any
other resource that should be associated such as a Title, Description, etc.
>
> How about … the ambiguity of the dimensions of a Framed Painting
(Dimension P2 Framed), with a Framed photograph (Photograph P2 Framed -- meaning
the photograph) of the Unframed Painting (Photograph P2 Unframed -- meaning the
painting)?
>
> {
> "@type": "ManMadeObject",
> "dimension": {
> "@type": "Dimension",
> "has_type": "x:Framed" // meaning the MMO measured in “framed”
state
> },
> "has_representation": {
> "@type": "Image",
> "has_type": "x:Framed" // ambiguous whether the Image is framed
or the MMO depicted is framed
> }
> }
>
> This sort of ambiguity is typically solved by having a new entity
which can have dimensions and representations (and titles, and…) associated with
it, which is my “State” … I don’t care about the name, and am happy to change the
definition to philosophically aligned … but the current “just use P2 to tag
everything” seems to either result in an infinity of interrelated Types (making
them no longer usable) or likely ambiguity when applied to real world use cases.
>
> Rob
>
>
> On 4/12/17, 12:41 PM, "martin" <[email protected]> wrote:
>
> Dear Robert,
>
> As we said, each measurement procedure defines a new Dimension type. In
modern physics it became very clear that measurements in general do interact with the object
itself. Therefore, do not separate the "state" from the procedure. E.g., if you
measure the
> voltage of a battery with a Voltmeter, each Voltmeter with a
different inner Ohm resistance will give you another value with very different
diagnostic utility (a personal experience by the way, that puzzled me once for
days!). Putting an object in a rectangular
> adjustable box gives you another height than the maximum
spatial extent, and depending on the softness and elasticity, you may be quite
puzzled by what you measure.
>
>
> Therefore, we really do recommend that "lid-open" and "lid-closed" are
two different types of Dimension, and that you describe with sufficient text and graphics or photos what that
each type means ("is documented in"). Then, you simply measure the Dimension
> "lid-open" etc. I believe that defining artificial states are
not of any help to do that better, but if you give me a query that you regard as relevant
that can be answered
> only your way, can make clear how the state itself would be
defined in an unambiguous way, and that this is possible for all kinds of
measurements, I'll be glad to be convinced:-)!
>
> All the best,
>
> Martin
>
> On 12/4/2017 6:49 μμ, Robert Sanderson wrote:
>
>
> Hi Dominic, Martin,
>
> Here’s two concrete use cases … how do you suggest that they be
described in CRM?
>
> 1. The object is a manuscript and for storage reasons I want
to know the dimensions of it when closed (also this is the typical set of
dimensions), and for exhibition planning reasons I want to know the dimensions of
it when open, so I can lay it out in a display case.
>
> 2. The object is a chest with hinged lid that sits, at rest,
either completely open or completely closed. Same reasons as above – I want to
display it open, but store it closed, so need to know the total height of the
chest with the lid closed versus open.
>
> Clearly there are many possible states for these objects that
would result in different measurements – the height of the manuscript would depend
on the number of pages turned, and the lid could be propped open to just about any
height.
>
> The difference with the skyscraper heights is that the
skyscraper is not being manipulated to produce the different dimensions, they’re
just heights of different parts. You could measure and record them separately and
calculate the different totals. The wooden tea caddy is also interesting
regarding state … let me propose a simpler case though:
>
> 3. An umbrella can be folded into a cylinder needing length and
radius dimensions, or open into (err…) an umbrella shape probably needing height,
width and depth dimensions.
>
> This case requires two _sets_ of dimensions to go together. Say
that it’s a very carefully constructed umbrella where the appearance when folded
is black, but the appearance when open is multi-colored. Same umbrella in two
states, each of which has multiple properties beyond just dimensions.
>
> If the P2 is the approach for the Dimension … is it also that
we’d associate the same Type with a descriptive text for the color?
> (And for all other features we want to describe about the same
state?)
>
> Rob
>
> On 4/12/17, 8:18 AM, "Dominic Oldman" <[email protected]>
<mailto:[email protected]> wrote:
>
> Dear Rob, Martin
>
>
> A Comment:
>
>
> Dimension is defined as a measurable extent of any kind. This
could be the distance between two points on an object. I think this is the way it is
also described in the CRM reference, e.g. "This
> class comprises quantifiable properties that can be measured by
some calibrated means and can be approximated by values, i.e. points or regions in a
mathematical or conceptual space..."
>
>
> Skyscrapers tend to have different types of height
dimension. For example, height to tip (where there is a spire or needle), height
to architectural top, height to highest occupied floor. These are all different
dimension types measuring from one point
> to another on a building.
>
>
> However, on the specific example, do I want to describe a
state of 'openess' or am I just opening the lid to make it more convenient to
measure the different dimensions of the same box which really hasn't changed -
height to top of closed lid, height
> to top of open lid. As Martin mentions the box is
specifically opened in order to take a particular type of dimension measurement.
The example of measuring these dimensions without opening the lid at all e.g
taking two measurements in a closed position and
> adding them together) is also an important indicator that
we don't really need to get into a state and I expect for many fragile items the
measurement is done in this way - practically indicating that this is simply a
type of dimension.
>
>
> I measured my tea caddy this morning. I measured with the "lid
on" to the point where the lid starts and then again to the top of the lid. I then took
the lid off and measured the main body of the caddy again. It was the same measurement as
when the lid
> was on! It is the same caddy and the measurement was not
affected. When I took the lid off it didn't really change the properties
particularly. The two measurements, one to the top of the main caddy body and one
to the top of the lid are two different dimensions
> of the same thing, like the skyscraper. If the caddy was
made of wood then these measurements might change in different conditions like,
for example, heat and humidity compared to freezing conditions. In this case the
same dimensions might have a different
> result but that would be a different situation.
>
> If I could only measure a dimension on the bottom of the
box by turning the box over, is this a dimension of a particular state (i.e.
upside down state)? - perhaps in common usage but this isn't the same as the
context we talk about.
>
>
> I agree that the world is constantly changing (and our
understanding of it changes). However, taking a slightly different line, it is not
necessary, in my opinion, to be exhaustive in order to describe a valid and useful
type of totality. Some things are
> more useful than others. I would therefore agree that we
need to be careful about the use of states as this could have quite problematic
implications for which, as Martin says, we are not equipped to deal with and
technology hasn't really helped with (perhaps
> made worse), but in any event we don't need.
>
>
> I think we should update the definition of S16 - its a bit
thin but I think it could be updated to a better state. :-)
>
>
> D
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> orcid.org/0000-0002-5539-3126
<http://orcid.org/0000-0002-5539-3126> <http://orcid.org/0000-0002-5539-3126>
>
>
>
>
>
>
>
> On Tue, Apr 11, 2017 at 6:37 PM, Robert Sanderson
> <[email protected]> <mailto:[email protected]> wrote:
>
>
> As in physics, you can know either the state of objects in
the universe or the forces that act upon them, but never both ( The proposal
takes the former as more valuable for the work that we are attempting to do –
describe the state of objects in our care
> either for conservation purposes or for simple descriptive
purposes. The CRM seems to try to model the ephemeral forces, to the exclusion of
the things being acted upon.
>
> By which I mean that E11 Modification enables the
description of the transforming force (the opening of the lid) but does not allow
the identification of the resulting state.
>
> _:LidOpening a Modification ;
> has_type <lid-opening> ;
> has_modified <box> ;
> carried_out_by <conservator> ;
> had_specific_purpose _:measurement1, _:measurement2 ;
> has_timespan <time> .
>
> _:measurement1 a Measurement ;
> measured <box> ;
> observed_dimension _:height .
>
> _:height a Dimension ;
> has_type <height> ;
> has_value 20 ;
> has_unit <inches> .
>
> _:measurement2 a Measurement ;
> measured <box> ;
> observed_dimension _:width .
>
> _:width a Dimension ;
> has_type <width> ;
> has_value 15 ;
> has_unit <inches> .
>
> We have described the forces … the actions … of lid-opening
and measuring, and linked the observed dimensions … but nowhere is there an entity
that IS the box with its lid open. We need to understand the LidOpening action’s
purpose in order to deduce that
> the measurements, although they are of the box, pertain to
some un-identified state of that object. We do not have anywhere to associate even
a label “Box with Lid Open” with those measurements.
>
> We would not want to say that the opening of the lid
somehow destroyed Box-with-Lid-Closed and created Box-with-Lid-Open (e.g. E81
Transformation is not appropriate)
>
> Rob
>
> On 4/11/17, 7:13 AM, "martin" <[email protected]>
<mailto:[email protected]> wrote:
>
> Dear Robert,
>
> The point I try to make is that we are easily confusing
reality with
> description, and partial knowledge with reconstruction
of what is in
> between:
> To my understanding, the very existence of a state is
an intellectual
> working back from the parameters of the observation.
> Whereas the reality does not change, things evolve,
move, interact as
> they do, the definition of state thereupon changes with
the definition
> of the properties we apply to describe these things.
The objective thing
> is the observation, the "state" an extrapolation of the
latter. To start
> constructing a state, which in the sequence is
observed, turns to my
> opinion things upside down. The lid is removed in the
course of the
> measurement in order to measure thedimension without
lid, and it was not
> observed that the lid was removed before the
observation. The latter has
> a completely different status, a "criminalistic one":
Who put down the lid?
>
> Once the state is produced by the activity to measure,
it does not have
> an ontological identity of its own.
> Further, all the positions the lid can have wrt the
container are
> continuous in space. The is nothing to mark
> a specific position which everybody would recognize as
being distinct
> from all others. Only by specifying artificially a
position range as
> "lid open", it can be described and observed. Any
definition of
> "lid-open-ness" produces another state on the very same
unambiguous
> reality. Measuring the container without the lid may
not even require
> removing the lid at all.
>
> Therefore, I'd say your solution is not as effective or
necessary to
> describe the respective measurement.
> "States" are a "treacherous" concept in a world which
we all very well
> know is never anywhere at rest. The art of ontology
engineering is using
> the concepts that produce the most robust identities as
reference under
> change of context and purpose, and not what we regard
as the most
> analytical ones. We are all tempted in this culture to
try to describe
> the world exhaustively by atomic elements, but no one
has ever succeeded
> to do so ;-).
>
> Comments?
>
> Best,
>
> Martin
>
> On 11/4/2017 2:18 πμ, Robert Sanderson wrote:
> > A clearer example, reversing the for_state predicate,
demonstrating it follows the same pattern as parts:
> >
> > X a ManMadeObject ;
> > label “Chest” ;
> > was_in_state S ;
> > composed_of P .
> >
> > S a State ;
> > label “A particular state of X”
> > has_type <lid-open-ness> ;
> > has_timespan T ; // when X was in this State
> > has_dimension D ;
> >
> > D a Dimension ;
> > label “Height of X with lid open” ;
> > has_value V ;
> > has_unit U .
> >
> > P a PhysicalObject ;
> > label “Lid of X”
> > has_dimension D2 .
> >
> > D2 a Dimension ;
> > label “Height of Lid of X”
> > has_value V2 ;
> > has_unit U2 .
> >
> >
> > On 4/5/17, 6:08 PM, "Robert Sanderson"
<[email protected]> <mailto:[email protected]> wrote:
> >
> >
> > Thanks Martin, as always :)
> >
> > So I agree completely, but we seem to have come
to different conclusions?
> >
> > The way I think about the procedure is as
follows:
> >
> > X is an object.
> > At time T, X was in a state S.
> > When in state S, object X was measured.
> > The measurement activity M, performed by actor
A, resulted in a dimension D, with value V and unit U.
> >
> > And for the majority of these capital letters I
can trivially assign CRM classes … other than state S.
> >
> > X: the box (Man Made Object)
> > T: 2015-09-10 (TimeSpan)
> > S: upright, lid open (?????)
> > M: the activity (Measurement)
> > A: curator ( Person)
> > D: the Dimension with P2 of height (Dimension)
> > V: 14 (Number)
> > U: inches (Unit)
> >
> > Or something like …
> >
> > X a ManMadeObject ;
> > has_state S ;
> > has_dimension D .
> >
> > S a State ;
> > label “Lid Open” ;
> > has_type (external Type for lid-open) ;
> > timespan T .
> >
> > D a Dimension ;
> > has_type <height> ;
> > for_state S ;
> > has_value 14 ;
> > has_unit U .
> >
> > (and add in the Measurement activity in the
obvious way, if desired)
> >
> > I agree that we should not try to catalog the
vocabulary level of all possible states of all possible types of object (!!) but it
seems to me (and I believe to others) like a valid concern with practical use cases
and requirements, that a simple
> P2_has_type on the Dimension would not be sufficient to
solve.
> >
> > Rob
> >
> > On 4/5/17, 11:41 AM, "martin" <[email protected]>
<mailto:[email protected]> wrote:
> >
> > Deasr Robert,
> >
> > No, the issue is very serious. The Dimension
is ultimately determined by
> > the procedure.
> > "Height with box open" is not a label, but
the very type of dimension.
> > This is not a work around.
> > It is a substantial understanding of what a dimension
is. "height" is
> > not a dimension. It has not verifiable
identity condition.
> >
> > Using P2 has type must never be interpreted as
"little regard", but as a
> > need for further standardization.
> > But I am sorry I do not see a way to
formalize in another way the
> > potential complexity of measurement
procedures. When they become
> > comparable, they must be categorical, and
then they form a type. If you
> > cannot agree on standard measurement
procedures, you cannot compare
> > results, isn't it? At least my understanding
as an experimental
> > physicist by education;-)
> >
> > All the best,
> >
> > martin
> >
> >
> > On 3/4/2017 10:35 μμ, Robert Sanderson wrote:
> > > Thanks Martin :)
> > >
> > > If I understand correctly, both the type
of dimension (height vs width) and the state of the object being measured (lid-open vs
lid-closed) would both end up as external P2_has_type URIs?
> > >
> > > _:h a Dimension ;
> > > label “Height of the box with the lid
open” ;
> > > has_type <height> , <lid-open> ;
> > > has_value 14 ;
> > > has_unit <inches> .
> > >
> > > And as the width doesn’t change depending on
<lid-open> or <lid-closed> ness:
> > >
> > > _:w a Dimension ;
> > > label “Height of the box with the lid
open” ;
> > > has_type <width> , <lid-open>,
<lid-closed> ;
> > > has_value 8 ;
> > > has_unit <inches> .
> > >
> > > It seems a little jarring to have a core museum
activity being treated with (from my perspective) little regard, compared to some of the existing
distinctions made between classes with very little practical value. When the <height> and
<lid-open>
> URIs are not understood, let alone the unit URI, the only
thing the ontology actually captures is the value… and as E60 can be a string,
there’s not all that much value (ha!) there either.
> > >
> > > When the answer to all questions is “Just
put it in P2”, doesn’t that give one pause that P2 is so broad as to be meaningless?
> > >
> > > Rob
> > >
> > >
> > > On 4/3/17, 12:16 PM, "martin"
<[email protected]> <mailto:[email protected]> wrote:
> > >
> > > Dear Robert,
> > >
> > > The standard way to describe this in
the CRM is to type the Dimension
> > > with the procedure:
> > > a) Lid-open
> > > b) Lid-closed
> > >
> > > The Measurement procedure type can be
documented by a detailed text.
> > >
> > > In biology, one would measure "wingspan at
life" and "winspan dead" of a
> > > bird, etc.
> > >
> > > Best,
> > >
> > > martin
> > >
> > > On 3/4/2017 7:13 μμ, Robert Sanderson
wrote:
> > > > Dear all,
> > > >
> > > > One of our use cases which we are
having trouble modeling with just the core CRM ontology is measurements of an object in a
particular state. For example, we would like to record the measurements of a chest with
the lid open, rather
> than those with the lid closed. It is the same object,
just in two different states, resulting in different measurements.
> > > >
> > > > The proposed scope note does
certainly clarify more than the rather terse original, but if there is any feedback or
guidance as to the above situation, we would be greatly appreciative.
> > > >
> > > > Many thanks,
> > > >
> > > > Rob
> > > >
> > >
> > > --
> > >
> > >
--------------------------------------------------------------
> > > Dr. Martin Doerr |
Vox:+30(2810)391625 <tel:%2B30%282810%29391625> <tel:%2B30%282810%29391625> |
> > > Research Director |
Fax:+30(2810)391638 <tel:%2B30%282810%29391638> <tel:%2B30%282810%29391638> |
> > > |
Email:
> [email protected] <mailto:[email protected]>
<mailto:[email protected]> |
> > >
|
> > > 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 |
> > >
|
> > > Web-site:
> http://www.ics.forth.gr/isl <http://www.ics.forth.gr/isl>
<http://www.ics.forth.gr/isl> |
> > >
--------------------------------------------------------------
> > >
> > >
> > >
> >
> >
> > --
> >
> >
--------------------------------------------------------------
> > Dr. Martin Doerr | Vox:+30(2810)391625
<tel:%2B30%282810%29391625> <tel:%2B30%282810%29391625> |
> > Research Director | Fax:+30(2810)391638
<tel:%2B30%282810%29391638> <tel:%2B30%282810%29391638> |
> > | Email:
> [email protected] <mailto:[email protected]>
<mailto:[email protected]> |
> >
|
> > 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 |
> >
|
> > Web-site:
> http://www.ics.forth.gr/isl <http://www.ics.forth.gr/isl>
<http://www.ics.forth.gr/isl> |
> >
--------------------------------------------------------------
> >
> >
> >
> >
> >
>
>
> --
>
>
--------------------------------------------------------------
> Dr. Martin Doerr | Vox:+30(2810)391625
<tel:%2B30%282810%29391625> <tel:%2B30%282810%29391625> |
> Research Director | Fax:+30(2810)391638
<tel:%2B30%282810%29391638> <tel:%2B30%282810%29391638> |
> | Email:
> [email protected] <mailto:[email protected]>
<mailto:[email protected]> |
>
|
> 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
|
>
|
> Web-site:
> http://www.ics.forth.gr/isl <http://www.ics.forth.gr/isl>
<http://www.ics.forth.gr/isl> |
>
--------------------------------------------------------------
>
>
>
>
> _______________________________________________
> Crm-sig mailing list
> [email protected]
> http://lists.ics.forth.gr/mailman/listinfo/crm-sig
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> --
>
> --------------------------------------------------------------
> Dr. Martin Doerr | Vox:+30(2810)391625 |
> Research Director | Fax:+30(2810)391638 |
> | Email: [email protected] |
> |
> 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 |
> |
> Web-site: http://www.ics.forth.gr/isl |
> --------------------------------------------------------------
>
>
>
>
> _______________________________________________
> Crm-sig mailing list
> [email protected]
> http://lists.ics.forth.gr/mailman/listinfo/crm-sig
>
>
>
--
--------------------------------------------------------------
Dr. Martin Doerr | Vox:+30(2810)391625 |
Research Director | Fax:+30(2810)391638 |
| Email: [email protected] |
|
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 |
|
Web-site: http://www.ics.forth.gr/isl |
--------------------------------------------------------------
