Subclassing ORE RDFS in BIBO OWL
Mark Diggory
I wanted to begin exploring the idea of utilizing ORE as a base
ontology for BIBO. This project would involve utilizing the ORE
properties and types as a basis for defining container-ship/
aggregation in BIBO. The idea being to allow the ability to treat
certain "BIBO Collections" as "ORE Aggregations" and "BIBO Documents"
as "ORE AggregatedResources" in RDF processing/triplestores without
having to explicitly assert properties/types from the ORE ontology.
To give you an example of the dilemma I'm attempting to solve, here
is an example trying to express a resource as both an ore:Aggregation
and a bibo:Issue or bibo:Articles.
> <info:hdl/1234.5/67890>
> a bibo:Issue, ore:Aggregation;
> dcterms:hasPart <info:hdl/1234.5/67890/1>;
> dcterms:hasPart <info:hdl/1234.5/67890/2>;
> dcterms:hasPart <info:hdl/1234.5/67890/3>;
> dcterms:hasPart <info:hdl/1234.5/67890/4>;
> ore:aggregates <info:hdl/1234.5/67890/1>;
> ore:aggregates <info:hdl/1234.5/67890/2>;
> ore:aggregates <info:hdl/1234.5/67890/3>;
> ore:aggregates <info:hdl/1234.5/67890/4>.
>
> <info:hdl/1234.5/67890/1>
> a bibo:Article, ore:AggregatedResource;
> ore:aggregatedBy <info:hdl/1234.5/67890>;
> dcterms:isPartOf <info:hdl/1234.5/67890>.
The point being that to assert my resources state as both an ORE
Aggregation and a BIBO Journal Issue, I am left with the difficulty
of replicating references of both types in the same instance... seems
both bloating and arduous. I'd rather just state the following and
have it mean the same:
> <info:hdl/1234.5/67890>
> a bibo:Issue;
> bibo:hasArticle <info:hdl/1234.5/67890/1>;
> bibo:hasArticle <info:hdl/1234.5/67890/2>;
> bibo:hasArticle <info:hdl/1234.5/67890/3>;
> bibo:hasArticle <info:hdl/1234.5/67890/4>.
>
> <info:hdl/1234.5/67890/1>
> a bibo:Article;
> bibo:isPartOfIssue <info:hdl/1234.5/67890>.
In reviewing the ORE and BIBO ontology to explore combining
ontologies to resolve the above issue, I've been coming up against
the reuse of properties from DCMI directly (usually an appropriate
thing to do) that forces us not to be able to more specifically the
"type" of a DCMI hasPart/isPartOf relationship. I would like to give
you an example and get your feedback on how we may make the goal I'm
seeking a possible outcome.
If we look at bibo:Issue more closely, we see:
> bibo:Issue a owl:Class ;
> bibo:term_status "stable" ;
> rdfs:label "Issue"@en ;
> rdfs:comment "something that is printed or published and
> distributed, esp. a given number of a periodical"@en ;
> rdfs:isDefinedBy <http://purl.org/ontology/bibo/> ;
> rdfs:subClassOf bibo:CollectedDocument ;
> rdfs:subClassOf
> [ a owl:Restriction ;
> owl:allValuesFrom bibo:Article ;
> owl:onProperty dcterms:hasPart ] ;
> rdfs:subClassOf
> [ a owl:Restriction ;
> owl:minCardinality "1"^^<http://www.w3.org/2001/
> XMLSchema#int>
> ;
> owl:onProperty dcterms:hasPart ] .
In this case we see that we've placed a restriction on presence of a
"dcterms:hasPart". We know that RDF is open-ended and that, such a
state means that an instance of a resource at the time it is being
processed. This means that there can always be "more"
dcterms:hasPart assertions out there in the wild. In the past, RDF
Collections were recommended as a means to assert finite sets of
resources as a group, LoD recommends avoiding the use of RDF
Collection because they make working with SPARQL endpoints a bit
difficult. I'm suggesting that at least the suggestion of a finite
set can be conveyed within BIBO by refining an ontology that is
specifically designed for such matters, ORE.
I would like to explore making the appropriate subClasses of
bibo:Collection be a restriction on ore:Aggregation (from ORE RDFS).
> ore:Aggregation
> a s:Class;
> s:comment
> "A set of related resources (Aggregated Resources), grouped
> together such that the set can be treated as a single resource.
> This is the entity described within the ORE interoperability
> framework by a Resource Map.";
> s:isDefinedBy
> ore:;
> s:label
> "Aggregation";
> s:subClassOf
> dctype:Collection.
>
> ore:AggregatedResource
> a s:Class;
> s:comment
> "A resource which is included in an Aggregation. Note that
> asserting that a resource is a member of the class of Aggregated
> Resources does not imply anything other than that it is aggregated
> by at least one Aggregation.";
> s:isDefinedBy
> ore:;
> s:label
> "Aggregated Resource".
>
> ore:aggregates
> a r:Property;
> s:comment
> "Aggregations, by definition, aggregate resources. The
> ore:aggregates relationship expresses that the object resource is a
> member of the set of Aggregated Resources of the subject (the
> Aggregation). This relationship between the Aggregation and its
> Aggregated Resources is thus more specific than a simple part/whole
> relationship, as expressed by dcterms:hasPart for example.";
> s:domain
> ore:Aggregation;
> s:isDefinedBy
> ore:;
> s:label
> "Aggregates";
> s:range
> ore:AggregatedResource;
> s:subPropertyOf
> dcterms:hasPart;
> owl:inverseOf
> ore:isAggregatedBy.
>
And explore the possibility of defining a new property type for bibo
(restriction on dcterms:hasPart, ore:aggregates) which will allow us
to union and refine the meanings of such container-ship types
allowing them to be semantically restricted to mean "finite collection".
Thus we can refine off of the ORE types and thus assert custom
properties on individual bibo instances such as:
> bibo:Issue a owl:Class ;
> bibo:term_status "stable" ;
> rdfs:label "Issue"@en ;
> rdfs:comment "something that is printed or published and
> distributed, esp. a given number of a periodical"@en ;
> rdfs:isDefinedBy <http://purl.org/ontology/bibo/> ;
> rdfs:subClassOf bibo:CollectedDocument ;
> rdfs:subClassOf
> [ a owl:Restriction ;
> owl:allValuesFrom bibo:Article ;
> owl:onProperty bibo:hasArticle ] ; <--- changed from
> dcterms:hasPart!!!!
> rdfs:subClassOf
> [ a owl:Restriction ;
> owl:minCardinality "1"^^<http://www.w3.org/2001/
> XMLSchema#int>
> ;
> owl:onProperty bibo:hasArticle ] . <--- changed from
> dcterms:hasPart!!!!
> bibo:Article a owl:Class ;
> bibo:term_status "stable" ;
> rdfs:label "Article"@en ;
> rdfs:comment "A written composition in prose, usually
> nonfiction, on a specific topic, forming an independent part of a
> book or other publication, as a newspaper or magazine."@en ;
> rdfs:isDefinedBy <http://purl.org/ontology/bibo/> ;
> rdfs:subClassOf bibo:Document, ore:AgregatedResource .
> bibo:hasArticle a r:Property
> s:subPropertyOf
> dcterms:hasPart, ore:aggregates;
> s:domain
> bibo:Issue;
> s:isDefinedBy
> bibo:;
> s:label
> "Has Article";
> s:range
> bibo:Article;
The nice thing about approaching such refinements is that they become
well labeled and clearly defined in meaning. We work with tools such
as Simile Longwell, which can use such property definitions as hints
for the UI presentation, and in such situations Labels are then
specific to the type of Container/Contained relationship, for
instance, a Journal Issue asserts its articles as properties labeled
"Has Article", rather than the more generic "Has Part".
But the Longwell "labeling" case is "superficial", for me the
ultimate "win" is that we begin to see how BIBO relates to other
ontologies emerging into the view and begin aligning with those
ontologies directly in their definition, this means that applications
can rely on the intrinsic mappings found in our ontologies (or in
separate mapping ontologies) to determine how to process the data
rather than having to treat each case uniquely. An example of this
would be an application that supported inferred ORE types which can
automatically take submitted BIBO instances and treat them
generically as ORE, and then refine its processing based on sub-
modules that support more specific ontologies (like BIBO). By
subTyping ORE in BIBO, it gives the BIBO community an opportunity to
assert exactly how their types should be related to ORE. Conversely
if other communities begin to do the same, then ORE, much like DCMI,
becomes more universal and established as a guideline for the initial
transfer of composite digital objects between systems.
Likewise, IMO, this would lead us one step down the road of building
up a shared repository of cleanly defined composite digital object
types expressed in OWL/RDFS, of which BIBO would be a subset. Is
this something we can explore in BIBO and ORE together?
Sincerely,
Mark
~~~~~~~~~~~~~
Mark R. Diggory
http://purl.org/net/mdiggory/homepage
Robert Sanderson
Hi Mark,
> <info:hdl/1234.5/67890>
> a bibo:Issue, ore:Aggregation;
> dcterms:hasPart <info:hdl/1234.5/67890/1>;
> ore:aggregates <info:hdl/1234.5/67890/1>;
ore:aggregates is a sub-property of dcterms:hasPart, so isn't it sufficient to just use ore:aggregates to fulfill both?
Rob