search

vivo-project / VIVO

VIVO is an extensible semantic web application for research discovery and showcasing scholarly work
http://vivoweb.org
BSD 3-Clause "New" or "Revised" License
206 stars 129 forks source link

VIVO-1239: vCard gets treated like an article for some faux properties #2830

Open chenejac opened 8 years ago

chenejac commented 8 years ago

Graham Triggs (Migrated from VIVO-1239) said:

We allow vCards to be used for authors, in place of foaf:Person. Normally, these are not linked, but you can end up browsing to / displaying a vCard in VIVO (I've been looking at extending the co-author network to allow vCards to be optionally displayed alongside people, which then has a click through).

The vCard is a subtype of Information Content Entity - which is also a super type for Articles, etc., and happens to be the type used as a domain for the faux property "authors".

So vCards claim to author themselves! Ideally, the domain of "authors" should be changed to not include vCards, and vCards should have a faux property for "author of".

chenejac commented 8 years ago

Mike Conlon said:

Would like to consider a roadmap for eliminating vcards in authorships. New code would create foaf:Person with the same vcard as now as contact information. The foaf:Person would appear in the authorship. Existing code would need to look for author names on the vcard of the person in an authorship, as well as any legacy vcards attached to the authorship.

We could distribute a utility to update the triple store to add foaf:Person for all the current orphan vcards.

We have an installed base of triple stores with vcards attached to authorships. We would need to maintain functionality around this through several future releases, but we would discontinue creating vcards attached to authorships.

We would announce an "intention to discontinue" (deprecated) for vcards in authorships, which would last two years (?). At the end of that time, a release of VIVO would no longer support vcards attached to authorships.

It is an interesting case, since current user code must already handle both cases -- names on vcards attached to authorships, and names on vcards attached to persons attached to authorships. So the change to require foaf:Person might be considered a simplification.

Of course, corporate authors are still not foaf:Person. Authors are either foaf:Person or foaf:Group. Needs extensive discussion with OpenRIF, Interest Groups, governance, before any proposed change.

chenejac commented 7 years ago

Benjamin Gross said:

As discussed during the previous developer call, if we choose to switch back to using foaf:Person for the vCard 'people' we need to use a property that indicates that the foaf:Person object is not to be linked in order to mimic the current behavior for author lists and co-author networks. We currently do not attempt to perform any disambiguation for vCards and we don't want to pollute the co-author network, browse people page, etc. with dozens of records for what is probably the same person (but we don't know and don't have time to confirm). core:hideFromDisplay isn't quite right since we still want to show the name in author list views, but at least in some implementations, that's the only place.