search

omeka / plugin-ItemRelations

Allows administrators to define relations between items.
https://omeka.org/classic/plugins/ItemRelations/
7 stars 23 forks source link

Include all of Dublin Core #5

Closed patrickmj closed 12 years ago

patrickmj commented 12 years ago

Some DC predicates seem to be missing, but could be useful. dc:creator, for example, would make sense to include to build a relation to an Item with item type Person

jimsafley commented 12 years ago

Currently the plugin includes only dcterms:source, dcterms:relation, and properties that refine dcterms:relation. The RDF schema's range mechanism can inform us on which other Dublin Core properties can appropriately define a relationship between Omeka items.

For a property to make sense as a relation between two items, the object item must logically conform to a rdfs:Class within that property's rdfs:range.

Makes sense

Questionable

Doesn't make sense

Properties without rdfs:range

patrickmj commented 12 years ago

The lists bring up a nifty set of implications when we think about the inferences. It seems like we are implicitly imagining an Omeka ontology, where we would have an omeka:Item class for our Items. Then we'd also be saying that the dcterms classes are subClasses of omeka:Item. If we include the dcterms:creator property between two items, then the object Item is a dcterms:Creator. None of that is actually exposed as RDF to a machine reasoner and the Omeka Ontology doesn't actually exist (yet!), but it seems like that'd be the implication.

But, if we also go with the idea that an item in Omeka can be anything, then it seems like there's no reason to leave out any of the dcterms classes. If items are wide open, it's hard to find clear reasons why some classes are questionable and others not. For example, both dcterms:LicenseDocument and dcterms:PolicyStatement look to me like subclasses of foaf:Document (though admittedly they don't make that assertion). If one can be an Item, why not the other?

And so, I'd vote for including everything in the questionable category.

I feel a little itchy about it, but this also implies that the only thing that should be excluded from the doesn't make sense category is Literal. Frequency and SizeOrDuration do seem weird to me, but no more weird than how we handle Dublin Core elsewhere, and consistency with above seems to require it. Class is weird in a different way, since it's specifically an abstraction, whereas most of the time we think of items as concrete things, but the utility of using dcterms:type makes me think that if people want to make an abstraction an item, why not?

I think most, if not all, of the properties without a range are already in the list of relations, but if any aren't I'd include those as well. The reasoning being that, if DC is silent about the range, no reason for us to build in a restriction. Most lend themselves very easily to item->item predicates, but even non-intuitive ones like dcterms:description, I can imagine use cases for.

If we do take a more restrictive approach, though, dcterms:instructionalMethod should definitely be there, since dcterms:MethodOfInstruction seems close enough to our Lesson Plan item type.

jimsafley commented 12 years ago

After some discussion about the nature of omeka:Item, we concluded that we should add every property in the dcterms namespace, save for those with range rdfs:Literal.