[Crm-sig] NEW ISSUE: symbolic content

Richard Light richard at light.demon.co.uk
Tue Sep 18 15:11:52 EEST 2018

Right, so we are defining a new CRM property, with domain E90 Symbolic Object and range E62 String.  Agreed?  I suggest that we call it "Pxxx has string value" to make its purpose clearer.

E62 String is defined more widely than the strings we are currently considering: it includes "bitmaps, vector graphics, etc.".  Is this a matter of concern?  My own initial thought is that the scope note for Pxxx in the CRM document should be as generic as the definition of E62, so they are mutually compatible, something like:

This property contains the symbolic content of the Symbolic Object, expressed as an E62 String.  The "level of symbolic specificity" by which the String is interpreted should conform to the type of the Symbolic Object.

Then we could have Rob's examples.

Once this simple property is in place in the CRM, we can update the RDF implementation guidelines to indicate that in the RDF environment we represent the E62 String values, which are the object of a Pxxx_has_string_value property/predicate, as a subclass of rdf:value.

Or ... maybe we might choose another RDF(S) property.  I forget the details of our previous discussions, but there is rdfs:Literal and rdfs:langString, either of which we could use.  Ideally, we should in general choose RDF implementations which conform nicely to our abstract distinction between E60 Number, E61 Time Primitive and E62 String.

I'm keen that we resolve the simple case of string values, because I think that will solve 90+% of our users' actual needs.  However, I'm equally keen that we don't do it in a way which makes it harder to deal with bitmaps, graphics, and indeed more complex values such as measurements (e.g. 3' 6") in RDF.



On 14/09/2018 18:23, Martin Doerr wrote:
Dear All,

I propose a new property of Symbolic Object : "has symbolic content : String" , in RDFS subproperty of rdfs:value.

The "level of symbolic specificity" by which the String is interpreted should conform to the type of the Symbolic Object.



On 9/14/2018 7:54 PM, Richard Light wrote:

On 13/09/2018 20:57, Martin Doerr wrote:
Dear Richard,

What we need, to my opinion, is a property of Symbolic Object we may call it "has symbolic content" or "has symbolic content inline" or anything better, which defines that the symbolic content is identical to the Literal, abstracted to the "level of symbolic specificity" that the Literal implies and that conforms to the identity condition of the Symbolic Object, i.e., characters of a certain script, or whatever. That would make the meaning of the "value" unambiguous.
Again, I'm in complete agreement with this line of thought.  One decision we should make is whether this property forms part of the generic CRM framework, or if it is to be an implementation-specific property which only appears in our RDF implementation of the CRM.  My instinct is for it to go into the CRM proper: the treatment of Symbolic Object and its subclasses would I think be made clearer by the addition of this property.
For CRM proper!
OK: perhaps we should start a new issue to address this?

 Dr. Martin Doerr              |  Vox:+30(2810)391625        |
 Research Director             |  Fax:+30(2810)391638        |
                               |  Email: martin at ics.forth.gr<mailto:martin at ics.forth.gr> |
               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
Crm-sig at ics.forth.gr<mailto:Crm-sig at ics.forth.gr>

Richard Light
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ics.forth.gr/pipermail/crm-sig/attachments/20180918/65d36dff/attachment-0001.html>

More information about the Crm-sig mailing list