W3C home > Mailing lists > Public > public-esw-thes@w3.org > December 2016

Integration of preservation vocabularies at id.loc.gov within the PREMIS ontology

From: <bertrand.caron@bnf.fr>
Date: Mon, 5 Dec 2016 19:14:03 +0100
To: public-esw-thes@w3.org
Cc: premis-ontology-2016@googlegroups.com
Message-ID: <OF8C41CB7B.F3584A19-ONC1258080.005D5DBE-C1258080.00642A04@LocalDomain>
Dear all,

Sorry if a question of this kind has already been asked to this group, I 
haven't got the courage to browse through the whole mail archives...

The PREMIS Editorial Committee is currently revising the PREMIS OWL 
ontology. A previous version, based on PREMIS version 2 was published in 
June 2013 (see http://www.loc.gov/standards/premis/ontology/index.html). 
As the PREMIS Data Dictionary version 3 was issued in December 2015, the 
ontology had to be updated to reflect the main new feature of v. 3, which 
aims at describing technical dependencies between digital or physical 
Objects and hardware or software Environments. In the future version of 
the ontology, the PEC decided that the modelling approach should be 
changed to be more consistent with linked data principles. This evolution 
implied in particular that the PREMIS ontology should reuse existing 
vocabularies (in the previous one, all vocabularies were defined in the 
PREMIS namespace) and that preservation vocabularies hosted by the LoC at 
id.loc.gov and maintained by the PEC (
http://id.loc.gov/vocabulary/preservation) should be integrated as 
subclasses / subproperties of PREMIS abstract classes / properties.
For example, <http://id.loc.gov/vocabulary/preservation/eventType/cre>, 
which describes a creation Event, would be declared a subclass of 
premis:Event.

Nevertheless, vocabularies at id.loc.gov are defined as instances of 
skos:Concept and madsrdf:Topic.According to 
https://www.w3.org/TR/skos-primer/#secskosowl, SKOS does not forbid that, 
but mentions a potential problem if implementers use OWL-DL, in which a 
resource cannot be both an individual and a class. On the other hand, 
MADS-RDF clearly distinguishes the concept and the real-world object it is 
identifying (see 
http://www.loc.gov/standards/mads/rdf/v1.html#identifiesRWO, which is a 
subproperty of foaf:focus).

It is also worth noting that these preservation vocabularies at id.loc.gov 
are not used exclusively for linked data; most implementers are using them 
in relational databases and XML files.

So IMHO the most rigorous solution (though not the simplest, probably), 
would be to create a different URI for all elements taken from the 
preservation vocabularies and to bind them to the skos:Concept by a 
"foaf:focus" property.

In practice, that would mean inserting a snippet like the one below in 
each vocabulary member we want to reuse, for example in 
http://id.loc.gov/vocabulary/preservation/environmentFunctionType/har 
which describes any kind of hardware Environment:

<foaf:focus xmlns:foaf="http://xmlns.com/foaf/0.1/">
      <owl:class xmlns:owl="http://www.w3.org/2002/07/owl#" rdf:about="
http://id.loc.gov/vocabulary/preservation/environmentFunctionType/har#rwo
">
        <rdfs:subClassOf xmlns:rdfs="https://www.w3.org/TR/rdf-schema/" 
xmlns:premis="http://www.loc.gov/premis/rdf/v3" rdf:resource="
premis:Environment"/>
      </owl:class>
    </foaf:focus>

In this case, resources describing specific hardware products created by 
users of the ontology should be instances of the class <
http://id.loc.gov/vocabulary/preservation/environmentFunctionType/har#rwo>

I also enclose in this mail a diagram to show what this solution should 
look like.

Has any of you faced such a question? Do you think the answer above 
addresses correctly our problem?

Thank you very much for your help.

All the best,


Bertrand Caron
Département des Métadonnées
Bibliothèque nationale de France
Quai François Mauriac
75706 Paris Cedex 13
01 53 79 42 23
bertrand.caron@bnf.fr

Participez à la rénovation de Richelieu Avant d'imprimer, pensez à l'environnement. 

Received on Thursday, 8 December 2016 19:35:45 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:46:51 UTC