- From: Young,Jeff (OR) <jyoung@oclc.org>
- Date: Mon, 19 Jul 2010 18:02:59 -0400
- To: "Karen Coyle" <kcoyle@kcoyle.net>
- Cc: <public-lld@w3.org>
- Message-ID: <52E301F960B30049ADEFBCCF1CCAEF59090AA23A@OAEXCH4SERVER.oa.oclc.org>
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 >
Attachments
- image/jpeg attachment: FRBRGroup1Group2.jpg
- image/jpeg attachment: FRBRGroups123.jpg
Received on Monday, 19 July 2010 22:03:40 UTC