[Crm-sig] P90 etc.

Martin Doerr martin at ics.forth.gr
Thu Mar 8 14:46:55 EET 2018


Excellent!

Contributions are most welcome, in particular if they do not propose the 
most simple solution, but point to problems in practice of existing 
methods (such as structured encoding of personal names). Clearly, all 
solutions need to be associated with a practical scope, which should not 
be named "vast majority", but be a concrete application profile.
For instance, xsd:dateTime goes back I think a billion years, but not 4 
or 14 billion years. We can declare that out of scope.

Looking forward to that,

Martin

On 3/8/2018 10:02 AM, Richard Light wrote:
>
> 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*


-- 
--------------------------------------------------------------
  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           |
--------------------------------------------------------------

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ics.forth.gr/pipermail/crm-sig/attachments/20180308/99f011f7/attachment-0001.html>


More information about the Crm-sig mailing list