Hi, The Linked Art group has been discussing the issue of URIs which point to resources in other frameworks (https://github.com/linked-art/linked.art/issues/307). The discussion has noted the advice in our RDF implementation document (http://www.cidoc-crm.org/sites/default/files/Implementing%20the%20CIDOC%20Conceptual%20Reference%20Model%20in%20RDF_0.pdf), in particular the advice that skos:Concept should not be used for people or places. This raises an issue in relation to ULAN and TGN, two Getty vocabularies which Linked Art would expect to be able to use. Various work-rounds have been proposed, of varying complexity.
After giving this issue some thought, I contributed the following to the discussion: Interesting problem. This issue will crop up wherever you want to exploit the potential of Linked Data by linking out across a 'boundary' to a LD resource which plays by different rules to your own. So it's not just a Linked Art problem. The alternatives would appear to be: * be relaxed about the semantic discontinuity * insist the rest of the LD world changes to fit your world view (which appears to be the CRM SIG position) * cower inside your silo and ignore everything outside it I would argue for adopting the first option. The external resource will still dereference for you; it will still deliver a machine-readable payload. As mentioned above, you won't find any Linked Art or CRM concepts in there, but does that matter? There might be benefit in inventing a relationship for Linked Art which says, in effect, "this is an equivalent but 'external' concept". To go beyond this, assuming that resources such as Geonames will continue to happily ignore our existence, I would suggest a dynamic mapping service, which takes e.g. a Geonames URL, retrieves its contents, and re-expresses those assertions in a CRM-compatible format. Make the call to that service a URL in our Linked Data with the Geonames URL as a parameter, and we will have extended our Linked Data graph to include a virtual CRM-compatible Geonames. Rinse and repeat with other external resources which are big enough to be of interest to us, and too big to re-design along CRM lines. On reflection, I increasingly like the idea of a dynamic mapping service. Maybe we should add something along those lines to the RDF implementation document? The way it would work could be as follows: * we analyse the RDF which is generated by the external resource and re-express those parts of it which are CRM-compatible in CRM RDF (i.e. do a mapping). Some concepts may not map, and would be excluded from the process * we develop a web service which implements this mapping, taking one URL from the external resource as its input and returning CRM RDF * we support a variant URL pattern which maps to this web service, e.g. https://geonames.cidoc-crm.org/2654308/ for https://www.geonames.org/2654308/burgess-hill.html * CIDOC CRM users quote these variant URLs in their RDF data This approach makes no demands on the external system; it simply exploits the fact that it is providing machine-processible data. Once installed, it will deliver whatever resources are in the external system, i.e. you don't need to keep updating your 'copy'. In effect, it extends the scope of the CRM-compatible graph to include this external resource (and all the resources that it mentions). Where the external resource has a SPARQL end-point, it may be possible to implement the mapping (at least in simple cases) by a suitable CONSTRUCT statement. Thoughts? Richard -- Richard Light
_______________________________________________ Crm-sig mailing list [email protected] http://lists.ics.forth.gr/mailman/listinfo/crm-sig
