Fwiw, we model them as FOAF:Agents at Talis, precisely because there are so many (undocumented) corporate authors in the data set.
-Ross. On Jan 31, 2012, at 8:05 PM, Ben Companjen <[email protected]> wrote: > 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] _______________________________________________ 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]
