Extending ORE Classes

[Mark Diggory]

As devils advocate, I wanted to know opinions on actually extending
the ORE classes directly, as in

> <rdfs:Class rdf:about="http://www.example.com/terms/MyContainer">
> <rdfs:label>My Container</rdfs:label>
> <rdfs:comment>My refined Aggregation of extra special
> aggregates.</rdfs:comment>
> <rdfs:subClassOf rdf:resource="http://www.openarchives.org/ore/
> terms/Aggregation" />
> </rdfs:Class>

> <rdf:Property rdf:about="http://www.example.com/terms/contains">
> <rdfs:label>Contains</rdfs:label>
> <rdfs:comment>A Subclass of Aggregation explicitly for
> Containership.</rdfs:comment>
> <rdfs:subPropertyOf
> rdf:resource="http://www.openarchives.org/
> ore/terms/aggregates"/>
> <rdfs:domain rdf:resource="http://www.example.com/terms/
> MyContainer" />
> <rdfs:range rdf:resource="http://www.openarchives.org/ore/terms/
> AggregatedResource" />
> </rdf:Property>

I won't say yet why I'm exploring this. I just want to see opinion on
the subject.

Cheers,
Mark

~~~~~~~~~~~~~
Mark R. Diggory - DSpace Developer and Systems Manager
MIT Libraries, Systems and Technology Services
Massachusetts Institute of Technology
Home Page: http://purl.org/net/mdiggory/homepage

[Jim Downing]

Hi Mark,

2008/6/19 Mark Diggory <mdig...@mit.edu>:

As devils advocate, I wanted to know opinions on actually extending
the ORE classes directly, as in

...

I won't say yet why I'm exploring this. I just want to see opinion on
the subject.

The spec favours leaving the predicates unextended so that queries can be consistent, so I don't see a problem extending the classes. What are the other alternatives, asides from inference?

jim

[Sebastian Kruk]

Hi Mark,

I would add that you would need to ensure that your extended ontology
is accessible according to Linking Open Data guidelines.
Which means you would need to ensure that the definition of the
classes and properties appear at http://www.example.com/terms/....

Than it is a matter of ensuring that the inferencing is done correctly
by the clients. I think (but I would need to check with my colleagues)
that semantic indexing services like Sindice could help at this point.

However, I agree with Jim - if you really need to extend the ontology
- I hope there is more to it than just giving your own names; I mean -
your classes and properties will have some specific meaning.

Cheers,

Sebastian

-- sebasti...@gmail.com
-- GG: 335067,
-- Jabber: sebasti...@gmail.com
-- Skype: sebastiankruk
-- WWW: http://www.sebastiankruk.com/

[Robert Sanderson]

This may sound like a Me Too, but I agree with Sebastian and Jim.  If you go too far away from the ORE objects and relationships, then while you may be doing RDF, you're not really doing ORE.
In particular, it would be very hard to detect that the graph even is somehow ORE unless there are predicates like ore:aggregates, and ore:describes, and classes like ore:ResourceMap and ore:Aggregation.

Of course without more information as to why you might want to create derivative classes, it's hard to say anything more.  I'm not sure what you'd gain by doing it over simply asserting additional rdf:type triples, as per the current examples.

(eg X is an Aggregation, and X is a Journal Article)

Rob

[Mark Diggory]

I did want to clarify why I bring up this topic.  I currently have three significant Ontologies to attempt to bring together under one exposed mechanism (possibly for our DSpace 2.0 development roadmap this fall).

Explicitly we have 

1.) ORE

2.) the FRBR Ontology (http://vocab.org/frbr/core)

3.) SWAP Ontology (http://www.ukoln.ac.uk/repositories/digirep/index/Scholarly_Works_Application_Profile). Which seriously needs a RDFS representation to be effective in this domain.

Likewise, As an initial Building block, I have the a very messy, but rapidly improving DSpace Data Model RDFS I've published here

http://purl.org/dspace/model/

My point is that to take true advantage of any of these Ontologies, it would appear that there is a cross-section between which they need to be appropriately mapped so that when requested, the application will be able to provide the most appropriate representation to the client... BUT...

If this representation can be made more explicitly encoded in the above Ontologies (i.e. subclass of, sub-property of) then it stands to reason that those relations will then be explicit in the ontologies themselves, and that without a need to produce separate third-party mappings across each of these domains, that a generic transformation can occur between FRBR/SWAP/ORE and my DSpace Object Model.  Since ORE is for the most part, just a scaffold for expressing a structural model, it seems appropriate that these above Ontologies would benefit from extending their container-ship off of ORE and saving us the labor of having to complete those mappings repeatedly ourselves in our applications.  (I.E. a FRBR/SWAP Work/Expression/Manifestation is a subclass of ore:Aggregation, and likewise a DSpace Community/Collection/Item/Bundle may be subclasses of ore:Aggregation.

The point being that by agreeing on a intrinsic approach to mapping to ORE, our various Ontologies can be slightly more polymorphic and an intrinsic mapping to the ORE Abstract Model (much like a mapping to the DCMI abstract Model for some of the application profiles I outline above) might establish at least a common mapping for converting from one representation to the other.

-Mark