W3C home > Mailing lists > Public > public-xg-lld@w3.org > July 2010

RE: Open Library and RDF

From: Young,Jeff (OR) <jyoung@oclc.org>
Date: Fri, 16 Jul 2010 17:23:26 -0400
Message-ID: <52E301F960B30049ADEFBCCF1CCAEF590900A55A@OAEXCH4SERVER.oa.oclc.org>
To: "Karen Coyle" <kcoyle@kcoyle.net>
Cc: <public-xg-lld@w3.org>
Karen,

I hope the redirect behavior can be changed because this single issue is
the difference between Linked Data or not. The correctness and
completeness of the RDF is not a factor in this.

I only object to DC elements when I have to look at them. ;-)

I do hear what you're saying about frbrCore:creator and
FRBRer:isCreatorPersonOf, though. But... FRBRCore, FRBRer, and RDA's
FRBR are not "FRBR" despite the implicit branding. As you point out,
there are vast differences in connecting properties which makes it
mindboggling to believe these are all owl:sameAs "FRBR Work":

- FRBRCore:Work	http://purl.org/vocab/frbr/core#Work 
- FRBRer:Work	http://iflastandards.info/ns/fr/frbr/frbrer/1001 (who's
idea was it to create ontology classes with opaque URIs?)
- RDAFRBR:Work	http://RDVocab.info/uri/schema/FRBRentitiesRDA/Work 

I encourage you to believe that the word "Work" being used here is a
homonym and the discrete URIs are an attempt to point this out. I know
this is counter-intuitive and unpopular given all the owl:sameAs and
multiple rdf:types being bandied about, but give your brain some time to
believe that this is a simpler way to look at the problem.

As assistance, notice that in the FRBR specification "Work" relates to
Group 2 Entities by way of "is responsible for the creation of".
"Expression" relates by way of "is responsible for the realization of".
"Manifestation" relates by way of "is responsible for the Publication,
Distribution, Fabrication, or Manufacture of". "Item" relates by way of
"is the owner or custodian of". A UML class diagram is attached with
references to section numbers.

IMO, we shouldn't fret about salvaging a single coherent FRBR model from
this ontology mess. Each ontology needs to be treated as a separate
self-coherent model. In the case of FRBRCore, it was the intention of
the modeler to use frbrCore:creator as a substitute for the
high-resolution relationships in the FRBR spec. It's their model and
second guessing their modeling decisions isn't productive. LLD-XG
doesn't have time to create one giant brain for everyone to use. If we
want to represent our information with higher-resolution, we can use the
RDA or FRBRer models instead. Representing our information *at runtime*
in these and various other overlapping models is a feature, not a
problem.

I have a solution to offer regarding foaf:Person and frbr:Person, but it
requires your URIs to behave according to Linked Data r303gendocument
<http://www.w3.org/TR/cooluris/#r303gendocument> rather than r303uri
<http://www.w3.org/TR/cooluris/#r303uri>. Let me know if your guys can
support this alternative and I'll offer the suggestion.

Jeff

-----Original Message-----
From: Karen Coyle [mailto:kcoyle@kcoyle.net] 
Sent: Friday, July 16, 2010 2:37 PM
To: Young,Jeff (OR)
Cc: public-xg-lld@w3.org
Subject: RE: Open Library and RDF

Thanks, Jeff. Some of this I will need to think about more, but here  
are a few comments:

Quoting "Young,Jeff (OR)" <jyoung@oclc.org>:


>
> The URI in the rdf:about currently behaves by returning 200 (OK) for
> Accept: application/rdf+xml or else 301 (Moved Permanently). I suggest
> changing this behavior to conform to Linked Data r303uri
> <http://www.w3.org/TR/cooluris/#r303uri>. In other words, change the
RDF
> negotiation behavior to do a 303 to
> http://openlibrary.org/works/OL15168504W.rdf and change the 301 for
HTML
> to a 303. The same would hold true for the author URIs and any others
> like it.

I can pass this on to the OL developers, but the fact of the matter is  
that OL is not terribly focused on RDF, so if such a change takes  
notable effort or interferes with anything else, it will not be done.

>
> You should consider using frbrCore:creator in your frbrCore:Work
rather
> than (or at least in addition to) dcterms:creator:
>
> <frbr:creator rdf:resource="http://openlibrary.org/authors/OC34266A"
/>


First, from what I can tell, "creator" is not a FRBR property,  
although it was included in frbrCore. Unfortunately, frbrCore and  
IFLA's FRBRer have a number of significant differences. I used "Work"  
from FRBRcore because there is no way to indicate Work in a more  
common vocabulary, like DC, and there was a sense that frbrCore is the  
current standard for FRBR properties. I used dcterms:creator because  
my impression is that folks prefer encountering a metadata set that  
they are already familiar with, and every time I use something *other  
than* DC I get asked why I didn't use DC :-). If I used the official  
FRBRer [1] entity, it would be "isCreatorPersonOf" -- and I think you  
can see why I don't want to go there. (Note: the term "Creator" is not  
used in the FRBR document, so the predicate isCreatorPersonOf must be  
coming out of the committee work, but I can't find it documented  
anywhere.)

[1] http://metadataregistry.org/schema/show/id/5.html


>
> Since the range on frbrCore:creator is frbrCore:ResponsibleEntity,
> though, you should consider the confusion created by the fact that
> http://openlibrary.org/authors/OC34266A currently identifies a
> foaf:Person. People don't seem to like my idea of keeping these typed
> identities separate, so I will let them suggest solutions. Hopefully
> they won't twist your arm to switch your XML from <frbr:Work...> to
> <rdf:Description...>


When I was working on the RDF for OL authors there was a strong desire  
on the part of folks advising me on ol-tech to make use of foaf for  
persons. I've done that here, but would like to hear a few more voices  
about this, since I realize that much of this is still very much  
speculative.


>
> I believe you should change rdf:value to rdfs:label in the following
> snippet:
>
>         <dcterms:creator>
>           <rdf:Description
> rdf:about="http://openlibrary.org/authors/OL34266A">
>           <rdf:value>Aimee Bender</rdf:value>
>           </rdf:Description>
>         </dcterms:creator>
>

I copied that from the "editions" template, so I didn't really think  
about it. Label sounds correct to me... Any other opinions?


>
> On the "Author" side, I don't see how rdg2 properties can be justified
> for foaf:Person since their rdfs:domain is
> http://RDVocab.info/uri/schema/FRBRentitiesRDA/Person. If the
assumption
> is that using this property inferentially forces the individual to
> become rdf:type
<http://RDVocab.info/uri/schema/FRBRentitiesRDA/Person>,
> my feeling is that we're encouraging a muddle. This also brings us
back
> to my complaint about conflating rdf:types for an individual.

I'll let you discuss that with Ross S and edsu and Rob S and various  
others who were in the conversation on ol-tech, if they can remember  
it. There was a lot of back and forth about whether RDA Person and  
foaf:Person are the same. (I was in the minority with "no" and wanted  
to use RDA properties exclusively for persons.) If you can advise on  
other options for those properties ( which are:
   variantNameForThePerson
   biographicalInformation
   titleOfThePerson )

... I can substitute them. I could use bio:Biography, but I couldn't  
find elements for the other two, so just grabbed them all from RDA  
Group 2. (We did discuss foaf:nick but that's really not a variant  
name in the bibliographic sense; and foaf:title is "Mr., Ms., Dr."  
etc., again, not what will be in this field in OL.)

I'd post links to the discussion at ol-tech but it's not public and I  
just looked and it doesn't seem to be archived -- so that whole  
discussion is gone. I'll try to get that fixed, at least going forward.

kc

-- 
Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet





FRBRGroup1Group2.jpg
(image/jpeg attachment: FRBRGroup1Group2.jpg)

Received on Friday, 16 July 2010 21:24:53 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 16 July 2010 21:24:54 GMT