[Crm-sig] P90 etc.

Richard Light richard at light.demon.co.uk
Thu Mar 8 19:29:31 EET 2018


Rob,

I'm suggesting that we take a step back from this sort of ad hoc
decision making, as noted two messages down.  We can come back to the
question of which RDF properties to use once we are equipped with
information on community practice as well as W3C/ISO norms.

If the group agrees, I propose to draft a call for examples of RDF
practice which we can put out to the MCG and MCN lists (for the museum
community), and to whatever library and archive lists we can find.

Richard

On 08/03/2018 16:28, Robert Sanderson wrote:
>
>  
>
> Martin,
>
>  
>
> Could you clarify why you have changed your mind about rdf:value?
>
>  
>
> > I recommend NOT to recommend rdf:value
>
>  
>
> In particular, in the last week you said:
>
>  
>
> “CRM-SIG normally works reactively: When a good community practice
> emerges, this is taken up.”
>
>  
>
> and
>
>  
>
> “Whatever the vast majority is  and rdf:value does the job, I have no
> objections to its use.
> Just define precisely what you use it for. We can add that to our
> guidelines. It is already standard rdf.”
>
>  
>
> Thanks,
>
>  
>
> Rob
>
>  
>
>  
>
> *From: *Crm-sig <crm-sig-bounces at ics.forth.gr> on behalf of Richard
> Light <richard at light.demon.co.uk>
> *Date: *Thursday, March 8, 2018 at 12:02 AM
> *To: *Martin Doerr <martin at ics.forth.gr>
> *Cc: *George Bruseker <george.bruseker at gmail.com>, crm-sig
> <crm-sig at ics.forth.gr>
> *Subject: *Re: [Crm-sig] P90 etc.
>
>  
>
> 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/
>
>     should
>
>     be replaced by rdfs:label (“rdfs:label is an instance
>     of<https://www.w3.org/TR/rdf-schema/#ch_property>
>
>     rdf: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 <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           |
>
>     --------------------------------------------------------------
>
>  
>
> -- 
> *Richard Light*
>

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


More information about the Crm-sig mailing list