containedInPlace.sameAs

[fjjulien]

In the first iteration of our "location" property guidelines, we focused on the granularity of the Place object and its relationship to a building. Various modelling strategies are proposed to ensure the location value is the performance hall, while at the same time also providing the name of the building, since it has more notoriety.

In the third scenario, we are recommending to describe the building as a nested building object under "schema:containedInPlace".

"location":
         {
            "@type":"Place",
            "name":"Salle Desjardins",
            "sameAs":[
               "http://kg.artsdata.ca/resource/K2-227",
               "http://www.wikidata.org/entity/Q111668872"],
            "address":{
               "@type":"PostalAddress",
               "addressLocality":"Saint-Hyacinthe",
               "addressRegion":"QC",
               "postalCode":"J2S 9E2",
               "streetAddress":"1705 Rue Saint-Antoine",
               "addressCountry":"CA"
            },
            "containedInPlace":{
               "@type":"Place",
               "name":"Centre des arts Juliette-Lassonde",
               "sameAs":"http://kg.artsdata.ca/resource/K5-796"
            }
    },

So far, so good: that's this relationship is modelled in Artsdata. Now my questions...

The nested building object under "schema:containedInPlace" has a sameAs with an Artsdata ID. If this modelling is used in a dataset uploaded to Artsdata, 

1. Will Artsdata detect two distinct Place objects?
2. Will this trigger a SHACL constraint?
3. Ultimately should recommend not to populate a containedInPlace.sameAs, since this data point would exist in the data record for the performance hall (http://kg.artsdata.ca/resource/K2-227, in the above example)?

[saumier]

1. Will Artsdata detect two distinct Place objects?

Yes. When loading this JSON-LD from a presenter's webpage, there will be a blank node for each event.location. This is OK.

2. Will this trigger a SHACL constraint?

No. The SHACL constraint is on an event having one location that is a place. So even if the place has nested containedInPlace that will not trigger a SHACL violation.

3. Ultimately should recommend not to populate a containedInPlace.sameAs, since this data point would exist in the data record for the performance hall (http://kg.artsdata.ca/resource/K2-227, in the above example)?

I think there are pros and cons of recommending it. I usually think simpler is better. But for SEO Google, the presenter may want to have "name":"Centre des arts Juliette-Lassonde" somewhere. So a simpler approach (that I think follows human nature) is to only have one Place without the containedInPlace but make the name longer. This will not change the official name in Artsdata.

"location":
   {
      "@type":"Place",
      "name":"Salle Desjardins - Centre des arts Juliette-Lassonde",
      "sameAs":[
               "http://kg.artsdata.ca/resource/K2-227",
               "http://www.wikidata.org/entity/Q111668872"]

[fjjulien]

I agree with the principle of keeping the code simple and lean.

I also agree that your proposal serves SEO purposes well.

This being said, from a data consumer's point of view, I see value in storing the performance hall name and the building name under two distinct name triples. This way, a data consumer would be able to display both the hall name and the building name on the page as distinct HTML elements, each with their own styling. You could counter-argue that your proposed naming convention, with a spacer, makes splitting possible. However, we would not be able to do this in a programmatic way without risking errors.

[dlh28]

@saumier what about adding an alternateName value instead? Do you think this would be preferable to containedinPlace? Or should we just stick to recommending the longer string?