Dear Doug,
On 3/1/2018 3:14 PM, Douglas Tudhope wrote:
We'd also support this direction and the move to standardising RDF
guidelines. The need for standardisation of technical representations
and encodings of the CRM (particularly RDF) has been a recurrent theme
in CRM workshops and papers oriented to implementation issues over the
last 10 years (*). We can't really achieve interoperability without
this. Encouraging particular communities with shared use cases (as in
linked.art) to adopt a set of consistent patterns for mapping instance
data to the CRM is also a necessary ingredient of practical
interoperability.
That is exactly my proposal. CRM-SIG normally works reactively: When a
good community practice emerges, this is taken up.
Best,
Martin
Doug Tudhope and Ceri Binding
Hypermedia Research Group, University of South Wales
(*) eg workshops on CRM implementation issues
http://tpdl2013.upatras.gr/ws-crmex.php
https://www.topoi.org/wp-content/uploads/2011/02/Programme_Datenwelten.pdf
PS just seen Martin's concurrent reply to this thread and this is not
taking issue with that, rather arguing that we can make significant
progress by some basic implementation (RDF) extensions and mapping
patterns, even though they will not solve all the problems
------------------------------------------------------------------------
*From:* Crm-sig [[email protected]] on behalf of Conal
Tuohy [[email protected]]
*Sent:* 01 March 2018 03:02
*To:* George Bruseker
*Cc:* crm-sig ([email protected])
*Subject:* Re: [Crm-sig] Domain and range of P90
One of the "gaps" which puzzles me most is the example you give of
encoding the string value of an Appellation. I understand the
recommended practice is to attach the string value of a person's name
using P3_has_note, or actually, using a custom subproperty of
P3_has_note. The semantics of P3_has_note itself are weak; a note is
simply an "informal description" of something, so if I have a
particular name (an RDF resource) which P3_has_note the literal string
"Conal Tuohy", then I should really define subproperties so as to be
able to distinguish that string value from a note which really is
nothing more than an "informal description" of that name e.g. "A very
uncommon name of Irish origin". What puzzles me most about this "gap"
in the RDFS specification is that the distinction between a note ABOUT
a name, and the actual textual representation OF a name is somehow
considered out of scope of the CRM in RDFS. It's puzzling, because the
string value of a name is something which really must be encoded in a
standard fashion, to achieve interoperability (as an aside, my
personal view is that the string literal "Conal Tuohy" could be
attached to an Appellation using the rdf:value or rdfs:label predicate
defined in the RDFS spec). But the important thing is that the RDFS
schema should stipulate how to attach this literal data rather than
leave it as an open question. In general these are the kinds of issues
which puzzle many people who approach the CRM from a position of
having already worked with other RDF ontologies in the cultural
heritage space, and find themselves wondering how they are supposed to
make these details CRM work in RDF in an interoperable way, without
having to pick and choose from a variety of techniques for "finessing"
the gaps.
These kinds of gaps are serious barriers to interoperability in the
Linked Open Data cloud, and they need to be addressed by agreeing on
some encoding procedures that can be used consistently by different
projects on the web. It would be helpful to CRM adopters in the Linked
Data community if these gaps could be filled in a manner which is
clear and simple and interoperable. I am not in favour of just
offering a menu of possible approaches, especially where individual
projects would have to make local customisations to their schema. If
there is some particular value in multiple approaches, then they could
be published as different "profiles" that encoders could simply adopt,
as a whole. I think the recent effort by Richard Light (and other
contributors) to collate guidelines on RDF encoding is a great
initiative!
<https://docs.google.com/document/d/1zCGZ4iBzekcEYo4Dy0hI8CrZ7dTkMD2rJaxavtEOET0/edit
<https://docs.google.com/document/d/1zCGZ4iBzekcEYo4Dy0hI8CrZ7dTkMD2rJaxavtEOET0/edit>>
It deserves more input and I hope it will continue to be discussed on
the list. I also think the Linked Art project http://linked.art/ with
its "profile" of the CRM is another really good way forward.
Regards
Conal
_______________________________________________
Crm-sig mailing list
[email protected]
http://lists.ics.forth.gr/mailman/listinfo/crm-sig
--
--------------------------------------------------------------
Dr. Martin Doerr | Vox:+30(2810)391625 |
Research Director | Fax:+30(2810)391638 |
| Email: [email protected] |
|
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 |
--------------------------------------------------------------
