Thanks for these suggestions and observations, Vladimir. We're in the
process of discussing your points, and I'll reply below to a few that
I think I know the answers to. (Others may contribute to this
conversation to clarify, add to, or disagree with my comments.)
> 1. Only familial/intimate/servant/slave, not professional (student,
> workshop of), nor groups. Professional are covered by AgRelOn and are needed
> by Getty ULAN. Ain't they in scope?
No, I don't think we felt we had a use-case for that yet. People in
the ancient prosopographies we're working with are commonly identified
as "Diogenes son of Aristarchos", "Metella wife of Philippos" or
"Corax freedman of Caracalla" but not "Isak office-mate of
Sebastianus" or "Barbara line-manager of Fidella". If we some day want
to ingest a prosopography that does record these kind of non-familial
relationships (maybe Ethan's Kerameikos database has some examples)
then we'll look at things like AgRelOn as an extension to SNAP.
> 2. All relations modeled as classes (good, allows for
> time/place/qualification). But the modeling of relations is asymmetric, even
> for inherently symmetric relations. Eg
> <person1> snap:has-bond <person1/sibling>.
> <person1/sibling> a snap:Sibling; snap:bond-with <person2>.
> So eg to find all siblings of <person2>, one needs to use complicated
> queries searching in both directions.
We considered modelling the Bond class slightly differently to allow
this sort of thing, but at present didn't think it would solve any
problems (and would cause a few others, among them added complexity of
modelling). This is open to renegotiation in the future, of course.
> 3. No abstraction of gender: many links implicitly say stuff about the
> gender of the linked people
Since most of our prosopographies don't explicitly assign gender to
individuals, we felt it wasnt' our place to do so. If we could
abstract that information from certain relations, for example, then so
could others. Again, this could be done at a later date if it turned
out to be valuable. (But I'd still be nervous about _how_ to define
gender/sex in the absence of a sensible, inclusive standard for doing
> 5. associatedDate & associatedPlace listed as both data and object
> properties? Protege got confused
That's just an error; snap:associatedDate should be data, and
snap:associatedPlace should be object. I hope this will be fixed in
the latest version of the ontology.
> 10. hi-jacking others' ontologies: efrbroo:F10_Person equivalentClass
This equivalence isn't declared by SNAP, but (and only indirectly) by
LAWD and CIDOC (and appears in our ontology only via reasoning on the
ontologies we import. It's confusing, but I don't think it's our
> 3. cnt:chars is not widely used outside the OA community, and there mostly
> for structured text (eg an SVG shape). Better use rdf:value or rdfs:label?
Agreed that cnt:chars was being misused on Place and Bond: we've
replaced both of those with rdfs:label, as suggested. On Attestation
and Citation, however, the object being described *is* a string of
text, not just labelled by that text, so neither title, value nor
label would really work. cnt:ContentAsText does exactly what it says
on the tin here.
> 4. Prefer DCT instead of DC, because DCT defines ObjectProperties as
> appropriate. Eg use dct: for dc:publisher, dc:replaces
This is of course arbitrary, but agreed, dct: is more usual. Changed.
> 5. The use of dc:identifier to link to other URLs for the same person
> (VIAF, DBpedia) is unusual. Both dc:identifier and dct:identifier allow
> literals. Better use rdfs:isDefinedBy or rdfs:seeAlso (but perhaps not
> owl:sameAs, which implies "smushing" semantics)
This is a good point, but we don't think isDefinedBy or seeAlso are a
very good fit either. isDefinedBy is too specific, since the referrent
of such a URI may not in fact define the current person, but just
claims to refer to the same person. Conversely, rdfs:seeAlso is not
specific enough, since we really want a term that we can unambiguously
use when and only when we mean "if two records both point to the same
URL here, then they are the same person". To use a modern example, a
prosopographical entry for Sonia Greene might well say "rdfs:seeAlso"
-> the Wikipedia entry for HP Lovecraft, since she doesn't have her
own WP entry. We wouldn't want our database to then assume that they
are the same person, since they're clearly not. I agree with you that
owl:sameAs brings too much baggage with it, since it would imply that
everything we say in one record should be taken as true of the other,
which just doesn't work. Identifier has the right semantics, although
as you say our putting URIs in there is a bit clunky. Happy for other
suggestions from the list?
> 8. Include the inverse link dct:isReplacedBy on the snap:MergedResource
This might not hurt, but as far as I can see the only benefit it would
have would be to make SPARQL queries a bit easier? We're actually
doing the querying we'd need to create this in the process of building
the human-readable person page over the triplestore, so it's sort of
simultaneously (a) easy and (b) not necessary. One objection is the
issue of maintaining the same piece of information in two places,
leading to the danger of that falling out of synch. Again though, it
would be easy to add this later if we decided it was useful.
Thanks again for your very thoughtful and attentive examination of our
We hope to have a new version of the ontology and Cookbook (and a
first stable, public-facing version of the core data) to share with
you in the next few weeks.
Dr Gabriel BODARD
Researcher in Digital Epigraphy
King's College London
Boris Karloff Building
26-29 Drury Lane
London WC2B 5RL
Tel: +44 (0)20 7848 1388
Fax: +44 (0)20 7848 2980