[Crm-sig] P90 etc.

Richard Light richard at light.demon.co.uk
Thu Mar 8 10:02:02 EET 2018


Martin,

Thanks for updating the string part of the RDF implementation doc.

I was thinking last night that maybe we should focus our RDF efforts on
exactly this issue: the representation of the CRM primitive classes E60,
E61 and E62 in RDF.  The current RDF document is becoming quite
wide-ranging in its scope, and (for example) you have questioned whether
certain sections belong in it.  If we concentrate on this single aspect
of the broader RDF issue, I think we can produce something which is of
practical value relatively quickly.  In particular, I would like to
devote time to this during the Lyon meeting.

It seems to me that there are three elements which need to be considered
when recommending an approach:

  * the CRM's own view on what information should be expressible, and
    how (in an abstract sense) it should be represented
  * RDF and other W3C/ISO recommendations and standards for representing
    string-type information
  * the view of communities of practice on the issues involved, and the
    solutions they have come up with

In particular I think it important that we should consult widely on this
issue, and be seen to take account of existing community practice.

Best wishes,

Richard

On 06/03/2018 17:54, Martin Doerr wrote:
> Dear Richard,
>
> It would be really great if you could join our next meeting!
>
> We need your help to finish the RDF guidelines.
> I have rewritten the string part in the google doc:
>
>
>     "Recording string values
>
> As mentioned in point 3 above, the RDFS Schema does not implement the
> CRM primitive classes E60 Number, E61 Date or E62 String.  Instead it
> specifies rdfs:Literal as the range of properties which would
> otherwise take one of these values:
>
>  *
>
>     P3_has_note [String]
>
>  *
>
>     P57_has_number_of_parts [Number]
>
>  *
>
>     P79_beginning_is_qualified_by [String]
>
>  *
>
>     P80_end_is_qualified_by [String]
>
>  *
>
>     P81_ongoing_throughout [Time primitive] [but see Note 8 above and
>     section on dates below]
>
>  *
>
>     P82_at_some_time_within [Time primitive] [but see Note 8 above and
>     section on dates below]
>
>  *
>
>     P90_has_value [Number]
>
> The recommended RDFS implementation of the CIDOC CRM may further
> refine the range of these properties to more specific datatypes, if
> not yet done.
>
>
>     Recording names
>
> Apart from the seven properties listed above, there are a number of
> situations where the fully-worked-out path to a string value leads to
> an unduly long chain of classes and properties.  For example:
>
> E55_Type > P1_is_identified_by > E41_Appellation > P3_has_note >
> E62_String
>
> Documenting an instance of E41_Appellation with a URI of its own, is
> only useful if the instance is expected to be either an object of
> discourse regardless what it identifies, such as etymology or name
> variants etc., or if it needs an extended content model with
> meaningful parts, such as a street address.
>
> In cases where there is nothing more to say about the E41_Appellation,
> P1_is_identified_by shouldbe replaced by rdfs:label (“rdfs:label is an
> instance ofrdf:Property
> <https://www.w3.org/TR/rdf-schema/#ch_property>that may be used to
> provide a human-readable version of a resource's name”, in: RDF Schema
> 1.1)
>
> E55_Type > rdfs:label > rdfs:Literal
> <https://www.w3.org/TR/rdf-schema/#ch_literal>.
>
> Since RDFS does not qualify the range of rds:label further, we cannot
> formally make rdfs:label a subproperty of P1_is_identified_by or
> vice-versa. We can only register the convention and take care that
> query systems retrieve labels together with instances of
> P1_is_identified_by . The fact that the same name “Martin Doerr” may
> appear in different encodings is inevitable. It is recommended to use
> name spelling conventions from library cataloguing rules and SKOS
> properties for instances of  E55_Type.
>
> "
>
> Please comment!
>
> I have discussed with George that we should make several distinctions:
>
> Only digitized content can be stored in-line in the KB as Literal.
>
> There must be a comparable way to point to a digitized content via
> URI, URL, or literal. All representations of Symbolic Objects in
> electronic form are ambiguous wrt the the intended level of symbolic
> interpretation: Is it the bits, or the Latin1 characters, or
> characters + font make up its identity?
>
> We must distinguish between digital content of a symbolic object, a
> general "note" about an individual, and values in a mathematical/
> physical space.
>
> I recommend NOT to recommend rdf:value:
>
>
>         "5.4.3 rdf:value rdf:value is an instance of rdf:Property
>         <https://www.w3.org/TR/rdf-schema/#ch_property> that may be
>         used in describing structured values. rdf:value has no meaning
>         on its own. "
>
> We definitely need a recommendation for names, regardless how complex
> it becomes.
>
> When we created the RDF version, there were no datatype
> recommendations. Now, that there are, we should remove "rdfs:Literal
> from all properties in which it is unambiguous.
>
> I kindly ask you to check
> https://www.w3.org/TR/2004/REC-rdf-mt-20040210/#dtype_interp for 
> compatible datatypes. This must be well-justified. E.g.,
> "P57_has_number_of_parts [Number]" should have range:
>
> "xsd:nonNegativeInteger", and not "xsd:decimal".
>
> E60 Number could be any value from the mathematical multidimensional
> spaces made of real numbers, such as RGB images. We have no
> super-representation in RDFS/XSD. We can enumerate compatible datatypes:
>
> |"xsd:decimal|
> <http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#decimal>,
> |xsd:float|
> <http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#float>,
> |xsd:double|
> <http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#double>,
> |xsd:hexBinary|
> <http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#hexBinary>,
> |xsd:base64Binary|
> <http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#base64Binary>, 
> |xsd:integer|
> <http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#integer>,
> |xsd:nonPositiveInteger|
> <http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#nonPositiveInteger>,
> |xsd:negativeInteger|
> <http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#negativeInteger>,
> |xsd:long| <http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#long>,
> |xsd:int| <http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#int>,
> |xsd:short|
> <http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#short>,
> |xsd:byte| <http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#byte>,
> |xsd:nonNegativeInteger|
> <http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#nonNegativeInteger>,
> |xsd:unsignedLong|
> <http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#unsignedLong>,
> |xsd:unsignedInt|
> <http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#unsignedInt>,
> |xsd:unsignedShort|
> <http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#unsignedShort>,
> |xsd:unsignedByte|
> <http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#unsignedByte>,
> |xsd:positiveInteger",|
> <http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#positiveInteger>
>
> E61 Timeprimitive could be completely replaced by xsd:dateTime,
> without causing incompatibilities if more precision/ coverage would be
> needed.
>
> "Spaceprimitive" should be a WKT string, I think.
>
> Should E62 be xsd:string, or would that cause another outcry to be too
> complex?
>
> If someone does not convert values into xsd, is that "incompatible"?
>
> Best,
>
>
> Martin
>
>
>
> -- 
> --------------------------------------------------------------
>  Dr. Martin Doerr              |  Vox:+30(2810)391625        |
>  Research Director             |  Fax:+30(2810)391638        |
>                                |  Email: 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           |
> --------------------------------------------------------------

-- 
*Richard Light*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ics.forth.gr/pipermail/crm-sig/attachments/20180308/13d1d260/attachment-0001.html>


More information about the Crm-sig mailing list