- From: Karen Coyle <kcoyle@kcoyle.net>
- Date: Mon, 19 Jul 2010 10:28:14 -0700
- To: "Young,Jeff (OR)" <jyoung@oclc.org>
- Cc: public-lld@w3.org
Moving this discussion to public list... so I'm leaving Jeff's comments intact for comprehension. Quoting "Young,Jeff (OR)" <jyoung@oclc.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. 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. > > 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. 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 [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.) 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). > > 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. Are you implying that one shouldn't mix the different FRBR models in a set of statements? > > 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. 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
Received on Monday, 19 July 2010 17:28:49 UTC