On Tue, Jun 8, 2010 at 12:58 PM, Karen Coyle <[email protected]> wrote:
> The reason that I used ol:link instead of foaf:page was George's > desire that we include the link text. (ol:link has the structure > link/url, link/text - http://openlibrary.org/type/link). I like this > use of foaf:page -- can we get a label into it in some way so that we > pick up the link text? You could do something like: <foaf:page> <rdf:Description rdf:about="http://en.wikipedia.org/wiki/Margaret_Mahy";> <rdfs:label>Your Label Here</rdfs:label> </rdf:Description> </foaf:page> I also *think* you can shorten that even more to: <foaf:page rdf:resource="http://en.wikipedia.org/wiki/Margaret_Mahy"; rdfs:label="Your Label Here" /> but I'm not 100% sure. >> <dcterms:identifier>/authors/OL31800A</dcterms:identifier> > > We modified this one to be "http://openlibrary.org/authors...etc";. > Does that mean that you don't need the provenance statement? (Was it > intended to modify identifier?) To be honest, maybe I don't know the 2nd draft RDF example (I *just* joined the list, etc., etc.). I used that particular example from an off-list exchange with Ed Summers, who, I think, thought that the FOAF-inspired changes were live. I attached the ProvenanceStatement mainly because it seems <http://openlibrary.org/authors/OL31800A> is about Margaret Mahy and modified/created/revision/etc. is about the metadata about Margaret Mahy, not Margaret Mahy herself. I just changed rdagr2:identifierForThePerson to dcterms:identifier there because we know she's a person (at this point, thanks to the foaf:Person type) and dcterms is a much more recognized vocabulary than RDA Group 2. -Ross. > > kc > >> <dcterms:provenance >> resource="http://openlibrary.org/authors/OL31800A#meta"; /> >> >> >> </foaf:Person> >> >> <dcterms:ProvenanceStatement >> about="http://openlibrary.org/authors/OL31800A#meta";> >> <dcterms:modified>2010-04-12 12:42:10.448987</dcterms:modified> >> <dcterms:created>2008-04-01T03:28:50.625462</dcterms:created> >> <foaf:page >> resource="http://openlibrary.org/authors/OL31800A/Margaret_Mahy?m=history"; >> /> >> <ov:versionnumber>5</ov:versionnumber> >> </dcterms:ProvenanceStatement> >> </rdf:RDF> >> >> Just as a strawman. >> >> -Ross. >> >> On Tue, Jun 8, 2010 at 11:34 AM, Lee Passey <[email protected]> wrote: >>> On 6/7/2010 12:12 PM, Ed Summers wrote: >>> >>>> On Mon, Jun 7, 2010 at 1:50 PM, Lee Passey<[email protected]> 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 >>> [email protected] >>> http://mail.archive.org/cgi-bin/mailman/listinfo/ol-tech >>> To unsubscribe from this mailing list, send email to >>> [email protected] >>> >> _______________________________________________ >> Ol-tech mailing list >> [email protected] >> http://mail.archive.org/cgi-bin/mailman/listinfo/ol-tech >> To unsubscribe from this mailing list, send email to >> [email protected] >> > > > > -- > Karen Coyle > [email protected] http://kcoyle.net > ph: 1-510-540-7596 > m: 1-510-435-8234 > skype: kcoylenet > > _______________________________________________ > Ol-tech mailing list > [email protected] > http://mail.archive.org/cgi-bin/mailman/listinfo/ol-tech > To unsubscribe from this mailing list, send email to > [email protected] > _______________________________________________ Ol-tech mailing list [email protected] http://mail.archive.org/cgi-bin/mailman/listinfo/ol-tech To unsubscribe from this mailing list, send email to [email protected]
