Agenda

Calls are held every other Wednesday at 11 AM Eastern Time.

Please add or suggest any additional items

Updates

Brown (Steven) – working on the "hasIssue" question discussed below. Also dealing with technical reports (pamphlets or papers put out by departments as opposed to being published). Who would be listed as the publisher – it's publishing in the way that putting up a web page is publishing. Some departments have technical reports series or newsletters that have the mode of a particular publishing date.
Duke (Demaris) – making a lot of progress in working with the communications person in Arts & Sciences to identify the additional fields to capture and have met with a department director; are moving to defining the UI, and have met with the developers to talk about the UI and workflow around adding collaborators. Also had a demo from the Symplectic team for adding artistic works within Elements. Still hoping to hit the September deadline.
- Are working on a SPARQL endpoint that will be public
- SciVal publications from ReachNC get to Elements first and then to VIVO
Florida (Nicholas) – working on designing an application that will run SPARQL queries on VIVO data to check the integrity of VIVO data, based on about 10 different factors such as duplicate labels, and will be extensible, but is limited to reporting, not making changes
- (Paul) – hope you can share it – Nicholas will
Johns Hopkins (Jing) – medical campus is implemented SciVal so we are trying to get that up first and see how it integrates with VIVO; not sure whether they will make a SPARQL endpoint of VIVO data available, or how data will be fed to SciVal
- Attended the ELAG (European Library Automation Group Conference) – The keynote talk by Herbert Van de Sompel is about research object model that encompass open annotations, provenance, and OAI-ORE.
- Did a presentation on authority control in linked data
Memorial University
NARCIS
North Texas
Scripps (Michaeleen) – starting to prepare for ingesting grants by verifying department affiliations, etc. Heard that Texas A&M will be adopting VIVO
Virginia Tech
Weill Cornell (Paul) – finally got some clarification and found that tracks serve as the basis of position definitions, picking up on a discussion about a year ago. Also working a little bit on a more compact version of the profile – working a little bit on some of the Freemarker templates
- Steve – has been playing around with the Freemarker templates and custom forms.
Cornell Ithaca (Brian) – working on the behind-the-scenes code changes; the ISF has had a beta release and we are in the process of moving classes and properties out of the big files that reflect the legacy of what came from VIVO and what came from eagle-i into files with the same kinds of content in more digestible pieces. There will be some minor additions and changes still, but we are still looking at a final release the end of July.

Discussion Topics

Why is the vivo:linkURI property of a vivo:URLLink not an object property?

(Griffin)

see the extended discussion about Representing internal and external links in the VIVO ontology.

Shedding light on the reasoning behind the two "editor" properties

(Patrick and Sheri at Duke, commenting a few weeks later: 2013-07-03): The discussion below matches what we were just considering concerning Editorships. We also need Translatorships, and think it makes sense to treat them in the same way. We are planning to implement this soon, so we'll do it in our local extension first. Glad you all had just discussed it!

(Steven)

Paul responded: editorOf is similar to authorInAuthorship. This would apply to a specific publication published on a particular date - an article, a book.
On the other hand, the editor role refers more to an ongoing activity in, often enough, a journal's publication management team (e.g. Dr. X is editor of/at the journal Nature). This is not a contribution defined by a particular date, but is more likely to be associated with a certain time range.
That said, I think the distinction is confusing enough to end users that our team is considering hiding the editorOf property from them. We have no authoritative source for these data, and it would probably be used fairly infrequently. What we might lose in comprehensiveness, we might gain in clarity.
(Jon) Paul has nailed down the distinction in intent perfectly. He's also right that (as is Steven, who raised the question) that it's confusing. Some thoughts
- we should at least be consistent in supporting the same pattern for an editor as for an author, via an Editorship comparable to an Authorship. We originally set up the direct editorOf property thinking that multiple editors would be rare and not likely have an established order, which has proven false in an example close to home (look in "additional document info").
- We had some discussions with Hal Warren and Brian Dennis of the APA at the Implementation Fest in Boulder about peer review systems, and what is meant by being editor of a journal is also not clear, and doesn't cover being a reviewer for an article or journal. Quite apart from terminology, they consider individual reviewer information to be highly confidential, even at the level of being a reviewer for a journal, not just an individual article.
- In the ISF, we think of an editor relationship distinctly from an editor role – the relationship connects a person with a continuant entity such as an information resource (an article or journal), while an editor role is realized in a process such as a writing or organizing process. Both may have temporal extent, although in the case of representing a person's editorship of a book there will rarely be any information available about time bounds apart from the publication date of the book.
  - Most existing vivo:EditorRole individuals will be migrated to be vivo:Editorships; the same vivo:Relationship can hold between a foaf:Person and a bibo:Book or a foaf:Person and a bibo:Journal.
  - It will likely be more rare to have information about actual editing processes in which a vivo:EditorRole would be realized
- we are looking with the ISF for being able to represent relationships that get established while still representing participation through roles

VIVO > 2013-06-12 VIVO Ontology Call > EditorShipsAndRoles.png

vivo:hasPart and modeling journal issues

(Steven)

First: the VIVO ontology has the relationship "hasPart" (inverse, "partOf"). I see that the Dublin Core terms property of the same name ("dcterms:hasPart") is not included in the VIVO ontology. Are these the same property, or at least, serving the same function? I don't see any mention in the vivo:hasPart record.
- (Jon) The dcterms:hasPart is an RDF property that can be used as either an object property or data property. Since vivo:hasPart and its inverse are intended to be used as object properties only, we did not re-use the dcterms:hasPart.
- (Brian) in the ISF we will be using the relations ontology "has part" rather than one we've minted on our own
We need to represent an individual "Issue" separately from a "Journal" because we're seeing citations like "editor of special issue of Quarterly Journal of Economics". In VIVO, we're currently associating Articles directly with Journals (via "hasPublicationVenue"), without any intermediate Issue object. Keeping track of issues will add complexity, especially considering that much issue information, like "Volume," is currently attached to Article objects via data properties.
There's no reason why an Article can't be associated with both an Issue and a Journal, or just an Issue, or just a Journal. If users want to add Issue data, they can; and if not, it's not necessary. However, this will be something to keep an eye on in the future, if we want to merge VIVO with more developed bibliographic databases (like, say, our university library). There, we're likely to have lists of issues for journal titles, and we'll need to see about mapping the attendant Article data onto the issue data.
The other problem is more abstract, namely: is the relationship between Issue and Journal really that of part to a whole? In some ways, a Journal title is just a label for the full sequence of Issues. This is more of a theoretical concern, however. For the time being, it seems to work for both BIBO and DC, so we may as well run with it; but I'm going to do a little more research into that.
So, I wanted to lay out our reasoning. I believe we'll add two new properties, "issueOf" and "hasIssue."
(Michaeleen) there has been a special issue of a journal where all the articles were by Scripps authors

Further discussion of ISF changes

The generic Relationship class and the related/relatedBy properties
- (Brian) --
skos:Concept punning with academic degrees

Concept for soliciting end user feedback about authoritative sources in VIVO

Paul has prepared a mockup of a suggested approach that relates more to application behavior than the ontology but is likely of interest to this group.