RE: [higgins-dev] RDF-OWLDataModelProposal

["Jim Sermersheim" <jimse@xxxxxxxxxx>]

Thanks Paul,

 

http://spwiki.editme.com/files/RDF-OWLDataModelProposal/higgins0.4.3.owl is good. It's giving me a good jumping off point toward understanding.

>>> "Paul Trevithick" <paul@xxxxxxxxxxxxxxxxx> 4/29/06 3:17 PM >>>

Replies inline.

 

Jim wrote:

 

I see the actual OWL definition file is there now. That helps.

>>> "Jim Sermersheim" <jimse@xxxxxxxxxx> 4/29/06 12:32 PM >>>
I've been reading this and (being an RDF/OWL newbie) trying to get a toehold on understanding it. Basically, I (and future consumers/developers) need to get from ground zero to understanding whatever they need to interface with an API/SPI, and the data model it surfaces.

I've rewritten to be clearer the "Proposal" portion of this page http://spwiki.editme.com/RDF-OWLDataModelProposal  

I assume the Higgins Ontology proposed will be expressed as some future XML OWL file?

Yes. I've taken a first cut at it. It is attached to this summary http://spwiki.editme.com/HigginsOntology.

If so, does that mean at the API/SPI level, one would not be working with class names like DigitalSubject, and AttributeStatement, but rather more generic class names like RDFStatement where the RDF Statement might be somehow denote that it's a DigitalSubject versus an AttributeStatement? (I know I'm probably 180 degrees off, but I want to get to the point where I can say what the page is saying and understand what I'm saying).

At the API/SPI level one would be working with lower level RDF objects. These RDF low level objects, through the rdf:type property are linked to classes defined in some ontology. The DigitalSubject and other classes that we've talked so much about are described in the Higgins ontology, but classes that "consenting" Context Providers define in some other shared ontology are interoperable at exactly the same level as the Higgins-defined DigitalSubject, etc. classes.  

I've created this page that shows an example of a single DigitalSubject in RDF here: http://spwiki.editme.com/RDFExampleOne (it is linked to from http://spwiki.editme.com/RDF-OWLDataModelProposal ). I created it a bit quickly so it probably has errors.

Is there more documentation for the eodm libraries? Just browsing the javadoc with wikipedia-level prior knowledge of RDF and OWL turned out to be futile (for me at least). Maybe an explanation of how it would be used in surfacing the data model would help. Mostly I'm having a hard time finding a good jumping in point (now I'm stepping through the demo code).

The documentation for EODM other than the Javadoc is its weakest point. It seems that there is just the JavaDoc. I'll post a question on that newsgroup to see what else there is.

If RDF and OWL DL are the data model, and the Higgins Ontology describes the basic notions of a context, its digital subjects, and their attributes/relationship s, would you say that a context provider also supplies its own ontology to describe its own schema (things like people, phone numbers, etc)? And that this would use the same mechanism (an OWL definition file/stream)?

Absolutely. Actually you'll find that the core Higgins ontology doesn't let you describe almost anything (as demonstrated by ExampleOne above which didn't have an SSN attribute). Context Providers will want to use (known as "importing") other existing ontologies and/or create their own. Obviously we want to encourage folks to reuse existing ontologies in the interest of interoperability.

<aside>
We had a long conversation about whether attributes and relationships should be two things, or the same thing. On this page, they are different things, well, different classes of RDF statements (please correct my horrendous use of terms if needed). Isn't there still an issue where it's unclear how to represent certain types of data (I'm thinking of the "myInterests" example again, where in some cases the values are text, and other times they point to other objects).
</aside>

But much this problem is addressed by OWL's semantic precision. It provides a formal specification for how to describe (or "conceptualize" if you like) the domain. For example, we can in the ontology prescribe what kind of field use-a simple literal value or a link to some other object to describe some concept. This is an improvement because in our "interim" data model proposals it was left to programmer's "convention" which kind of field to use.

You are right that in RDF you have a choice of using either a literal-valued property vs. object-valued (my term) property. And in our interim proposals we had both Attributes and SubjectRelationships. What I like about an explicit ontology is that it provides a way for us to agree on which we'll use in a formal, logically-enforceable way. [Actually there was another layer of ambiguity. In the interim proposal even a single Attribute could be either a literal valued or link/object valued. ]

 

Jim