crm:P62_depicts is wrong for AAA objects

[VladimirAlexiev]

Copying @workergnome @azaroth42 since this change would not sit well with the application, so is for version 2.

Consider http://data.americanartcollaborative.org/page/aaa/object/178 which says
crm:P62_depicts <institution/37>, <person/154>.

But this item https://www.aaa.si.edu/collections/items/detail/william-wyman-178
is "A letter to the administration of the Massachusetts College of Art in which Wyman recommending the purchase gas-fired pottery kilns."
The letter depicts neither Wyman nor the College (it's quite business like and there are no depictions nor doodles of any sort on it). So we have to do:

<object/178> crm:P128_carries <object/178/concept>.
<object/178/concept> crm:P67_refers_to <institution/37>, <person/154>.

Most AAA items are NOT pictures or paintings but documentary items, so the same applies to most.

[tobiashreiter]

I already replied to others by email, but we are happy to use refers_to instead of depicts.

[VladimirAlexiev]

Please note there's an intermediate node in addition to refers_to. And I think this would disrupt @workergnome's aplication

[tobiashreiter]

After glancing at the documentation again, I think I can see that the problem is that refers to is connected, basically, to an intellectual work (what the model calls a conceptual object), whereas our items are modeled as man-made objects.

Almost of the items we've supplied (with a handful of exceptions) contain intellectual works, and could easily have an associated intellectual work node (which would essentially have much of the same attributes as the physical object).

Are you saying we simply don't have any place in the current application to model intellectual works?

[workergnome]

Hey, all—

The pattern that @VladimirAlexiev is suggesting is very similar to what we've been using for "subject of". http://review.americanartcollaborative.org/entity/E22_Man-Made_Object#field_13-search_0

@azaroth42 and I have also been trying to figure out appropriate methods for distinguishing between intellectual works and physical object, and where the split occurs—There's a lot of talk around this in the library world, since you almost inevitably end up with a physical object, a conceptual object, and an 'edition', since there are often multiple editions or versions of the same intellectual work.

For artwork, we've been trying hard to avoid splitting the two out, though I don't know that we're going to be able to sustain that. Archival material is so much more focused on the intellectual content that it makes that decision more immediate.

So.

All that said, there are two solutions that might work. One is what Vladimir is suggesting, which is probably the most robust solution, but to do it right might require a lot of thinking around what parts go conceptual and what parts go physical, and that's definitely a version 2 problem. I'm not opposed to special-casing this for this particular portion of the archives, since it's not going to conflict with anything else, but I'd rather not go down the whole conceptual/physical split right now in its entirety.

The other option is to use a simpler, non-CIDOC property, like dct:relation or dct:subject, to refer to the authority URI, and know that we'll model this fully in a later iteration.

[tobiashreiter]

@workergnome , thanks for the thoughtful examination of the issue. These kind of discussions are what got me interested in this field in the first place.

I think for now, we're definitely comfortable with using non-CIDOC properties to establish the relationship. As far as I know, we're already using non-CIDOC for certain elements of our data in AAC right now.

For version 2, I'd love to be involved in any discussions on how this intellectual/physical split happens, particularly for content coming from archives.

[VladimirAlexiev]

The job of archives and museums is to safeguard physical objects; and secondarily to research, present, expose, connect them.
Every MM physical object carries some conceptual content: even a scratch on a bone (may) carry some meaning (at least for the person who made it), thus is Inscription, a conceptual object.
The main difference is that conceptual objects cannot be destroyed (unless you destroy all photos of it, and kill all people who have seen it) and you can easily have numerous copies of them (whereas even a 3D printed copy of a physical object is considered a separate one).
How "intellectual" is the content represented by a conceptual object is a secondary thing.

Please note that <object> depicts <subject> is a shortcut:
<object> carries <visual image>. <visual image> refers to<subject>.
Unfortunately no such shortcut exists for non-visual aboutness, forcing us to use an intermediate conceptual node as above.

@tobiashreiter "we're already using non-CIDOC for certain element": please provide an example.

[tobiashreiter]

@VladimirAlexiev - again, I appreciate the thoughtful discussion this issue is raising. I'm very involved in the presentation of conceptual content, so I sometimes lose track of the physical preservation mandate (which is why I sometimes go visit the physical collections to remind myself about them).

As far as non-CIDOC examples, I probably should have been more precise to say that we're already using them as properties on certain elements. A simple example is foaf:homepage. There may be a sequence of entities and properties that could have been used to express this, but since foaf:homepage was already being used for existing (non-AAA) entities on the aac-browse site, this was the property I adopted in my "cheatsheet".

[VladimirAlexiev]

Currently even the value is wrong: literal instead of resource. Eg see http://data.americanartcollaborative.org/page/aaa/object/200:
crm:P62_depicts "person/166"

[tobiashreiter]

I think this came up when we were first reviewing the mapping. Is this something you can correct yourself? Thanks!

…

On Wed, Jun 21, 2017 at 8:34 AM, Vladimir Alexiev ***@***.***> wrote: Currently even the value is wrong: literal instead of resource. Eg see http://data.americanartcollaborative.org/page/aaa/object/200: crm:P62_depicts "person/166" — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#12 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AXLDaHiaXWgMT2uTza3xED9qa7U-DQrQks5sGQ3cgaJpZM4NcuNQ> .

[VladimirAlexiev]

Yes, it should be fixed in the mapping

[tobiashreiter]

This is now fixed.