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

Reply via email to