Links to external authorities for people and places

[natuk]

Over here under the section for "Other Linked Data Identifiers" we recommend skos:exactMatch to link from E21 Person to ULAN identifiers (which are skos:Concept). This contradicts the guidelines for RDF implementation for the CRM which state:

It is not recommended and incompatible with the CRM to use skos:Concept for places and persons.

Also from the documentation for skos:exactMatch:

A skos:exactMatch link indicates a high degree of confidence that two concepts can be used interchangeably across a wide range of information retrieval applications.

I think it is not possible to use E21 Person and skos:Concept interchangeably. So what is the reasoning behind this recommendation?

With the usual apologies for possibly having missed discussion threads somewhere or simply confusing things...

[azaroth42]

No, nothing missed, just a lack of a good alternative. Agree that it's not possible to use E21 and Concept interchangeably.

Is there a better relationship that we can use in CRM space? It should allow any sort of resource to be linked together, without expressing absolute identity criteria. So close or exact match, rather than same as.

[natuk]

In the CRM world skos:Concept is a subclass of E55 Type, so I was wondering if a subproperty of P2 has type would make sense. I have not brought it up in the SIG.

[azaroth42]

Here is my thinking that led to the use of exactMatch:

In the current DIG extension there is L54_is_same_as, with domain and range of E1, and with the scope note:

This property describes the association kind of "same as" between objects. It is used to declare that two or more objects are exactly the same.

And is thus equivalent to (and utterly redundant with) owl:sameAs.

I don't think that CRMDig (per #283) is a strong extension as it is, nor that this is a particularly useful place for such a relationship to live. I don't think we want another similar relationship in that extension, nor do we want to use it directly as it expresses the pure identity condition. We also can't really wait until there is such a broad update to Dig.

It could be farmed out to an AttributeAssignment with a classification of certainty. That would be consistent with other use cases, but seems overly complex.

{
  "type": "Person",
  "_label": "A Person",
  "assigned_to_by": {
    "type": "AttributeAssignment",
    "classified_as": [{
      "id": "aat:probably",
      "type":"Type",
      "_label": "Probably"
    }],
    "assigned_property": "same_as"
    "assigned": {
      "id": "ulan:person",
      "type": "Person",
      "_label": "A Person"
    }
  }
}

versus

{
  "type": "Person",
  "_label": "A Person",
  "exact_match": "ulan:person"
}

It could be a brand new relationship in Linked Art, but it would be practically identical to exactMatch, but with E1 as the domain and range. This seems highly unfortunate, given the general utility of exactMatch.

So it was a case of nose-holding about the domain and range to avoid minting something new or exploding the model out into E13s.

[natuk]

Maybe such weak property is not needed. The problem is primarily links to resources formulated using SKOS. So the range should always be skos:Concept.

[ewg118]

Doesn't this preclude us from using ULAN and TGN URIs directly in our data?

[azaroth42]

I think that's what we want to avoid -- the URI should be "live" in the data, not a string that needs to be recognized to have the shape of a URI. So then the question is the cost/benefit analysis of ignoring the range/domain of skos:exactMatch versus some other model or predicate.

[natuk]

More recent discussions among SIG members indicate that the appropriate property is P1 identified by. The reasoning is that a URI is an instance of E42 Appellation for a place or person. When we match CRM instances to entries in vocabularies or authorities then we are confident we are talking about the same thing, so using the authority URI of the thing as appellation makes sense. This assumes that we are not attempting to do any clever reasoning across CRM and SKOS as they are incompatible.

[azaroth42]

I agree conceptually that http://vocab.getty.edu/ulan/500027372 is an Identifier that identifies Lewis Carroll (the person), but to have that as a string, rather than a LOD resource seems like a missed opportunity. We would treat the URI the same way as "1234".

In order to then retrieve the data from ULAN (or any other such networked vocabulary), having the link as a link seems far more important than the specifics of the relationship.

[natuk]

Forgive me if I am confusing things Rob, but is this not OK?

{
  "@context": "https://linked.art/ns/v1/linked-art.json", 
  "id": "https://linked.art/example/person/3", 
  "type": "Person", 
  "_label": "L. Carroll", 
  "identified_by": [
    {
      "id": "https://linked.art/example/name/2", 
      "type": "Name", 
      "content": "L. Carroll"
    }
  ],
  "identified_by": [
    {
      "id": "http://vocab.getty.edu/ulan/500027372", 
      "type": "Identifier"
    }
  ]
}

Is the ULAN URI treated as string in the above JSON-LD snippet? Or have I broken the model conventions?

[azaroth42]

The issue is asserting that the entity identified by .../ulan/500027372 is an Identifier. It's not, it's a Person. The same way that .../person/3 is a Person (indeed the same Person), not an Identifier.

[natuk]

ULAN does not use the CRM, so in the ULAN universe the entity is a skos:personConcept, not a Person. In the CRM/Linked Art universe, this is an Identifier. My local URIs for Persons are kept to allow me to match them with multiple external resources.

[azaroth42]

It will provide crm Persons before much longer :)

But then equally, it could be VIAF or wikidata or any other source that has a better model than Vlad's PersonConcepts where they really are people.

[ewg118]

Does this model apply only to the API profile for person and place entities? Do we still link a production event in the HMO model to a ULAN URI for carried_out_by or a TGN URI for took_place_at? Even if the Getty updates their JSON-LD and Linked Art profile conneg to provide people and place linked data according to CIDOC CRM, it still precludes us from linking to URIs in other vocabulary systems, whether Nomisma, Geonames, or Pleiades.

[natuk]

Yes, I think if ULAN, TGN etc. enter the CRM universe then there is no problem using their URIs directly (especially if the local databases do not hold local identifiers). One might even argue for sameAs in that case.

For authority files not using the CRM: If we discount the skos:exactMatch semantics in favour of an active link, then why don't we discount the semantics of the authority file (which we know anyway that do not agree with our universe)? I.e. we consider the external URIs as identifiers in the CRM sense and maintain the active link, not worrying about breaking any external semantics.

[azaroth42]

@ewg118 Or languages in GlottoLog (for yet another example) or [as much as I would not do this, many people are keen to...] to anything in wikidata.

I think there are two cases. I use Person for ease, but the same applies to any other class.

1. Using an external URI directly in the model -- Production carried_out_by viaf:rembrandt. Where we would thus be asserting (if only by inference from the range of the property) that viaf:rembrandt was of type crm:Person (or at least crm:Actor). I don't think this is contentious? Even when dereferencing viaf:rembrandt did not result in any CRM properties. crm:Person is just the "local" ontology form of the abstract class of persons, and could easily be swapped for any equivalent class in another ontology. We do this all the time with aat concepts -- they currently do not say they are instances of crm:Type, but they are the object of zillions of p2_has_type / classified_as triples.

2. We have a local crm:Person instance because we want to make assertions about that person directly. I think this is going to be the vast, vast majority of the use cases, even if only to be able to assert a Name on the instance. But then we need to be able to refer to other identifiers that also identify the same entity, such as viaf:rembrandt. I continue to feel that it is not contentious to say that viaf:rembrandt is a crm:Person, as in the case above. Asserting that the entity with the URI viaf:rembrandt is an instance of the CRM class Identifier seems wrong, when above we would say that is an instance of Person.

Desirable features of the solution, in my order of importance:

• Semantically consistent (an entity is not both a Person and an Identifier)
• The remote URI is a resource in the local model, not a string (e.g. not the correct but harder to process pattern of Identifier.content = "uri")
• Uses existing ontological features rather than requiring new terms
• Semantically meaningful (e.g. respects the meaning of the terms)

Possible solutions (and please feel free to add more):

• The very long attribute assignment pattern of asserting sameAs. I don't like this because we will need to do this for many different types of resource, adding a pretty significant overhead. It does, however, meet all the above criteria.
• Use skos:exactMatchand ignore the range/domain implications. This drops out the last bullet, as using exactMatch would imply that the subject and object of the triple are skos:Concepts.
• Use owl:sameAs. There are horrible implications of sameAs where the URIs can be collapsed together programmatically, losing all of the context inherent in the URI and the choice of published data. It does meet all the above criteria, but fails for the same reason as exactMatch in my opinion.
• Find another term that has the same semantics but a better domain/range. I don't think there is one, but if anyone knows of one...
• Invent a new term that's the equivalent of exactMatch, but in our own namespace. This seems worse than using exactMatch, to me.

@aisaac Your thoughts on using skos relationships for non Concept/Type instances would be appreciated. How big a party-foul would it be?

[richardofsussex]

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.

[natuk]

This is exactly my point: let's relax the semantics of the authority files and treat the URIs as crm:Identifiers. We can retrieve more data from the authority files using different semantics, but since we have decided that our semantics are CRM, I do not see what the problem is with using P1 and keeping consistent in our dataset. Different semantics mean different silos in some respect and a dynamic mapping service would solve the problem, but who is going to maintain such a service?

[ajs6f]

Does anyone in the Linked.Art community currently have plans for how they will use inference over L.A data, together with SKOS data? If so, will those plans be injured by @richardofsussex's first alternative? If so, we can discuss those concrete problems here.

I would love to make our decision based directly on the concrete needs of L.A participants, rather than abstract (if important) issues around potential inferencing workflows.

[azaroth42]

A potential solution from asking smart people (@kasei) ...

What about prov:alternateOf?

Two alternate entities present aspects of the same thing. These aspects may be the same or different, and the alternate entities may or may not overlap in time.

Not exactly the same as exactMatch but the same fundamental relation, and the domain and range are Entity which has a clear mapping in CRM to E1.

Then we have the benefits of a single property that isn't maintained by us, without the inference challenges.

[natuk]

I like your thinking Rob :-)

Is prov:entity really a crm:Entity? I would say it is more of a crm:Thing. I thought it is prov:Agent which is similar to crm:Actor for which prov:alternateOf does no apply, so I am not sure that property would help for reconciling people.

But maybe Adam is right, maybe skos:exactMatch is not going to break anything in practical terms. Going from SKOS to CRM, one would have a skos:Concept without any skos:Labels or broader or narrower terms, so nothing to do. Going from CRM to SKOS may be problematic, I would query for my taxonomy and I would get people as results. But I guess one can fix this easily if you know what to expect.

I have a lot less experience with system implementation than the rest of the group so I am happy to park this for now if you think we are spending too much time on it.

[ewg118]

We use prov:alternativeOf in Nomisma when we want to link two URIs that are sort of the same place over time periods, just so we can have some means of associating them together (e.g., Byzantium, Constantinople, Istanbul). Otherwise we adopted PROV-O for the provenance of our RDF data rather than relations between properties of the concepts themselves.

I still think skos:exactMatch is fine. It isn't going to break anything if you choose to implement a SPARQL endpoint to aggregate/query HMO + vocabulary data.

[Habennin]

Jumping in quite late to this lively discussion. I think the problem is that we should not confound things and concepts of things which is what starts the whole semantic debacle. If a thing and its concept were the same, then my imagination of the million dollars in my bank account would be equivalent to the being of the million dollars in my bank account. A quick check reveals that this has not occurred, although I did properly imagine it.

So to start from a text that looks at some of the main options together, I look here:

https://www.w3.org/TR/skos-reference/#L4858

Is this up to date knowledge?

If so, I think it is quite clear that the semantics of none of the terms available are appropriate:

owl:sameAs is used to link two individuals in an ontology, and indicates that they are the same individual (i.e., the same resource).

skos:closeMatch and skos:exactMatch are used to link SKOS concepts in different schemes. A skos:closeMatch link indicates that two concepts are sufficiently similar that they can be used interchangeably in some information retrieval applications. A skos:exactMatch link indicates a high degree of confidence that two concepts can be used interchangeably across a wide range of information retrieval applications.

It is unfortunately the case that the majority of classes in CIDOC CRM are not, on the model level, equivalent to skos concepts. I understand the proper scope of skos:concept is for classifying concepts (therefore equivalent only to E55 in CRM and below), and therefore any instance of a CIDOC CRM class that is not an instance of E55 cannot be either close or equivalent to an instance of some other resource that is an instance of skos:concept. The semantics would be incorrect.

Owl:same-as would do the trick in that it indicates that the two different resources, at the knowledge base level, stand for and are equivalent to the same real world entity (regardless of what class they have then been documented under in the alternate system). But, as Rob has said, this leads to unfortunate consequences in terms of the strong reasoning that has been associated to this in terms of treating the instances as functionally (instead of representationally) equivalent.

It would seem that there is no general property around that has the right semantics. I will read up more about prov:alternativeOf to hope to be disproved, but would wonder if its domains and ranges were also not semantically too restrictive (in CRM terms).

I would be in favour in coming up with a robust, simple property at a higher level that can indicate the semantics of representationally equivalent instances in a knowledge base and promote it as part of Linked.Art's contribution to the wider community. (As in Rob's idea of coining a new same-as as was done in CRMdig, but at a much higher level with significantly more thought put into defining it).

This is not to critique any of the above suggested properties, they seem to function well for their purpose and I think they should be adopted within scope (e.g.: SKOS:exactmatch ought to be used for instances of concepts in SKOS being equated to instances of concepts elaborated under E57 material in CIDOC CRM for example), but it seems that the conversation just identifies a gap in the general semantics that could be filled.

Since applying any of the existing properties would result in actually incorrect reasoning, would it provide any benefit aside from applying a well known (but often incorrectly used) predicate? If it would provide no practical benefit, then why not coin our own property that eventually could provide a practical benefit (because not implying semantically incorrect conclusions, either in terms of classification or in terms of conflation of instances).

has_instance_equivalent

I think the problem arises because it is a sort of meta property. The URI for a person both stands for the person in the real world and is, in the information system, the representational equivalent of that person in the real world. The predicate we need would make a statement about the URI, that stands for some real world thing in some information system, and some other URI, that stands for some real world thing in some other information system, rather than making a statement about the real world thing in itself which it stands for....

If prov:alternativeOf already does that, then it would be fit to purpose. The other options don't seem to do that.

[natuk]

The predicate we need would make a statement about the URI, that stands for some real world thing in some information system, and some other URI, that stands for some real world thing in some other information system,

This sounds a bit like P139 has alternative form.

[VladimirAlexiev]

Hi @azaroth42! In quick answer to your email, I'd recommend this:

• use skos:exactMatch because it's already been used on non-concepts in the wild many many times.
• NOT use RDFS domain/range inferencing, or cut out the skos:exactMatch domain/range. http://vocab.getty.edu/doc/#Reduced_SKOS_Inference shows how we've done this for skos:semanticRelation (because it's useless), skos:narrower (because it's redundant with skos:broader) and skos:narrowerTransitive (because it's not feasible to serve an RDF entity for ULAN's Earth or NorthAmerica with 2.2 resp 1.4M descendants)
• NOT enforce transitivity of skos:exactMatch. Getty AAT has been criticized for having ?x skos:exactMatch ?x for every ?x that has some skos:exactMatch link, which is useless and many find confusing, but follows logically from transitivity and symmetry.
• NOT generate blank-node AttributeAssignments for each skos:exactMatch, unless you have extra info about such matches (who, when, probability, etc)
• evaluate what class to use for such matches. Good candidates are oa:Annotation and EDOAL (https://ns.inria.fr/edoal/1.0/)

I'll also forward an ancient email that tries to assess what would be the damage of saying that Rembrandt is a concept...

[ncarboni]

IMHO defining the external URI for the same instance as E42 Identifier as in the example below:

<sari/123> a crm:E21_Person ;
  crm:P1_is_identified_by <http://d-nb.info/gnd/131556444> .

<http://d-nb.info/gnd/131556444> a crm:E42_Identifier .

is not correct. Doing so means flattening up the distinction between the URI identifying an entity and the URI identifying its identifier. The URI http://d-nb.info/gnd/131556444 represent a person and not the identifier of that person, which is "131556444" or "(DE-588a)131556444". I would also avoid (@natuk) P139 has alternative form because of the same problem.

Could be ideal, however it is going to take quite some time, to have a property: Pxx have external identity Domain: crm:E1_Entity Range: rdfs:Class

What come close to a current solution is skos:exactMatch, however it does requires to instantiate each crm:E1_Entityas skos:Concept. One argument in favour of E1 ≡ skos:Concept is that the Concept has been designed as "unit of thought [...] ideas, meanings, or (categories of) objects and events—which underlie many knowledge organization systems" which does not seems incompatible to me with a E1. We could propose this solution as a "RDF solution" or use it initially and substitute once a property such as "Pxx have external identity" is proposed and approved by the SIG.

[Habennin]

Ideas are not the things they are ideas of!

On Mon., Mar. 2, 2020, 6:49 p.m. Nicola Carboni, notifications@github.com wrote:

IMHO defining the external URI for the same instance as E42 Identifier as in the example below:

<sari/123> a crm:E21_Person ;

crm:P1_is_identified_by http://d-nb.info/gnd/131556444 .

http://d-nb.info/gnd/131556444 a crm:E42_Identifier .

is not correct. Doing so means flattening up the distinction between the URI identifying an entity and the URI identifying its identifier. The URI http://d-nb.info/gnd/131556444 represent a person and not the identifier of that person, which is "131556444" or "(DE-588a)131556444". I would also avoid (@natuk https://github.com/natuk) P139 has alternative form because of the same problem.

Could be ideal, however it is going to take quite some time, to have a property: Pxx have external identity Domain: crm:E1_Entity Range: rdfs:Class

What come close to a current solution is skos:exactMatch, however it does requires to instantiate each crm:E1_Entityas skos:Concept. One argument in favour of E1 ≡ skos:Concept is that the Concept has been designed as "unit of thought [...] ideas, meanings, or (categories of) objects and events—which underlie many knowledge organization systems" which does not seems incompatible to me with a E1. We could propose this solution as a "RDF solution" or use it initially and substitute once a property such as "Pxx have external identity" is proposed and approved by the SIG.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/linked-art/linked.art/issues/307?email_source=notifications&email_token=AC4CLH4P6LWOYAGCDP3ZBJTRFPPQZA5CNFSM4KGG3S3KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENQBP7A#issuecomment-593500156, or unsubscribe https://github.com/notifications/unsubscribe-auth/AC4CLH3QK47ZEMMOEKG4EVTRFPPQZANCNFSM4KGG3S3A .

[ewg118]

I agree with @ncarboni and @VladimirAlexiev. At the end of the day, we need a practical solution. The point of Linked Art is to find a common ground between the semantic perfection required by CIDOC CRM and the reality of building reusable data and scalable information systems.

[Habennin]

To be clear, I am not arguing for the ’semantic perfection of CRM’ or that everything be described with a CRM property. I would argue against CIDOC CRM SIG coining a property for this because it is beyond the scope of CRM. What I am saying is that the SKOS properties are scoped for SKOS and, as far as I understand it, not appropriate to the task that we are trying to put it. It is definitely the case that skos concept does not equal crm entity. E.g.: an instance of E21 People does not have broader and narrower terms because people are not concepts of themselves on the categorical level. But E21 isA E1. Ergo, E1 does not equal SKOS:Concept. So ideally what we need is a higher level property that actually does what is required, as much for the sake of SKOS as for CRM as for Linked.Art. If we choose to use skos:closematch of the like for convenience and because it is semantic web colloquialism, then so be it, but that should be on the basis of it being a decision of convenience and convention and not because CRM Entity = SKOS:concept, because it does not.

On Mar 2, 2020, at 8:32 PM, Ethan Gruber notifications@github.com wrote:

I agree with @ncarboni https://github.com/ncarboni and @VladimirAlexiev https://github.com/VladimirAlexiev. At the end of the day, we need a practical solution. The point of Linked Art is to find a common ground between the semantic perfection required by CIDOC CRM and the reality of building reusable data and scalable information systems.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/linked-art/linked.art/issues/307?email_source=notifications&email_token=AC4CLH6XAK7XWYKTEBT2EMTRFP3VDA5CNFSM4KGG3S3KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENQNT6Q#issuecomment-593549818, or unsubscribe https://github.com/notifications/unsubscribe-auth/AC4CLHZTPDU6CAXFKH6ALLLRFP3VDANCNFSM4KGG3S3A.

[natuk]

I think that since Linked Art has adopted the CRM semantics, trying to adopt semantics from a different discourse at the same time is too difficult if not impossible. @ewg118: Say we consider URIs from authority files as Appellations and we use P1_is_identified_by or a new property to establish the links. What could the limitations be in terms of scalability and reusability of Linked Art data?

[richardofsussex]

I went looking for the definition of skos:exactMatch, and found this (https://www.w3.org/2004/02/skos/mapping/spec/2004-11-11.html):

If two concepts are an 'exact-match' then the set of resources properly indexed against the first concept is identical to the set of resources properly indexed against the second. Therefore the two concepts may be interchanged in queries and subject-based indexes.

To me, this definition suggests that we could use skos:exactMatch to assert that our base URI (the Linked Art data about the person) and the target URI (e.g. the ULAN concept) 'index the same [set of] resource[s]', i.e. the same real-world person, for the purpose of querying and indexing.

[ncarboni]

Ideas are not the things they are ideas of! …

Absolutely, but I think the skos:Concept is a unit of description and "what constitutes a unit of thought is subjective, and this definition is meant to be suggestive, rather than restrictive."
the scope of skos:exact/closeMatch would be to define two instance not only as member of specific CRM classes, but also as two units in KB linked with each others. The double instantiation (when needed) would reflect the nature of these instance as both descriptive of reality and units in the KB. As units in a KB they can be part of sets/schemes which represents the willingness and needs of the organisation behind the KB.

edit and expansion: the object of the matching is not the person/group/physical item, but the record of that person/group/physical item. The problem is the double nature of the assertions in the KB, which is both documentary and document at the same time. We can discuss about the documentary value, but also about being themselves documents which are created, modified and deleted by someone. CRM does not resolve this ambiguity entirely (see preferred vs not-preferred properties), and it is why I think E1 and skos:Concept could live together. CRM would focus on the documentary, other ontologies on the document (e.g. SKOS, prov-o). In my opinion, the multitude of perspectives over the object is the necessary foundation.

That being said: It is the use of skos:concept compatible with the CRM vision of the KB? no It is the use of skos:concept the perfect solution? absolutely no Does work better than E41? IMHO, yes. It does not flatten two things together, but it enables multiple views, which are formally stated. Do we need something better? yes, totally agree.

[VladimirAlexiev]

.Not many people know, but ulan:nnnnn is a Concept, whose focus is ulan:nnnnn-agent, which itself is a Person or Organization. This is described here: http://vocab.getty.edu/doc/#Concept_vs_Thing_Duality. There's also a small survey which Authority systems have such dual representation (eg VIAF does).

I designed it, though I side with Rob not liking this complexity. I'd guess many LODLAM data says "performed by ulan:nnnnn" though it should use ulan:nnnnn-agent. Even Europeana's recommendations used to say "use ulan:nnnnn".

I guess a lesson is that no matter what high falutin ontologies we design, people won't read the doc and may use the wrong form. Because all people care about are links. We should be happy if they put in even /page/ulan/nnnnn.

E21 People does not have broader and narrower terms. But E21 isA E1. Ergo, E1 does not equal SKOS:Concept

I think this is flawed reasoning. E55 is pretty much the same as Concept and CRM includes the analog of broader/narrower. It's true these don't apply to E1 though...

BTW, in ULAN the concepts are arranged in a hierarchy, though it's pretty flat. You got 5 facets, and for some institutions you got iso:broaderPartitive (departments).

[VladimirAlexiev]

Btw, see this discussion from 7y ago: http://web.archive.org/web/20150512004951/http://answers.semanticweb.com:80/questions/16198/skosexactmatch-vs-owlsameas . (Antoine Isaac is a SKOS editor and a main Europeana person)

[ncarboni]

Another solution (which however does not resolve the problem of double instantiation, it just postpone it) is the use of "L54 is same-as" from CRMdig. It seems to be tailor made for this use case : not strong (sameas) nor flattening (identifier). Others have used similar properties (see BBC) too. The problem is that whatever we do, if we define the sameness (skos or owl or crm) between two instances from two different ontologies we are going to have the problem of having them double instantiated at a certain point in time. "L54 is same-as" allow us, however, to declare sameness at least between two object in the CRM universe of discourse.

I sincerely think this is the lesser evil:

<http://sari.net/776458> a crm:E21_Person ;
  crmdig:L54_is_same-as <http://d-nb.info/gnd/131556444> .

<http://d-nb.info/gnd/131556444> a crm:E21_Person .

While http://d-nb.info/gnd/131556444 is a gndo:DifferentiatedPerson, we do not need to declare this in our KB, but we just define it as crm:E21_Person. The two classes can be then declare equivalent in respect to the context of use the KB.

[VladimirAlexiev]

Eg https://github.com/okeeffemuseum/collections-data/blob/master/json/actor/person/260.json where O'Keefe happily state that one of their crm:Persons (which is not a Concept) is skos:exactMatch ulan:nnnnn (which is a Concept). My point is, don't worry about all this so much. The important thing is to have links

[aisaac]

Of course I will agree with @VladimirAlexiev ;-)

But I must say to me the discussion here is unnecessarily complex. Before discussing owl:sameAs vs skos:exactMatch, we should have a more fundamental discussion on whether it is appropriate to use a concept/authority URI or a "real world object" URI in the "carried_out_by" of an the description of a museum object description. So looking first at, say, https://linked.art/model/object/production/, rather than at https://linked.art/model/actor/

If we're ok to use URIs like http://d-nb.info/gnd/131556444 or http://vocab.getty.edu/ulan/500115588 alternatively in the "carried_out_by", be they intended to represent authorities/concepts or real persons, then this will give us good progress to identify which property we can use to represent a match between them. (and yes I believe that there is a case for using concepts in "carried_out_by" if we want to be usable, because these are often the only Linked Data URIs that publishers have)

[azaroth42]

Tagging this for discussion on forthcoming call on July 15th.

To try and summarize the issue:

• We want to link from local resources (Rembrandt in my system) to remote resources that represent the same real world thing (Rembrandt in ULAN or Rembrandt in VIAF), such that consuming clients can extract information from that remote resource or use it for merging across systems (reconciliation). This we are looking for X in the triple: local:rembrandt X ulan:rembrandt
• There are no options that meet all of the requirements, we have to make concessions somewhere... and we try to make concessions that benefit the users of the data, at the expense of the purity of the model.

There are several possible options, with (I believe from the thread) the one with the most support being:

• Use skos:exactMatch -- this is the easiest to produce and consume, with the fewest unintended side-effects, using a commonly recognized predicate. The side-effects only happen if domain/range inferencing are turned on. And even then, it is to add a class of skos:Concept to the entity which might not be a Concept (such as a Person).

Thus, the person record would read:

{
  "id": "https://local.museum/person/A-Person",
  "type": "Person",
  "_label": "A. Person",
  "exact_match": "http://vocab.getty.edu/ulan/500999999"
}

Other options:

• Use prov:alternate_of instead of skos:exactMatch. Doesn't have the potential for the inference breakage, but isn't as well known.
• Use crm:L54_same-as instead of skos:exactMatch. Has the same features as skos:exactMatch, other than not being as well known. And thus we should use exactMatch
• Use owl:sameAs instead of skos:exactMatch. This has more unintended consequences.
• Create a new property of our own, such as has_equivalent_instance. No unintended consequences, but requires maintenance and adoption.
• Use the URI as the value of an Identifier. This would make the URI into a string rather than a resource.
• Use the URI as the id of an Identifier. This has an unintended consequence of explicitly adding Identifier as a class to the remote entity, which is worse than the inference. It also breaks the common Identifier pattern by not having a value.
• Long form the relationship into an AttributeAssignment. This ignores the audience -- people trying to use the data.

[azaroth42]

Decision on 2020-07-15 is to create a new property and advocate for inclusion into CRM Base (or similar) with the SIG in the future.

[VladimirAlexiev]

I'd like to point out again that TGN and ULAN include Places and Agents respectively (in addition to Concepts about such entities). See the red text in http://vocab.getty.edu/doc/#Cons_of_the_Dual_Approach. Despite this red text, many people still use the concept URLs in their data.

[edwardanderson]

The documentation examples for la:equivalent cover objects, activities, places, people and groups. Where we would like to state that our Type is the same as an AAT one, should we also use this property or is skos:exactMatch preferred since it doesn't break anything?

[azaroth42]

I think equivalent is better for consistency with the other linked art data, as you note. (We're doing the same thing at Yale, FWIW). Will update the Type page in the API docs

[beaudet]

I've arrived here after searching issues for "ULAN" because I have an alternative identifier for an Actor that is a ULAN ID and yet there seemingly does not exist a concept term for "ULAN Identifier" meaning the numerical portion of the ULAN ID. In the Actor record, this is expressed as an equivalent for the custom minted identifier of the Actor, but for simplicity, I'd like to also include the numerical value under the identifiers for the Actor and classify that Identifier with a ULAN Identifier term. I will mint my own ID for this concept, but it would be great to express an equivalent URI for it if one exists. If one doesn't exist, then I'm thinking of using an equivalent concept of "personal identifiers" since we're talking about actors but what would be the metatype in this case? It should be a concept indicating ULAN.

There are some wikidata properties and entities for ULAN. Could those help in any way? For example, is it permissible to state that Wikidata's ULAN ID property is equivalent to the custom concept for ULAN Identifier?

For Example:

id,type,label = a custom minted artist URI
    equivalent: https://vocab.getty.edu/ulan/500337743
    identified_by: 
        type:Identifier
            content: 500337743
            classified_as:
                custom term for "ULAN Identifier"
                option 1:
                    equivalent: https://www.wikidata.org/wiki/Property:P245 (ulan id)

                option 2:
                    equivalent: https://vocab.getty.edu/aat/300404627 (personal identification numbers)
                    classified_as: https://www.wikidata.org/wiki/Q2494649 (union list of artist names)  (this would be the metatype)

[azaroth42]

The equivalent is now covered in the base documentation.

For @beaudet's question, this could be handled via the assigned_by pattern for Identifiers. 500337743 is an Identifier assigned_by an AttributeAssignment carried_out_by Getty, and is part_of ULAN.