For most purposes, all that is really wanted is a set of agreed-on records and fields - a record being a bundle of fields: some required, some multivalued and so on. Yes, you might want to lay OWL reasoning rules over these, but what is really needed in the first instance is "country code" and "habitat type".
I occurs to me that LDAP is an ideal model of these types of requirements.
* An LDAP directory data schema declares a number of attributes. Each attribute has a data type and may or may not be multi-valued. * Data types include strings, numbers, strings fitting a formatting pattern, addresses and phone numbers, and of course "pointer to LDAP object of type X". * The directory schema also declares a number of record types. Each record type is a bundle of attributes, each of which might be required or optional. * Records may multiply inherit their attribute bundles from other records, in which case the attribute bundle is simply the union. * Crucially, an attribute named "phone number" always means the same thing in any record in which it appears. The name of the attribute belongs to the attribute, not the record. * Finally, an object has attributes with values. One of the attributes is "record type" (which is multivalued) and the LDAP store enforces data integrity.
It's obvious, I think, how well this maps to the RDF/OWL/triples way of looking at the world. I'm pretty sure LDAP servers do things like data federation and distributed data. LDAP servers are usually oriented towards fast lookup and retrieval. Even if the data objects are not stored in an LDAP dart store, something like open ldap might serve as a worthwhile platform for hosting vocabularies. URIs for vocabulary terms might be made available as equivalent ldap:// and http:// forms. Implement a JENA graph that queries an LDAP data source, use it as a JOSEKI back-end, and you are done.
From the point of view of our immediate problem - somehow making it possible for people to collaborate on authoring RDF vocabularies - there are existing tools for managing and editing schemas in an LDAP store. These types of tools understand users and user groups, access restrictions, the whole thorny issue of providing a secure public interface.
There are a variety of things that don't "fit" naturally into an LDAP schema, of course - reasoning rules especially. But those things can be dispensed with for purposes of hosting vocabularies. It might very well be that because the LDAP model is so similar to what is needed (attributes and types), that using these tools will be natural for the job at hand.
On 20/09/2011, at 6:14 PM, Dag Endresen (GBIF) wrote:
Dear Joel and Steve,
I am very interested to take part in the RDF/OWL task group kickoff meeting at TDWG 2011 in New Orleans!
I have recently started as the new Knowledge Systems Engineer at the GBIF secretariat in Copenhagen. I plan to focus in the first phase on providing tools for collecting terminology and the definition of concepts in use in the biodiversity informatics domain. This will hopefully lead to the mapping of terms in these vocabularies and the development of ontologies to describe the relation and different use of these terms in different parts of our community.
GBIF provides the http://vocabularies.gbif.org as a tool to collect and discuss vocabularies. This tool was developed at GBIF and the Natural History Museum in London using the Scratchpads and Drupal. I am exploring other supplementary tools such as the Web Protege for collaborative development of domain vocabularies and ontologies. I am also exploring solutions such as the NCBO BioPortal for publishing agreed-upon versions of our vocabularies and ontologies. I would much appreciate feedback and discussions to identify the requirements, priorities and solutions for this task.
My personal background is from the community of plant genetic resources for agriculture where I have taken an active part in the genebank domain modeling during the last 10 years.
With best regards Dag Endresen
On Mon, 19 Sep 2011 15:46:44 -0400 (EDT), joel sachs wrote:
Greetings everyone,
After some back and forth amongst Steve Baskauf, myself, Greg Whitbread, and the executive, we've decided to move forward with an RDF/OWL task group, convened under the TAG. Our task will be to deliver a document comprising i. use cases and competency questions; ii. well documented examples of addressing those use cases via rdf and sparql; and iii. discussion of advantages and disadvantages of the approaches illustrated by the examples.
Our draft charter is at http://code.google.com/p/tdwg-rdf/wiki/CharterOfTG and we welcome comments, suggestions, and better ideas. One area where we're still open is the question of whether or not our deliverable should be an official Best Current Practice document [1]. The charter reflects our current feeling that it should not. After we deliver our "book of use cases and examples", options would include being re-chartered by the TAG to produce a best practices document, spinning off as a "Semantic Web Interest Group", or disbanding (either in triumph or despair).
When we were planning to convene as an Interest Group, several of you accepted our invitation to serve as core members, and we hope that convening as a Task Group does not change your willingness to do so. If you would like to be a core member of the group, and we haven't yet contacted you, there's a good chance that we will. But don't wait! Feel free to volunteer for core membership. (And recall that you don't have to be a "core member to" contribute.)
In regards timeline, I'd like to incorporate any feedback we receive, and submit the charter to the executive at the end of this week, in hopes of being chartered by New Orleans.
Many thanks! Joel.
tdwg-tag mailing list tdwg-tag@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tag
tdwg-tag mailing list tdwg-tag@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tag
If you have received this transmission in error please notify us immediately by return e-mail and delete all copies. If this e-mail or any attachments have been sent to you in error, that error does not constitute waiver of any confidentiality, privilege or copyright in respect of information in the e-mail or attachments.
Please consider the environment before printing this email.