RE: Open Library and RDF

Karen Coyle wrote:
> This is exactly how I do think of these different definitions, but you
> and I appear to be in the minority. For example, when I was modeling
> the Open Library Author entity in RDF, I began by using RDA properties
> [1], not FOAF, because I felt that since the author information had
> primarily been derived from library data that rda:Person would be the
> most appropriate. But I got a great deal of push-back on the ol-tech
> list by folks who favored using FOAF, so I conceded (mainly in the
> interest of having the OL RDF accepted by active members of the
> community). I actually consider foaf:Person and rda:Person to be very
> different, as evidenced by the properties they contain and the goals
> and purposes of the metadata (I'm preparing a VERY LONG blog post on
> this topic). However, since FOAF didn't have some of the properties I
> needed, it ended up with some RDA properties being coded as relating
> to foaf:Person. I feel uneasy about that, but the end result doesn't
> seem to have any glaring violations of the meaning of the properties
> themselves.

You and I agree that "Work" is a homonym and that "Person" is in the
same boat.

I don't know if anyone noticed, but VIAF resources went through a
similar flip-flop between foaf and skos. I felt an a-ha moment when we
realized the generous possibility of supporting both at runtime using
Linked Data hash URIs <http://www.w3.org/TR/cooluris/#hashuri>. What the
heck, we added rdaEnt:Person last time around. 

http://viaf.org/viaf/27060791/#foaf:Person 
http://viaf.org/viaf/27060791/#rdaEnt:Person
http://viaf.org/viaf/27060791/#skos:Concept 

In a future release, we can do even better by adding discrete Linked
Data HTML & RDF representations that focus on each model separately.
Libraries shouldn't shy away from incomplete and imperfect conceptual
models. Library school should have taught us all that objective reality
is impossible. :-)

I can sympathize with two arguments against this POV: 1) the information
is being maintained natively in RDF or 2) OL developers are being stingy
with the URI patterns you've been allocated. I can think of solutions
for the former. The fact that the URIs in your RDF aren't currently
Linked Data suggests the latter.

> > 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.
> 
> Yes, the FRBR document shows the creation relationship in its
> diagrams, but you won't find "creator" as an entity or relationship
> property anywhere in the FRBR document. 

Just so everyone is aware, we're talking about modeling now. I prefer
domain modeling to entity-relation modeling, but hopefully it all ends
up as OWL DL ultimately.

IMO, the term "Creator" implies a class name. In contrast, "is the
creator of" or "was created by" implies a property. I promise not to
whine if "creator" is defined as a property, but only if its range is a
class named "Creator". ;-)

> 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 :-).

No argument.

> If I used the official
> FRBRer [2] entity, it would be "isCreatorPersonOf" -- and I think you
> can see why I don't want to go there. (Note: since 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.)

Why do these so-called FRBR ontologies refuse to declare "Group1",
"Group2", and "Group3" as owl:Class? If they did, they could set
subclasses, domains and ranges sensibly and we could all go back to
guessing property names from the FRBR spec. If someone showed me a use
case, I might even buy the need for "isCreatorOf" and "wasCreatedBy"
properties from which the official FRBR relationships could be derived. 

I suggest we pick one of the existing FRBR ontologies (not FRBRer
please), and mock up a recommendation for version 0.0002 that
demonstrates this possibility.

> The lack of a simple "creator" property is in keeping with the FRBR
> decision to define specific properties but not the more general
> classes. This leads to some interesting issues, such as the definition
> of Place as a member of Group 3 (subjects), but no generalized
> property for place that could be used elsewhere (such as place of
> publication).

There seems to be a flaw in your argument. "Subject" is not an alias for
frbr:Group3. Instead, frbr:Group3 is related to frbr:Work by
frbr:isTheSubjectOf and inversely frbr:hasAsSubject. The attached UML
class diagram should help make this clearer (note the section numbers).
This should mean that frbr:Place could reasonably be used as the range
for frbr:placeOfPublication.

> Are you implying that one shouldn't mix the different FRBR models in a
> set of statements?

Let's do it both ways! Invite FOAF, VCard, SKOS, and other ontologies to
the party. As we've discussed, though, I encourage you to avoid
conflating rdf:types under a individual's URI. Here are some
hypothetical URIs that might make this liberalism palatable:

http://example.org/person/1 (303 redirect to...)
http://example.org/person/1/ (200 conneg to ...)
http://example.org/person/1/default.html
http://example.org/person/1/all.rdf (all the following RDF triples
thrown together)
http://example.org/person/1/foaf.rdf
http://example.org/person/1/skos.rdf
http://example.org/person/1/frbr.rdf
http://example.org/person/1/rda.rdf
http://example.org/person/1/frbrer.rdf

People might also appreciate it if you added an HTML representation for
each of the RDF ontological breakdowns.

> > 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.
> 
> Well, the "guys" aren't "my guys" so all I can do is suggest. It would
> be helpful if you would articulate your idea on the ol-tech list,
> since that might provide a motivation for taking the time to make the
> change.

My contributions should remain in the context of LLD XG. Now that this
discussion has been moved to public-lld, though, I assume that anyone
can follow and share.

Here are some examples using Linked Data hash URIs and r303gendocument:

http://example.org/person/1 (303 redirect to...)
http://example.org/person/1/ (200 conneg to...)
http://example.org/person/1/#foaf:Person
http://example.org/person/1/#frbr:Person
http://example.org/person/1/default.html
http://example.org/person/1/about.rdf

These URIs can be used to keep the foaf and frbr models separate while
allowing them to share Web documents that are focused on a
domain-specific common sense model.

Jeff

> 
> kc
> 
> [1] http://metadataregistry.org/rdabrowse.htm
> [2] http://metadataregistry.org/schemaprop/list/schema_id/5.html
> 
> 
> 
> >
> > 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
> >
> >
> >
> 
> 
> 
> --
> Karen Coyle
> kcoyle@kcoyle.net http://kcoyle.net
> ph: 1-510-540-7596
> m: 1-510-435-8234
> skype: kcoylenet
>