WEMI as SKOS concepts

[kcoyle]

It has been suggested that WEMI could be defined as SKOS concepts. (This may be in addition to or in place of WEMI as RDF classes.) Examples are greatly encouraged.

[tombaker]

@kcoyle I can come up with an example. If there is already an example of how WEMI would be used as RDF classes, I could perhaps modify that example so that the difference is clear.

[kcoyle]

Here is an example taken from the FaBiO documentation by @essepuntato. What is important is that fabio classes are subclassed or sub-subclassed to one of the FRBRcore entities. (vocab.org is broken, so use the archived version to view that vocabulary.) So WEMI comes in by inference, which is how openWEMI should be used, IMO. Obviously you can just grab a bit to do your example, and change up what you need.

# Example of use of FaBiO #1 # August 18, 2015 # by Silvio Peroni

# This work is licensed under a Creative Commons Attribution 4.0 # International License (http://creativecommons.org/licenses/by/4.0/). # You are free to: # * Share - copy and redistribute the material in any medium or format # * Adapt - remix, transform, and build upon the material # for any purpose, even commercially.

# The licensor cannot revoke these freedoms as long as you follow # the license terms.

# Under the following terms: # * Attribution - You must give appropriate credit, provide a link # to the license, and indicate if changes were made. You may do so # in any reasonable manner, but not in any way that suggests the # licensor endorses you or your use.

@prefix : http://www.sparontologies.net/example/ . @prefix fabio: http://purl.org/spar/fabio/ . @prefix frbr: http://purl.org/vocab/frbr/core# . @prefix prism: http://prismstandard.org/namespaces/basic/2.0/ . @prefix rdf: http://www.w3.org/1999/02/22-rdf-syntax-ns# . @prefix rdfs: http://www.w3.org/2000/01/rdf-schema# . @prefix xsd: http://www.w3.org/2001/XMLSchema# . @prefix dcterms: http://purl.org/dc/terms/ . @prefix foaf: http://xmlns.com/foaf/0.1/ . @prefix application: http://purl.org/NET/mediatypes/application/ .

:opjk-and-diligent a fabio:ResearchPaper ; dcterms:creator :casanovas , :casellas, :tempich, :vrandecic, :benjamins ; frbr:realization :version-of-record .

:version-of-record a fabio:JournalArticle ; dcterms:title "OPJK and DILIGENT: ontology modeling in a distributed environment" ; fabio:hasPublicationYear "2007"^^xsd:gYear ; prism:doi "10.1007/s10506-007-9036-2" ; frbr:embodiment :printed , :pdf ; frbr:partOf :ai-and-law-15-2 .

:ai-and-law-15-2 a fabio:JournalIssue ; prism:issueIdentifier "2" ; frbr:embodiment :printed-issue ; frbr:partOf :ai-and-law-15 .

:ai-and-law-15 a fabio:JournalVolume ; prism:volume "15" ; frbr:partOf :ai-and-law .

:ai-and-law a fabio:Journal ; dcterms:title "Artificial Intelligence and Law" .

:printed-issue a fabio:Paperback ; dcterms:publisher :springer ; prism:publicationDate "2007-06"^^xsd:gYearMonth ; frbr:part :printed .

:printed a fabio:PrintObject ; dcterms:publisher :springer ; prism:publicationDate "2007-06"^^xsd:gYearMonth ; prism:startingPage "171" ; prism:endingPage "186" .

:pdf a fabio:DigitalManifestation ; dcterms:publisher :springer ; dcterms:format application:pdf ; prism:publicationDate "2007-05-31"^^xsd:date .

:casanovas a foaf:Person ; foaf:givenName "Pompeu" ; foaf:familyName "Casanovas" .

:casellas a foaf:Person ; foaf:givenName "Nuria" ; foaf:familyName "Casellas" .

:tempich a foaf:Person ; foaf:givenName "Christoph" ; foaf:familyName "Tempich" .

:vrandecic a foaf:Person ; foaf:givenName "Denny" ; foaf:familyName "Vrandečić" .

:benjamins a foaf:Person ; foaf:givenName "Richard" ; foaf:familyName "Benjamins" .

:springer a foaf:Organization ; foaf:name "Springer" .

[tombaker]

@kcoyle The openWEMI draft describes six classes -- four WEMI classes (Work, Expression, Manifestation, Item), all of which subclasses of Endeavor, plus ResponsibleEntity -- and four properties: relatedEndeavor, plus three "EMI" properties (expresses, manifests, and instantiates) which have as range the "WEM" classes, so I was expecting the example above to show how these properties and classes would be used in data.

Are you saying that the openWEMI classes are not intended to be used directly in data, but rather as drop-in replacements for the classes of the abandoned FRBRcore vocabulary of 2005 -- specifically, to serve as superclasses for classes like ResearchPaper, JournalArticle, JournalIssue, and JournalVolume?

If so, I guess I would be looking for an example not of instance data, but of a vocabulary where the classes ResearchPaper, etc, were related (presumably as subclasses) to the openWEMI classes.

[tombaker]

I ended up providing an example of how a WEMI entity could be expressed in instance data using a SKOS concept at the end of my opening post for a new issue "WEMI entities as data shapes?".

[kcoyle]

Are you saying that the openWEMI classes are not intended to be used directly in data, but rather as drop-in replacements for the classes of the abandoned FRBRcore vocabulary of 2005 -- specifically, to serve as superclasses for classes like ResearchPaper, JournalArticle, JournalIssue, and JournalVolume?

They COULD be used directly in data, but for many applications they are overly broad. As superclasses in RDF they allow for searching at any level of the sub/super link. I can imagine that they could be applied to data "after the fact" such as giving the classes openWEMI:Work and openWEMI:Expression to the BIBFRAME Work.

The openWEMI draft describes six classes

I actually made this issue #1 - frbrcore created this superclass, which to me made more sense in the strict FRBR-ness of that vocabulary. I'm not sure it makes sense with the open-ness of openWEMI.

The FaBiO documentation is the vocabulary for the example I gave.

[kcoyle]

I gave the wrong link for the FaBiO documentation. It's https://sparontologies.github.io/fabio/current/fabio.html. What I gave you above was just an example document. The FaBiO documentation is interesting for its extensive use of classes, but it isn't the only way to do things, of course.

[tombaker]

Re-reading these issues I am reminded that my unease with the notion of WEMI entities as instances of RDF classes has remained essentially unchanged since July 2022, when I asked whether the entities might more properly be conceptualized as SKOS concepts or even data shapes. However, some of the points made over the last two weeks have brought this option better into focus:

• @annakasprzik is also "in favour of not interpreting WEMI as something absolute but in view of the intent in a metadata scenario -- so: in the moment of creating (or using) metadata for something, what is the aspect the description is focussing on in order to fit the use case?"
• Anna points to a 2008 paper by Renear and Dubin, which argues that three of the four WEMI "entity types" are actually roles, not types -- roles specific to "particular social contexts" or "contingent circumstances" rather than "fundamental ontological types" or "genuine types".
• @danbri has at times considered the notion of "annotating" things with property-value pairs that address FRBR-ish distinctions -- for example, by coining a wemiCode property to use with values such as Work or Item with the intention of providing a hint that a given description should be taken as referring to things that are more abstract, or more specific.
• Dan adds: "Typing seems somehow more grand and serious" -- a comment :in line with "not interpreting WEMI as something absolute" (Anna) or as "genuine type" (Guarino, in Reanar and Dubin) or "things that supposedly are 'essentially' Ws, Es, Ms, or Is" (myself, two weeks ago).

I am also reminded of the Scholarly Works Application Profile (SWAP, aka Eprints AP) -- a FRBR-based application profile proposed by Julie Allinson and Andy Powell in 2006-2008. The profile consisted of FRBR-ish descriptions typed not with RDF classes, but with the Eprints EntityType Vocabulary Encoding Scheme -- "a simple vocabulary for use with the dc:type property". In the Dublin Core jargon of the day, a "vocabulary encoding scheme" was something that we would today define as a SKOS concept scheme. The Eprints EntityType Vocabulary uses PURLs to define things such as "ScholarlyWork" (http://purl.org/eprint/entityType/ScholarlyWork) which, according to the Wayback Machine, once resolved simply to the webpage for the Eprints EntityType Vocabulary Encoding Scheme. I take the PURL for "ScholarlyWork" to be, essentially, a SKOS concept.

If FRBR things were defined as SKOS concepts, how could they be used in data? At least two possibilities have been mentioned:

• with the property dc:type (as in SWAP/EprintsAP).
• with a property along the lines of wemiCode (as Dan has suggested).

Triples using either property could be used to match data shapes. Ontologically, such assertions would provide nothing grander than hints or annotations.

[kcoyle]

@tombaker There is no reason not to also create a skos vocabulary with WEMI, but SKOS does not allow folks to use WEMI subclasses to define domains and ranges, and that latter is what they are already doing with vocab.org's frbrcore. So this is a response to that need, and does not preclude other forms of WEMI, like SKOS or XML (which is what the akoma folks use).

[aisaac]

Yes if properties need some domain and range among the OpenWEMI entities, then mechanically they would end up as RDFS classes. This said I have nothing against using RDFS classes as SKOS concepts too, without having to re-define new URIs. This is allowed in SKOS anyway.