Issue 260: Review specializations of Appellation

ID: 
260
Starting Date: 
2014-04-04
Working Group: 
3
Status: 
Open
Background: 

When the crm-sig closed the issue 233 in Hague meeting, they decided that someone should write an issue about which specializations of appellation should be removed. 

30th CRM-SIG meeting, Hague April 2014

Current Proposal: 

In the 32nd joined meeting of the CIDOC CRM SIG and ISO/TC46/SC4/WG9 and the 25th FRBR - CIDOC CRM Harmonization meeting the crm-sig, reviewing this issue,  has  noted that a class definition in CRM must not depend on the incidental association of its instances with another entity instance. The sense of subclasses of Appellation has been misinterpreted in that sense. the discourse about inferring the class of something identified by a special kind of identifier appears to be exotic after years of CRM applications.

This would justify putting this stuff into an extension  about Named Entity resolution and TEI.
Steve, Arianna Ciula, Øyvind, will elaborate this issue by reviewing the subclasses of E41 Appellation.

Posted by Oyvind on 20/5/2015

Some preliminary notes, sorry about being late, of course:

1. Add to E41 scope note, this paragraph:

“Specific subclasses of E41 Appellation should be used when instances of E41 Appellation of a characteristic form are used for particular objects. Instances of E49 Time Appellation, for example, which take the form of instances of E50 Date, can be easily recognised.”

this addition:

“Thus, the use of subclasses of E41 is not determined of the characteristics of the object the appellation refer to, e.g., a person or a place, but rather the form of the appellation showing it as a special type of an appellation, such as a place name or person name.”

2. Subclasses of E41

E35 Title: scope note misleading. It refers to something functioning a title, not having the form of a title.

E42 Identifier: scope note misleading. It refers to something functioning as an identifier, not having the form of one.

E44 Place Appellation: scope note correct (“any sort of identifier characteristically used to refer to an E53 Place”) but could be clearer.

E49 Time Appellation: scope note correct but could be clearer, as E44.

E51 Contact Point: I think the scope note is OK, but not sure how clear it is.

E75 Conceptual Object Appellation: scope note correct and clear (“by their form or syntax specific to identifying instances of”). Use this phrasing on the others?

E82 Actor Appellation: scope note correct but could be clearer, as E44.

3. Putting stuff in extension?

It would be good to know more about current use of these subclasses, partly to examine how they are (mis]used, partly to know if any of them are not used very much.

As for what should be in the extension I must admit I do not really remember the details. 


Posted by Arianna Ciula on 20/5/2015

Hi Øyvind,

Thanks for this. I am in a hurry now but since I know the meeting is already taking place I prefer to reply with something quick than nothing.

I think you addition is god but there is a typo:
- the use of subclasses of E41 is not determined of the characteristics of the object --> the use of subclasses of E41 is not determined **by** the characteristics of the object

Based on your addition as example we could maybe use a place name used as toponymic surname. This would be a case of E44 Place Appellation despite the fact that it is naming a person. For example in the Fine Rolls we had many cases like the following:
Isabella d'Aubigny (Alban', Alben', Albin', Albini, Albiniac', Albiniaco, Albyn) [Aubigné, Saint Aubin d', dep. Ille-et-Vilaine, France]

For clarity 'd'Aubigny' is the toponymic surname; within round brackets you have the textual variants and within the square brackets the details of where the place ' Aubigny' is.

I hope this is useful for now.


Posted by Øyvind   on 20/5/2015 

Thanks for the comments, Arianna!

We will use them when we discuss it. The example is an interesting one — there is a comparable one in TEI (my mother’s father  ). Not sure they are equal thought. His name is Dystvold. We should compare at one point maybe.


Posted by   Øyvindon 20/5/2015

To remind ourselves, this is how TEI does it:

<persName>
<forename>Johan</forename>
<surname type="toponymic" ref="#dystvold">Dystvold</surname>
</persName>
<!-- ... -->
<placeName xml:id="dystvold">Dystvold</placeName>

So here it is claimed (in this case truthfully) that the name is a surname, but it is toponymic and linked to the place name.

Just to throw it in, I am not sure how equal these are.

In confusion,


posted by Arianna Ciula on 20/5/2015

Yes. You told me before I think.

They are comparable:

<persName>
<forename>Johan</forename>
<surname type="toponymic" ref="#dystvold">Dystvold</surname>
</persName>
<!-- ... -->
<placeName xml:id="dystvold">Dystvold</placeName>

If we had to map this  <surname type="toponymic"> would be an instance of E44 Place Appellation but so would also be the <placeName xml:id="dystvold">.

What is missing in the TEI example is information on the location of the place of course (and as you know we have the problem that in TEI you can replicate the place geopolitical structure within a <placeName>... hence the confusion between the thing being named and the type of name).

This makes me think that the use of 'form' for appellations might be also misleading (but I know that might be problematic to touch) because it could be interpreted to the form of the name in linguistic, lexicographical, entomological sense (what in TEI is called <nym>).


posted by Oyevind

Right.

Form: we cannot step back from complexity here. We have to work through the complexity, hopefully to an easy to understand result. It seems clear that what we can give this week is a report on work in progress — then with input for the whole group we can continue working on this.

Thank for opening the cans — I mean it, we need to understand or at least acknowledge the complexity.

 

In the 37th joined meeting of the CIDOC CRM SIG and ISO/TC46/SC4/WG9 and the 30th   FRBR - CIDOC CRM Harmonization meeting, the crm-sig reviewed the proposals made by Oyvind and decided the following:
 
E41: to add to the scope note   a paragraph proposed by Oyvind
E35: to update the scope note. This HW is assigned to Oyvind
E42 Identifier:  to  keep this class and fix scope note
E44 Place Appellation : to Keep this class
E49 Time Appellation: to merge this class  with E50 Date.This HW is assigned to Oyvind
E51 Contact Point: Keep and harmonize this with Parthenos. This HW is assigned to Oyvind GB
E75 Conceptual Object Appellation:  to  delete this class
E82 Actor Appellation:to  delete this class
E46 Section definition:to  delete this class
 
Also the crm-sig decided that when a property or a class is deleted, it should be removed from the text  its super/sub classes sections, scope note and examples, but the title of the class/property should   be kept with a note saying ‘deprecated’ use X instead, the properties that go with these classes are also deprecated
 
Berlin, December 2016
 

posted by Ovind on 24/3/2017

Dear all,

Here is my homework for Issue 260:

1. E35: Accepted the comment made by Oyvind that the scope note of E35 Title is misleading, since it refers to something functioning a title, not having the form of a title, it is decided to keep the Title, to update scope note. This HW is assigned to Oyvind

I have changed the first paragraph of the scope note

Old scope note for E35:

> This class comprises the names assigned to works, such as texts, artworks or pieces of music.

> Titles are proper noun phrases or verbal phrases, and should not be confused with generic object names such as “chair”, “painting” or “book” (the latter are common nouns that stand for instances of E55 Type). Titles may be assigned by the creator of the work itself, or by a social group.

> This class also comprises the translations of titles that are used as surrogates for the original titles in different social contexts.

Proposed new version:

This class comprises textual strings that within a cultural context can be clearly identified as titles due to their form. Being a subclass of E41 Appellation, E35 Title can only be used when such a string is actually are used as a title of a work, such as a text, an artwork, or a piece of music.

Titles are proper noun phrases or verbal phrases, and should not be confused with generic object names such as “chair”, “painting” or “book” (the latter are common nouns that stand for instances of E55 Type). Titles may be assigned by the creator of the work itself, or by a social group.

This class also comprises the translations of titles that are used as surrogates for the original titles in different social contexts.”

—————————

2. E49 Time Appellation: to keep but it should be merged with Date and it should be decided if they keep the same name (Oyvind)

E50 Date should be marked obsolete. I have changed the inheritance, the first paragraph of the scope note, and added two examples.

Old definition of E49 Time Appellation:

> Subclass of : E41 Appellation
> Superclass of: E50 Date
>
> Scope Note:
>
> This class comprises all forms of names or codes, such as historical periods which are characteristically used to refer to a specific E52 Time-Span. This includes human- and machine readable dates and timestamps.

> The instances of E49 Time Appellation may vary in their degree of precision, and they may be relative to other time frames, “Before Christ” for example. Instances of E52 Time-Span are often defined by reference to a cultural period or an event e.g. ‘the duration of the Ming Dynasty’.

> Examples:
>  • “Meiji” [Japanese term for a specific time-span]
>  • “1st half of the XX century”
>  • “Quaternary”
>  • “1215 Hegira” [a date in the Islamic calendar]
>  • “Last century”

New definition of E49 Time Appellation:

Subclass of : E41 Appellation

Scope Note:

This class comprises all forms of names or codes, such as historical periods, and dates, which are characteristically used to refer to a specific E52 Time-Span.

The instances of E49 Time Appellation may vary in their degree of precision, and they may be relative to other time frames, “Before Christ” for example. Instances of E52 Time-Span are often defined by reference to a cultural period or an event e.g. ‘the duration of the Ming Dynasty’.

Examples:
• “Meiji” [Japanese term for a specific time-span]
• “1st half of the XX century”
• “Quaternary”
• “1215 Hegira” [a date in the Islamic calendar]
• “Last century”
• “2013-10-05”
• “Mon May 19 22:39:23 CET 2014”
 

Posted by Martin 24/3/2017

Dear Oeyvind,

I agree with the scope note, given the interpretation we decided. I wonder however if there is a
deeper issue here:

In Germany there exists the saying that dying Goethe uttered "mehr Licht" ("more light"). I reused this proposition yesterday, because I wanted to read a newspaper.

Claude Shannon defined information as a message with a known provenance, which is the most accepted theory in computer science.

That would mean that the identity of an Information Object is a tuple <content,sender>, rather than <content>.

If we accept that, we enter another hell of arguments about what the identity of the sender is. That is easy for a Title, but quite tricky for the non-smoking symbol.

Question: Should we touch also this front, or are we sure that "more light" is always "more light" ?

In other words, may be a title actually deviates from an appellation in that it adds to its identity the provenance, which in turn allows for translation? 

Posted by Oyvind on 26/3/2017

Dear Martin,

this is dangerous territory. Do we need to go there? We may have to open up all sorts of boxes including those owned by language philosophers and semioticians.

An utterance is made by someone, surely. But is a title an utterance? It is not purely either or, but is it not more langue than parole? https://en.wikipedia.org/wiki/Langue_and_parole

I think one can find many different views on what information is in the humanities and many of them would be quite different from Shannon. Personally, I think thinking based on dialogism makes a lot of sense.
 

Posted by Christian Emil on 26/3/2017

Dear all
It is an interesting area. However, the class title was intrudeced for practical-pragmatical  purposes in CRM at an early stage and from a museum point of view.  To try to go into deep details may be interesting indeed, but should perhaps not be the higest prioritized task.

A comment to the new scopenote, the sentence "This class comprises textual strings that within a cultural context can be clearly identified as titles due to their form" in the defintion of a class Title is almost without information value. The only contraint is that titles are textual strings.

Posted by Jim Salmons on 27/3/2017

To All and especially Martin and Oyvind,

Although not specifically germane to the "rights" conversation of the moment, I would like to contribute a further refining dimension to Martin's and Oyvind's discussion about Claude Shannon's definition of 'information' as a 'message' with a 'known provenance', that is, the distinction between the tuple of <message, sender> vis a vis <message>.

The notion of fact/assertion (let's not quibble about the truth-value of a statement at this point, only its existence as a 'parole' -- spoken/written linguistic utterance) is incomplete without the 'sender' aspect to the assertion. This insight is fundamental to FactMiners' development of the MAGAZINE #GTS (Ground-Truth Storage) format as an extension of PRImA's PAGE #GTS format.

An often unspoken assumption about an historical document -- a book or monograph, for example -- is that its message/content 'speaks' with the voice of its author or coordinated group of authors. This notion of unified voice is completely inappropriate as an assumption about the content of a commercial magazine (or for most academic/research journals for that matter) where multiple disconnected 'message-senders' have equal access to the 'channel' of the magazine's content.

The same 'fact' (assertion) made by a -- in our case of Softalk magazine -- a software product-publisher in an advertisement in an issue of a serial publication/magazine is completely different than the same fact/assertion contributed by an authoritative reviewer in the same issue of the magazine. The credibility of that assertion is further reducible if the same fact/assertion is made in the issue by a previously unknown author of a letter to the editor of the publication.

This recognition of Shannon's message/sender tuple is the basis for FactMiners' desire to create the MAGAZINE #GTS format as one with integrated complex document structure and content depiction models derived from a #cidocCRM/FRBRoo/PRESSoo ontological 'stack'.

Happy-Healthy Vibes, 

Posted by Oyvind on 28/3/2017

Dear Oeyvind, Christian-Emil,

I agree with both of you and propose to drop the change.I would leave it open to which degree the Title gets identity from the sender. But given that titles are translated, I'd argue that the concept is implicit that the title depends on the sender.
 

Posted by George on 1/4/2017

Dear all,

With regards to this H/W, I was assigned to look at E51 Contact Point and harmonize to Parthenos Entities which has PE29 Access Point which is understood as an address used in an information network environment local or global which allows for directing communication to some entity.

In terms of harmonization then PE29 is clearly just a subclass of E51. With regards to insights potentially provided to the core model, it would seem to support the idea that there may be a generalized communication brokering service to be modelled which facilitates messages between actors. In the case of Parthenos Entities this PE8 E-Service which is said to ‘provide access point’ to some digital object which it hosts and which bears this address as a means of finding it. (Model to be found in attached slide)

One could imagine a general communication service would offer some means of reaching an object, hold a relation to the object itself and the object in turn would relate to the means of reaching it. That being said, the model is quite speculative and does not seem to be required by any particular data structure at present. Therefore, I thin owe can be content with knowing that E51 adequately models a piece of information that allows you to contact some agent and that it serves as an adequate generalization for a specialization that deals with the particular situation of machine communication.

posted by Christian Emil on 27/4/2017

Dear all,

I am studying some of the example mappings in the online 3M system. There are some strange mapping suggestion there.

An exhibition of (fine) arts is usually mapped as an E5 Event.


An exhibition is often given a title e.g. "Fly me to the moon​". ​​ E35 Title is a subclass of E41 Appellation and P102 has title has E71 Man-Made Thing as domain. ​Thus an exhibition, mapped as an E5 Event, cannot have a title only an appellation in CRM.


In every day language an exhibition can be opened, closed, mounted, taken down.  Apparently there are physical aspect associated with an exhibition as well ass conceptual aspects (the plan). But what does the exhibtion title denote?


Suggestions?


 

Posted by Christian Emil on 27/4/2017

I realized that we can use instances of E35 Title to identify all instances of E1 CRM Entity through P1 is identified by (identifies) . I was confused by the mapping.

posted by Martin on 15/12/2017

On 3/26/2017 9:29 PM, Øyvind Eide wrote:
> Dear Martin,
>
> this is dangerous territory. Do we need to go there? We may have to open up all sorts of boxes including those owned by language philosophers and semioticians.
>
> An utterance is made by someone, surely. But is a title an utterance? It is not purely either or, but is it not more langue than parole? https://en.wikipedia.org/wiki/Langue_and_parole
>
> I think one can find many different views on what information is in the humanities and many of them would be quite different from Shannon. Personally, I think thinking based on dialogism makes a lot of sense.
>
> Do we have to enter this territory? Do we need to express opinions on these things in CRM?
Dear Øyvind,

Clearly, one principle of the CRM is, never interpret a term! So, we are not concerned settling disputes about what information or an utterance is. We are concerned with the consistency and effectiveness of definitions for our information purposes. So, for me the problem is a simple question of disambiguation of identity.

Since you wrote (and I agree) "E35 Title can only be used when such a string is actually are used as a title...." this implies that (a) the same string may be used twice as a title and (b) translates differently in these cases.

This means, that the identity of the title as described above consists of the string + context. Otherwise, the scope note is inconsistent.
This context can either be determined as (1) language, (2) one work of art, (3) multiple works of art intentionally referring to the same source - F1 Work or
"loans" from other F1 Work.

This creates a precedent with respect to identity of information. Equally obviously, if we create in the CRM an identifier for "mehr Licht" by Goethe, true or not, and want to trace arguments about the interpretation and reality in an information system, we must, if we want or not, carry the context with us. So, we have two choices: Either we keep the identity of an E73 provenance independent, and introduce another class for information object use context, or we imply a concept of provenance as part of the identity of the information object.

Equally obviously, it is impossible in general to trace exact provenance. We could, however, in the scope note, describe the context concept behind an information object in a more general way, which implies specialization from case to case.

A relevant application are tombstone and other short inscriptions. Epigraphy experts regard the same text on another stone as different.

We may even talk about two message levels. For instance "r.i.p." as a generic message in the tombstone context, and "r.i.p." as a personal message on a
particular tombstone.

Or we say r.i.p. to the issue

posted by Øyvind  on 18/12/2017


> Am 15.12.2017 um 10:53 schrieb Martin Doerr <martin@ics.forth.gr>:
>
> On 3/26/2017 9:29 PM, Øyvind Eide wrote:
>> Dear Martin,
>>
>> this is dangerous territory. Do we need to go there? We may have to open up all sorts of boxes including those owned by language philosophers and semioticians.
>>
>> An utterance is made by someone, surely. But is a title an utterance? It is not purely either or, but is it not more langue than parole? https://en.wikipedia.org/wiki/Langue_and_parole
>>
>> I think one can find many different views on what information is in the humanities and many of them would be quite different from Shannon. Personally, I think thinking based on dialogism makes a lot of sense.
>>
>> Do we have to enter this territory? Do we need to express opinions on these things in CRM?
> Dear Øyvind,
>
> Clearly, one principle of the CRM is, never interpret a term! So, we are not concerned settling disputes about what information or an utterance is. We are concerned with the consistency and effectiveness of definitions for our information purposes. So, for me the problem is a simple question of disambiguation of identity.
>
> Since you wrote (and I agree) "E35 Title can only be used when such a string is actually are used as a title...." this implies that (a) the same string may be used twice as a title and (b) translates differently in these cases.
>
> This means, that the identity of the title as described above consists of the string + context. Otherwise, the scope note is inconsistent.
> This context can either be determined as (1) language, (2) one work of art, (3) multiple works of art intentionally referring to the same source - F1 Work or
> "loans" from other F1 Work.
>
> This creates a precedent with respect to identity of information. Equally obviously, if we create in the CRM an identifier for "mehr Licht" by Goethe, true or not, and want to trace arguments about the interpretation and reality in an information system, we must, if we want or not, carry the context with us. So, we have two choices: Either we keep the identity of an E73 provenance independent, and introduce another class for information object use context, or we imply a concept of provenance as part of the identity of the information object.
>
> Equally obviously, it is impossible in general to trace exact provenance. We could, however, in the scope note, describe the context concept behind an information object in a more general way, which implies specialization from case to case.
>
> A relevant application are tombstone and other short inscriptions. Epigraphy experts regard the same text on another stone as different.
>
> We may even talk about two message levels. For instance "r.i.p." as a generic message in the tombstone context, and "r.i.p." as a personal message on a
> particular tombstone.
>
> Or we say r.i.p. to the issue

Indeed, Martin. I see your arguments, and hopefully understand them in the right context.

As Hirst pointed out, context is a spurious concept. We need some, we never need (or can have) all, and the border between the two is unsharp.

Is this not also the trade-off of information integration in general, and where we disagree with the semantic web community (a sentence that should have had a lot of qualification)? Because we know that the dream of a decontextualised emerging network of useful information is just a dream, at least for cultural history and the humanities. Still, we also know that if we let ourselves tie down to traditional levels of context we are lost and will never be able to integrate something.

Introducing a class for context sounds strange to me as it would indicate that the rest is context-free. Still, it could make sense in order to have a possibility to make context explicit in the cases we need to.

posted by Richard on 19/12/2017

>
> Introducing a class for context sounds strange to me as it would indicate that the rest is context-free. Still, it could make sense in order to have a possibility to make context explicit in the cases we need to.
>
Surely the statements which we make with the CRM are themselves the 'context' for individual assertions?  If so, we have our context already, and don't need to invent an artificial mechanism to express it.

posted by  Øyvind  on 20/12/2017


> Am 19.12.2017 um 12:10 schrieb Richard Light <richard@LIGHT.DEMON.CO.UK>:
>
>
>> Introducing a class for context sounds strange to me as it would indicate that the rest is context-free. Still, it could make sense in order to have a possibility to make context explicit in the cases we need to.
>>
> Surely the statements which we make with the CRM are themselves the 'context' for individual assertions?  If so, we have our context already, and don't need to invent an artificial mechanism to express it.

I would say ONE context, not THE context. The assertions often come from somewhere, loosing one context and adding a new one, the two being more or less similar.

Granted, the original context is often lost already when the data was entered into a database, long before it was expressed in CRM.

A series of de/re-contextualisations…

posted by Martin on 20/12/2017

Dear Richard,

On 12/20/2017 6:23 PM, Øyvind Eide wrote:
>
>> Am 19.12.2017 um 12:10 schrieb Richard Light <richard@LIGHT.DEMON.CO.UK>:
>>
>>
>>> Introducing a class for context sounds strange to me as it would indicate that the rest is context-free. Still, it could make sense in order to have a possibility to make context explicit in the cases we need to.
I think we are confusing terms here. RDF propositions are "context free" because they use URIs, which should(!) resolve unambiguously to the intended reference, without needing a context of utterance to grasp the meaning. Clearly, information objects are in general not context free, how could they! The question I raised is, which parameters of the context of either use or creation are the ones in our cultural communication practice, which allow us to differentiate between two identical strings with obviously two different intended meanings. This context is well acknowledged in the information theory by Shannon, who simply assumes an a priori unambiguous agreement between sender and receiver about the employed signs.
If we have understood which context parameters are relevant, and which cases to distinguish, we will formulate them in the form of context-free propositions. Normally, we associate information objects with the metadata about their creation, which is one form of specifying a context. However, creation may be unknown, as in the case of fairy tales, and yet they have an identity. So, it's more complicated.

posted by Richard on 21/12/2017

Martin,

I'm not sure I accept the idea that strings have an identity, which is separate from the way in which they happen to have been used, and which it is worth our while to record by adding new classes and properties to the CRM.

Any string value which is of interest to us will be identified as an instance of a suitable CRM class: E35 Title; E41 Appellation; etc.  Staying with titles for now, if we know who assigned a title to an art work, we have E13 Attribute assignment which allows us to state what we know (who assigned the title, when, etc.); otherwise we can put a simple P1 is identified by property to join the art work itself directly to its title.  Either way, the title now has a context (i.e. a number of CRM assertions which reflect what we know about the art works bearing that title).  In this particular case, what more is there to say?

Another example of this sort of thing (which might be more convincing) would be surnames.  There are lots of resources which detail the origin, meaning and geographical spread of peoples' family names.  Each name is a subject of study in its own right.  Looking at the definition of E41 Appellation, I notice that it relates to "a specific instance of some class or category within a certain context". That isn't quite the same as the surname as a name. 

posted by Martin on 21/12/2017

Dear Richard,

On 12/21/2017 5:38 PM, Richard Light wrote:
> Martin,
>
> I'm not sure I accept the idea that strings have an identity, which is separate from the way in which they happen to have been used, and which it is worth our while to record by adding new classes and properties to the CRM.
I actually did not propose to add new classes and properties. Identity conditions are rules that are not explicit constructs in the CRM so far, but in scope notes. In general, all class scope notes should describe identity conditions. That is an issue for the next versions.
>
> Any string value which is of interest to us will be identified as an instance of a suitable CRM class: E35 Title; E41 Appellation; etc.  Staying with titles for now, if we know who assigned a title to an art work, we have E13 Attribute assignment which allows us to state what we know (who assigned the title, when, etc.); otherwise we can put a simple P1 is identified by property to join the art work itself directly to its title.  Either way, the title now has a context (i.e. a number of CRM assertions which reflect what we know about the art works bearing that title).  In this particular case, what more is there to say?
>
> Another example of this sort of thing (which might be more convincing) would be surnames.  There are lots of resources which detail the origin, meaning and geographical spread of peoples' family names.  Each name is a subject of study in its own right.  Looking at the definition of E41 Appellation, I notice that it relates to "a specific instance of some class or category within a certain context". That isn't quite the same as the surname as a name.
Right. That is my point. Clearly, there is an identity condition of a string, which is only the sequence of symbols and the relevant encoding level. For instance,
is an ASCII "H" the same with a Latin 1 "H" and - or not - with a Greek capital "H" ? Obviously there are different choices, making sense depending on what we want to describe.

If we talk about names, is William and Bill the same?  Obviously there are different choices, making sense depending on what we want to describe.

If we are on the level of titles, is the identity condition only that of a string, or of a string and...

If we are in Information Objects, is the identity condition only that of a string, or of a string and...?

The problem occurs only with short strings with a good chance to be the same at some encoding level, but not in intended meaning. It may be marginal.
I don't know. But translations of titles clearly use more identity conditions than the string.

Last proposal: Scope note of E35 Title was discussed in  the 38th joined meeting of the CIDOC CRM SIG and ISO/TC46/SC4/WG9 and the 31st FRBR - CIDOC CRM Harmonization meeting, the crm-sig discussed about the proposal made by Oyvind and decided the following:

the scope note which is not accepted is the following

“This class comprises textual strings that within a cultural context can be clearly identified as titles due to their form. Being a subclass of E41 Appellation, E35 Title can only be used when such a string is actually are used as a title of a work, such as a text, an artwork, or a piece of music.

Titles are proper noun phrases or verbal phrases, and should not be confused with generic object names such as “chair”, “painting” or “book” (the latter are common nouns that stand for instances of E55 Type). Titles may be assigned by the creator of the work itself, or by a social group.

This class also comprises the translations of titles that are used as surrogates for the original titles in different social contexts.”

the decisions are

  • The proposed changes in the scope note of  E35 Title have not been decided (there is an e-mail discussion about identity conditions of information objects in general.)
  • The new definition about E49 Time Appellation has been accepted and the E50 has been marked obsolete.
  • The E51 Contact Point will be discussed in the next meeting.

 

In the 40th joined meeting of the CIDOC CRM SIG and ISO/TC46/SC4/WG9 and the 33nd FRBR - CIDOC CRM Harmonization meetingthe sig reviewed the proposal by Oyvind for E35 Title and accepted it. The revised scope note is here

Cologne, January 2018

In the 42nd joined meeting of the CIDOC CRM SIG and ISO/TC46/SC4/WG9 and the 35th FRBR - CIDOC CRM Harmonization meeting, the crm-sig has decided to keep Issue 260 open. E51 Contact Point has been deprecated from crm-base, in line with the guideline that classes with no properties pointing to them are not to be declared. However, E51 should be moved to the Parthenos model instead.
GB is assigned to write a scope note and transfer the examples.

Berlin, November 2018