Hi Karen, Thanks for your comment, but I am not sure about saying "these (few) non-persons can be foaf:Persons". This may be an issue that cannot be easily fixed in the RDF views though. Is there a way in the system (and database) to say Rijksmuseum Twenthe is not a person or to specifically say it is an organization? When there is, it is easy to change the RDF template accordingly. Of course I can revert foaf:Agent to foaf:Person in my changeset, but in these special cases the RDF will be 'wrong'. My proposal may 'just' be less precise, as foaf:Person is a subclass of foaf:Agent, unless other properties are used that only apply to persons. I don't know of any rule / guideline that says organizations should be added as collaborators instead of creators, or of a way to enter the information this way.
What exactly do you mean by linking? If you have more remarks, I'd like to hear them too. :) Regards, Ben On 31 January 2012 21:20, Karen Coyle <[email protected]> wrote: > I looked again and had remembered wrong: the change was to be between > foaf:Person and foaf:Agent. My reply is still the same: Person is what > is intended, and Person will get us better linking. > > kc > > On 1/30/12 3:55 PM, Ben Companjen wrote: >> Hi all, >> >> I just opened issue 136 on Github, which is a pull request to change >> some things in the RDF templates. These things have already been >> proposed on this list. One change since my last email: URI references >> for Works, Editions and Authors have no trailing "/". >> Please see https://github.com/internetarchive/openlibrary/issues/136 >> for details. >> >> I had already opened issue 130 about changing the HTTP behavior when >> requesting RDF (actually, for any type). In essence it is about using >> 303 redirects instead of 301 or 200 depending on the requested >> mimetype. >> Please see https://github.com/internetarchive/openlibrary/issues/130 >> for details. >> >> Regards, >> >> Ben >> >> On 13 January 2012 23:02, Ben Companjen<[email protected]> wrote: >>> Summary of text below: it does matter for RDF to have consistent URIs >>> (URI with "/" is different from URI without "/"); using URIs with '/' >>> for OL resources fits better in current web server configuration. >>> There is content negotiation, but in July 2010 it was suggested to do >>> it differently (it is still the same) and it is not as 'Accept'ing as >>> I would like. >>> ---------------------------------------------------------------------------------------------------------------------- >>> >>> On 13 January 2012 01:52, raj kumar<[email protected]> wrote: >>>> >>>> On Jan 12, 2012, at 2:18 PM, Karen Coyle wrote: >>>> >>>>> I don't remember at this point what this was about, presumably a >>>>> comment that came in on the list. It MAY have been a reference to the >>>>> URI/Ls in the namespace section of the XML. Since we can't seem to >>>>> find a problem, I'd say we should ignore it. If it matters, it'll come >>>>> up again. >>>> >>>> Ah, I remember... Yes, this is specific to Namespace URIs in RDF. >>>> >>>> Namespace URIs should end in either / or #, so that RDF URI Refs can be >>>> constructed by concatenation of the Namespace URI and a local name without >>>> adding any separators. >>>> >>>> This concat operation is defined here: http://www.w3.org/TR/REC-rdf-syntax/ >>>> >>>> Ben, can you send a pull request with only the change of appending the >>>> trailing '/'? >>>> >>>> Thanks! >>>> -raj >>>> >>> Hi Raj, >>> >>> I'm not sure I understand you here, seeing that all namespace URIs >>> already have a trailing / or #. I was talking about other 'URI >>> references', the URIs used to identify and make statements about >>> resources (Works, Editions and Authors). These are not prefixes, but >>> complete URIs. >>> >>> I looked through the URI RFC<http://www.ietf.org/rfc/rfc2396.txt>, >>> but found no concrete information that >>> <http://openlibrary.org/books/OL18215289M/> and >>> <http://openlibrary.org/books/OL18215289M> should be interpreted as >>> being equivalent (or that they shouldn't). >>> Following Lee's analogy: I don't know if "Ben/" should be interpreted >>> by RDF agents as being equivalent to "Ben". If they should, in theory >>> the discussion about URI references with or without trailing slashes >>> is irrelevant, even though I'd say (if they were references to me) I'd >>> prefer "Ben". :) >>> People >>> on<http://answers.semanticweb.com/questions/13827/is-a-uri-with-trailing-different-from-uri-without> >>> say the identifiers are different. So it is important to be consistent >>> in assigning URIs to resources. RDF applications who use the current >>> OL RDF output will not be able to link the data from the Work RDF >>> (URIs with /) to the data from the Edition RDF (URIs without /). >>> >>> Following the linked data principles, it would be very nice if one can >>> look up the URI of something and get it (e.g. electronic documents) or >>> get more information about it (e.g. information about a person). Since >>> the resources in the Open Library cannot be transferred via HTTP, we >>> only want information about the resources. Redirecting requests for a >>> non-information resource using HTTP 303 to its HTML, RDF, JSON etc >>> representation, based on the Accept header in the request, is common. >>> But you probably know this already. >>> Using Wireshark I could see the redirect process happening. When I ask >>> for<x/> I get a "303 See Other" to<x>, then when I ask for<x> I get >>> "301 Permanently moved" to<x/Title>. This is almost what the Cool >>> URIs document describes, only content negotiation is not used - as I >>> wrote in a previous email, I am always redirected to the HTML >>> representation. >>> >>> At this point in writing this email, I searched the list archives for >>> "http 303" and found a two-message conversation from July 2010 about >>> using 303 redirects to<x.rdf> instead of returning RDF/XML when >>> requesting<x>. Err, content negotiation is already implemented? So I >>> tried "Accept: application/rdf+xml" in a request for<x/> and was >>> redirected to<x> and served RDF/XML. D'oh! >>> >>> That changes what I wanted to say. The mail conversation starts at >>> <http://www.mail-archive.com/[email protected]/msg00198.html>. Ross >>> Singer replies in >>> <http://www.mail-archive.com/[email protected]/msg00199.html> that >>> redirecting to<x.rdf> seems doable. I agree and would like this to be >>> implemented. >>> I would like to add that better handling of the Accept header would be >>> welcome. If I prefer Turtle (q=1) but like RDF/XML almost the same >>> (q=0.9), I'm redirected to the HTML with 301 permanently moved. >>> >>> Finally, getting back to the trailing slashes: although I don't like >>> the aesthetics of a trailing /, with this insights, it may be easier >>> make all URI references (to OL resources) in the RDF end with a "/". >>> >>> Apologies for this long answer - I hope I made myself clear, though. :) >>> >>> Regards, >>> >>> Ben >> _______________________________________________ >> 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]
