search

lcnetdev / bibframe-ontology

Repository for versions of BIBFRAME ontology.
http://www.loc.gov/bibframe/
50 stars 7 forks source link

Remove range of bf:place and bf:originPlace to provide for objects that are not typed bf:Place #19

Closed sfolsom closed 3 years ago

sfolsom commented 6 years ago

Justification: By removing range of bf:place, objects that are not typed bf:Place will not have undesirable entailments. E.g. We want to use bf:place to link to GeoNames entities, but not have those entities entailed as type bf:Place.

[This recommendation was made on behalf of the LD4P Art & Rare Materials BIBFRAME Ontology Extension (https://github.com/LD4P/arm).]

kefo commented 5 years ago

Out of curiosity, can you provide an example of how this produces an undesirable entailment?

Under what circumstances would an entailment that concludes a given GeoName resource is also a bf:Place, be a problem or possibly untrue?

sfolsom commented 5 years ago

Maybe Geonames is a bad example; geonames:Features and bf:Place definitions are pretty similar. That said, one might want to ward off class pollution and keep a clean representation of Geonames entities as they intended them to be described. A more likely situation is when a place is modeled as a skos:Concept or madsrdf:Authority, and while they are not bf:Places, a profile may want to link to them using bf:place.

sfolsom commented 5 years ago

re: ARM related requests for changes to BF, I’ve responded above to give more context about the thought process at the time we made these requests. I've reached out to folks still affiliated ARM to consider how they want to weigh in.

Generally, the domain and range questions are a design decision... how much do you want to rely on these type assertions, how comfortable are you with assigning type to entities you didn't mint, and... many folks confuse domain and ranges for validation instead of inferencing which can lead to a chilling effect on the use of these properties.

ntra00 commented 4 years ago

For consistency purposes, I'm adding bf:originPlace to this request. See new title

melanieWacker commented 3 years ago

PoCo also voted in favor (Dec. 2020) of removing the range of bf:Place from bf:place. This is an outcome of the final report of the PCC Task Group on Sinopia Application Profiles (https://www.loc.gov/aba/pcc/taskgroup/Sinopia-Profiles-TG-Final-Report.pdf) From the report "The addition of ranges to BF properties introduces challenges regarding inferencing and linked data best practices. At a practical level, a range may restrict the breadth of possible vocabularies that are usable according to best practice.

kefo commented 3 years ago

https://id.loc.gov/ontologies/bibframe.html#p_place https://id.loc.gov/ontologies/bibframe.html#p_originPlace

azaroth42 commented 6 months ago

I can't help myself. This was a terrible decision in my opinion. It makes the ontology completely unable to be validated in any meaningful sense, and at the same time makes it significantly harder to understand. Instead of throwing out the entire conceptual model, just turn off inferencing in your implementation. This (and similar issues, e.g. for language) is putting the fully loaded cart on top of the horse, and thereby breaking its back.