[Crm-sig] A symbol made of symbols

Ethan Gruber ewg4xuva at gmail.com
Thu Jan 16 19:52:20 EET 2020


I have a followup question to the use of crm:P165i_is_incorporated_in. We
have implemented this property to link a Monogram to a representative,
idealized SVG URI. In a very narrow subset of cases (maybe only one that I
know of so far), a monogram is notable enough to have warranted entry into
Unicode, the chi-rho Christogram: ☧

We have a need to define URIs for these Christograms so that we can exploit
the constituent letters via P106_is_composed_of in SPARQL. We have at least
a few examples of Monograms that consist of both Latin letters and a
Christogram, e.g.,

?monogram crm:P106_is_composed_of+ "Ρ" #Greek rho

So I just want to confirm that a single Unicode character itself is an E73
Information Object, even if this is an unusual implementation.

?monogram crm:P165i_is_incorporated_in "☧"

Ethan


On Fri, Nov 8, 2019 at 10:15 AM Ethan Gruber <ewg4xuva at gmail.com> wrote:

> Hi George,
>
> I think this makes a lot of sense. I can use the D1 Digital Object, and
> this is pretty useful for us as I would like to be able to associate the
> SVG with the person who created it or other processes of production
> (derived from a font file, e.g.). I've forwarded to the Nomisma list and
> hopefully we'll agree and start publishing our monograms online soon.
>
> Thanks,
> Ethan
>
> On Fri, Nov 8, 2019 at 6:28 AM George Bruseker <george.bruseker at gmail.com>
> wrote:
>
>> Hi Ethan,
>>
>> Here is my take.
>>
>>
>>
>> I have a large number (thousands) of monograms that appear on Greek
>> coinage. There is an SVG file that represents an idealized form of the
>> monogram. The Nomisma ontology has a nmo:Monogram class, and I am
>> attempting to link Nomisma more directly as subclasses or subproperties to
>> CIDOC-CRM ones. A monogram fits the definition of a subclass of
>> crm:E37_Mark:
>>
>> "This  class  comprises  symbols,  signs,  signatures  or  short  texts
>>  applied  to  instances  of  E24  Physical Man-Made Thing by arbitrary
>> techniques in order to indicate the creator, owner, dedications, purpose,
>> etc."
>>
>>
>> Yes, it seems the right match.
>>
>>
>> In this sense, if I want to link a monogram to its constituent letters,
>> is P106_is_composed_of the appropriate property for this?
>>
>> For example, I have a URI for a monogram,
>> http://numismatics.org/ocre/symbol/monogram.ric.10.theodosius_ii.3
>>
>> Therefore:
>>
>> <http://numismatics.org/ocre/symbol/monogram.ric.10.theodosius_ii.3> a
>> nmo:Monogram ;
>>   crm:P106_is_composed_of "T" ;
>>   crm:P106_is_composed_of "H" .
>>
>>
>> This also seems the right match. If you are not concerned about the
>> particular form of the letters, then I guess you could make the letters
>> instances of E90 Symbolic Object.
>>
>> etc.
>>
>> The next question I have is how do I link this concept of a monogram to
>> one or more SVG files that represent this monogram? There could be variant
>> images based on individual styles of die-carvers, but scholars agree these
>> variations represent the same semantic concept.
>>
>>
>> I am looking at the documentation for P138 represents, and I am having a
>> difficult time understanding the distinction between the examples where a
>> digital file (PLY 3D model or a JPEG image) is the E36 Visual Item, but in
>> other documentation the E36 Visual Item seems more conceptual.
>>
>> If a Visual Item is definitionally an E1 CRM Entity, then a Visual Item
>> can still represent another Visual Item, correct? So:
>>
>> <http://numismatics.org/ocre/symbol/monogram.ric.10.theodosius_ii.3> a
>> nmo:Monogram ;
>>   crm:P106_is_composed_of "T" ;
>>   crm:P106_is_composed_of "H" ;
>>   crm:P138i_has_representation <
>> http://numismatics.org/ocre/symbols/monogram.ric.10.theodosius_ii.3>
>> #svg file url
>>
>>
>> For the question of relating the instance of Mark (the monograms) to the
>> SVG, I would do this otherwise. I would take advantage of D1 Digital Object
>> class for the instances of SVG and their characteristics. [if you won’t
>> like extensions, then E73 information object] I would then link the
>> instances of D1 to the individual marks through the p165
>> <http://www.cidoc-crm.org/Property/P165-incorporates/Version-6.2.1> incorporation
>> property which allows one information object to incorporate another.
>>
>> For the question of relating one instance of Mark (such that that is
>> uniquely identifiable from another but which is nevertheless a variant of
>> the same Mark), you could make use of the p130
>> <http://www.cidoc-crm.org/Property/P130-shows-features-of/Version-6.2.1> property
>> ’shows features of’. It has a property on property that allows you to
>> specify the kind of similarity.
>>
>> I attach an example of the proposed solution as a diagram. I guess the
>> one part of your problem that it does not address is the ur-imageness of
>> the one idealization. I guess the ur type did not historically exist but is
>> the composite based on scholarly research. Therefore it sounds like
>> creation of a type, see E83
>> <http://www.cidoc-crm.org/Entity/E83-Type-Creation/Version-6.2.1>
>> Perhaps this is a picture for a type? Or you could make one instance of
>> Mark which is the ur instance and say that all the other instance are
>> related to it in particular as variant, but that doesn’t seem correct at
>> first thought.
>>
>> Best,
>>
>> George
>>
>>
>>
>> Thanks,
>> Ethan
>> _______________________________________________
>> Crm-sig mailing list
>> Crm-sig at ics.forth.gr
>> http://lists.ics.forth.gr/mailman/listinfo/crm-sig
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ics.forth.gr/pipermail/crm-sig/attachments/20200116/4993a0a7/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: monogram.png
Type: image/png
Size: 73608 bytes
Desc: not available
URL: <http://lists.ics.forth.gr/pipermail/crm-sig/attachments/20200116/4993a0a7/attachment-0001.png>


More information about the Crm-sig mailing list