I think you two may be disagreeing about something that doesn't need to be disagreed about. Let's see if we can all agree on these two principles:
1. It is important to represent the entire internal OL data model in representations delivered by the API. 2. It is desirable to use common standardized "controlled vocabularies" to represent parts of this data, where possible. By "controlled vocabularies" I mean both RDF vocabularies and XML schema, in this case. Keep in mind that in _both_ (non-RDF-based) XML _and_ RDF it is possible to mix-and-match "controlled vocabularies". Via namespaces in XML, via vocabularies in RDF. So this isn't an "XML vs. RDF" thing. (On top of that, in many cases a 'controlled vocabulary' can exist both as an RDF vocabulary AND an XML schema. FOAF does, I think? And of course RDF can be expressed as XML, which I believe is the plan here?). In either case, there is a bit of a balancing act. How well does internal OL data map to a 'standardized' controlled vocabulary? If it maps perfectly, it's a no-brainer, use the standardized vocabulary (whether that's an RDF vocab or an XML schema). If it doesn't map perfectly, then you have to balance the benefit (how "standardized"/popular IS this third party controlled vocabulary really?) with the cost (how much more difficult and ugly is it going to be to expose complete OL data _and_ use the standardized controlled vocabulary?). It's a judgement call. With FOAF, it seems to me that it's reasonable to think that the cost-benefit is good, both because it seems to express certain OL data concepts pretty well, and because it's a reasonably well-accepted thing. Either way, I agree with Lee, and I suspect Ed does too, that as much of OL internal data model as possible should be provided by machine-readable representation(s). Using FOAF does not prevent you from doing that, so long as you don't _only_ use FOAF. Which I don't think anyone is suggesting. You can mix and match RDF vocabularies, you can do the same thing with non-RDF-modelled data in XML. "Because it's not in FOAF" is indeed not a good explanation for why some data is not available via API machine readable representation. Jonahtan ________________________________________ From: ol-tech-boun...@archive.org [ol-tech-boun...@archive.org] On Behalf Of Lee Passey [...@novomail.net] Sent: Tuesday, June 08, 2010 11:34 AM To: ol-tech@archive.org Subject: Re: [ol-tech] a few notes on rdf views On 6/7/2010 12:12 PM, Ed Summers wrote: > On Mon, Jun 7, 2010 at 1:50 PM, Lee Passey<l...@novomail.net> wrote: >> So before any questions about how best to represent a person in RDF can >> be addressed, you should try to find out who will be consuming the data, >> and what their expectations are. > > I think this is an important point, and is largely why I'm in favor of > leveraging existing vocabularies for people (foaf) in the rdf views, > so that ol authors fit into the existing ecosystem of rdf data about > people, some of whom happen to have written books. Can you give us a better description of this "ecosystem?" What existing, or in-development, applications would consume OL data? What would they use it for? It seems to me that the proposed preference for FOAF, with its accompanying incompleteness, is mostly speculative at this point; that is, /if/ OL provided data using the FOAF vocabulary, and /if/ future applications had a use for OL data /then/ something useful could happen. But what if the predicates never materialize? Thus the question, "what applications currently exist or are likely to exist imminently, that desire to consume OL data, and what are their requirements?" Until this gating question is answered, at least provisionally, any attempts to decide on an RDF vocabulary is premature. On the other hand, if there are no current or imminent applications, then it seems to me the answers to the vocabulary selection question are: 1. pick anything you want, because no one will be using it anyway, and 2. why are you wasting developer time on an effort for which there is no demand? On the third hand, XSLT is a powerful enough scripting language that transformations from any arbitrary XML vocabulary, even non-RDF vocabularies, to any other XML vocabulary, are trivial. Simply pick or invent an XML vocabulary that encodes all of the data stored in the OL record sets. When someone comes to you and asks for a different transfer encoding, simply hand him/her the XSLT script that transforms the OL encoding to whatever the target encoding needs to be (or if demand is great enough, run the XSLT on the server side via a Java servlet); of course, you won't know what the target encoding needs to be until someone comes to you and asks for it. The key here is that the XML encoding /must/ carry /all/ of the data currently stored in the OL record sets, which is something that the current RDF API does not do. In my opinion, completeness trumps conformance to any particular vocabulary. _______________________________________________ Ol-tech mailing list Ol-tech@archive.org http://mail.archive.org/cgi-bin/mailman/listinfo/ol-tech To unsubscribe from this mailing list, send email to ol-tech-unsubscr...@archive.org _______________________________________________ Ol-tech mailing list Ol-tech@archive.org http://mail.archive.org/cgi-bin/mailman/listinfo/ol-tech To unsubscribe from this mailing list, send email to ol-tech-unsubscr...@archive.org
