- From: Niklas Lindström <lindstream@gmail.com>
- Date: Wed, 3 Jul 2013 23:12:20 +0200
- To: Karen Coyle <kcoyle@kcoyle.net>
- Cc: "public-schemabibex@w3.org" <public-schemabibex@w3.org>
- Message-ID: <CADjV5jcc2JDWzyhc39JfyDmma9-Wv1p=ydyWdPNQ00D0KN+r4A@mail.gmail.com>
Karen, On Wed, Jul 3, 2013 at 10:47 PM, Karen Coyle <kcoyle@kcoyle.net> wrote: > Once again, good idea, but a different meaning. That's exactly my point. I elaborated on that, suggesting that the *combination* of 'isFormatOf' and 'isVersionOf' may cover what 'commonEndeavor' is after. And that I value this distinction (as defined in DC), because its meaning has been proven useful. > I suspect that "isVersionOf" is close to "isInstanceOf" - it has an > implied vertical relationship, where one resource is "it" and the other is > "version of it". In the "commonEndeavor" case, the endeavor itself is > undefined and outside of the relationship being coded. It's quite a bit > less precise, but the key thing is that it is explicitly a peer-to-peer > relationship. As I said, 'isVersionOf' implies precedence, but only a temporal precedence. It can most definitely relate two "manifestations", such as a legal document and a revision of it. It links to another "version, edition, or adaptation", with "substantive changes in content rather than differences in format". > It is so broad that the only inferencing that might be possible is: > if ResA -> commonEndeavor -> ResB > then ResB -> commonEndeavor -> ResA > and > if ResB -> commonEndeavor -> ResC > then ResA -> commonEndeavor -> ResC > > However, in the latter case, anthologies and other multiple Work resources > may negate that. In fact, I prefer making few if any inferences, thus > leaving this in the same category as ref:similarTo, which can be exploited > for things like "Would you also like to see similar items?" but nothing > more precise. > I understand that. I also brought up 'dcterms:relation' (defined as "A related resource", and being the explicit superproperty of 'dcterms:isFormatOf' and 'dcterms:isVersionOf'), which may fit this use case (albeit being even more general). Just like 'commonEndeavor', it is (reasonably) a symmetric and transitive property. Cheers, Niklas > kc > > > > On 7/3/13 11:47 AM, Niklas Lindström wrote: > >> Hi Karen, >> >> Thanks! Yes, that is an important point – 'commonEndeavor' is less >> specific than 'isFormatOf'. However, Dublin Core also defines >> 'dcterms:isVersionOf' [1], as: >> >> A related resource of which the described resource is a version, >> edition, or adaptation. >> >> Changes in version imply substantive changes in content rather than >> differences in format. >> >> Combined, I believe they can cover the gamut of use cases. And the good >> thing with that is that this specificity, which is already well-known >> thanks to the widespread use of DC, makes the resulting descriptions >> more actionable, in my opinion. Thinking of queries, and user interfaces >> thereof, it seems to me that it is rather common to differ between >> either various versions of a work, or various formats (representations) >> thereof. (Of course, provided that the statement about what constitutes >> a version or format is made by an informed party with knowledge about >> the work in question.) >> >> So to cover (more of) what we're after, the 'isFormatOf' suggestion >> should be combined with 'isVersionOf', to enable differentiation on >> these aspects. >> >> As for precedence, 'isVersionOf' does imply that. Not so much with >> 'isFormatOf', although it might be more apt for relating something >> specific to something general. It is not required though, as long as the >> substantial content is the same. I don't know enough about use cases >> where a generic relation between things that are based on a common >> endeavor is suitable, so I cannot readily speak for the aptness of these >> properties there. Relating a book and a movie in general, without >> stating that one is derived from the other (which I'd gather is the >> common case), seems to imply that they are about the same topic. For >> relating to what they are about, we have 'schema:about' (with say a link >> to a DBPedia resource for the topic at hand). For stating that a movie >> is an adaptation of a book, I believe 'dcterms:source' [2] is >> applicable. (More so than 'isVersionOf' since the change is substantive >> in format as well. In any case, I do not think they represent the same >> creative work, and therefore do not constitute alternate formats of each >> other.) >> >> As for relating e.g. a movie and a book together without specifying that >> relation further, 'dcterms:relation' [3] might be fine, since that is >> very general indeed. Both 'dcterms:isFormatOf' and 'dcterms:isVersionOf' >> are subproperties of that one. If you want to group a bunch of related >> works together, that would apply. Another interesting DC term is >> 'dcterms:references' [4]. >> >> (Regarding 'dcterms:source', if that were to be incorporated into >> schema.org <http://schema.org>, it'd have to be renamed, since that >> >> one's already defined in [5] – as "The anatomical or organ system that >> the artery originates from", of all things.. I'd suggest 'isBasedOn', as >> a corresponding ObjectProperty to the already defined >> 'schema:isBasedOnUrl', which is rather poor..) >> >> As mentioned, I think we should seriously consider all of these, since >> Dublin Core has been successfully deployed for many years. And even if >> we end up with modified versions of them, and/or something in between >> (such as 'commonEndeavor'), I think it is very valuable to be able to >> state, as succinctly as possible, how our resulting proposals relate to >> the DC terms. (And by succinctly, I personally mean using RDFS/OWL.) >> >> On that topic, a related, interesting read is the "Dublin Core to PROV >> Mapping" WG Note [6], which explains in-depth correlations between the >> W3C PROV (provenance) vocabulary and the above mentioned DC terms (among >> others). >> >> Finally, I believe that many participants in the "DCMI Schema.org >> Alignment Task Group" [7] are also members of this group, correct? From >> my point of view, we should be doing the same thing, more or less. If >> this other group is still active, I wonder if we could merge our efforts? >> >> Cheers, >> Niklas >> >> [1]: http://purl.org/dc/terms/**isVersionOf<http://purl.org/dc/terms/isVersionOf> >> [2]: http://purl.org/dc/terms/**source <http://purl.org/dc/terms/source> >> [3]: http://purl.org/dc/terms/**relation<http://purl.org/dc/terms/relation> >> [4]: http://purl.org/dc/terms/**references<http://purl.org/dc/terms/references> >> [5]: http://schema.org/Artery >> [6]: http://www.w3.org/TR/prov-dc/ >> [7]: http://wiki.dublincore.org/**index.php/Schema.org_Alignment<http://wiki.dublincore.org/index.php/Schema.org_Alignment> >> >> >> >> On Wed, Jul 3, 2013 at 12:36 AM, Karen Coyle <kcoyle@kcoyle.net >> <mailto:kcoyle@kcoyle.net>> wrote: >> >> Niklas, while your proposal is very well thought-out, let me clarify >> that "commonEndeavor" is not the same as dc:isFormatOf. >> commonEndeavor can be between things of the same format, such as the >> same text published at different times (e.g. the many >> re-publications of various classics). Another possibility is to use >> it to link translations to each other (even though none are the >> original). It can ALSO refer to the same story or theme in different >> formats. In other words, commonEndeavor is broader than >> dc:isFormatOf, and can be used for anything where you think the >> intellectual font was the same. >> >> What I like about commonEndeavor is that it does not assume a >> precedence. I realize that in fact saying that MovieA dc:isFormatOf >> BookB does not state that the book can first, but I think it is easy >> to interpret it that way. commonEndeavor is designed to be a >> horizontal relationship that says, in effect: the two of these have >> significant intellectual content in common. >> >> None of this is to say that we should NOT also consider >> dc:isFormatOf if we consider it useful. It's just that it has a >> different meaning to commonEndeavor. >> >> I agree with your analysis that it is best to avoid the necessity of >> an abstract class. I think that it is better to create relationships >> between things that people generally recognize as "things" than to >> try to decide what is abstract and what is concrete. Both >> commonEndeavor and dc:isFormatOf avoid the need for an abstract class. >> >> kc >> >> >> On 7/2/13 2:54 PM, Niklas Lindström wrote: >> >> Hi all, >> >> I'm sure we can find a way of reconciling our current, varied, >> positions >> regarding instanceOf and commonEndeavour. The differences seem >> to relate >> to various MARC and FRBR experiences, or at least reactions to the >> different rigors, or indeed lack thereof, that have come out of >> these. I >> also think we can avoid inventing too much new thinking on these >> matters, since there is lots to reuse from the domain of resource >> descriptions. >> >> Model-wise, I think many of us (perhaps all) agree that the >> restrictive >> abstraction principles of WEMI separation, and the simpler but >> still >> divided Work/Instance counterpart evolving in BIBFRAME, are too >> rigid >> for schema.org <http://schema.org> <http://schema.org/> (and >> >> possibly for cataloguing in >> >> general). However, many also see a great benefit in relating to >> common >> generalized notions of works from their specific forms, at least >> when a >> work is available in a multitude of formats. This notion is very >> useful >> both for facilitating cataloguers' workflow and for building >> services >> upon the data. As I mentioned a while ago [1], this is not so >> much about >> *abstraction* but *generalization* (also elaborated on in [2]). >> So let >> us neither prescribe nor prohibit. >> >> We should carefully consider what has been done in the wild, and >> especially practices stemming from, but not limited to, >> libraries. A >> good example of this is the Dublin Core Terms vocabulary [3], >> which has >> been heavily used for many years now, in lots of linked data >> scenarios. >> It is used in and recommended by many W3C specs (e..g SKOS, VoID >> and >> PROV) and is the base for many community vocabularies, such as >> BIBO. Its >> terms are used in lots, if not most, of the datasets in the >> Linked Open >> Data cloud. If there is any stable core in the plethora of >> bibliographic >> vocabularies, I'd say DC terms is it. And it gets by with >> (probably >> because of) quite a minimal specification (just like schema.org >> <http://schema.org> >> <http://schema.org>). >> >> >> I therefore suggest that we consider 'isFormatOf', explicitly >> based on >> 'dcterms:isFormatOf' [4], as a replacement for, or indeed a >> unification >> of, both the 'instanceOf' and 'commonEndeavour' proposals (and >> possibly >> content/carrier). >> >> Dublin Core defines 'isFormatOf' as: >> >> A related resource that is substantially the same as the >> described >> resource, but in another format. >> >> The things being in specific formats are representations, >> manifestations >> or instances. This property can be used both to relate between >> different >> formats (similar to 'commonEndeavour'), and for linking from a >> specific >> format to a generalized notion, such as an expression or work >> (similar >> to 'instanceOf'). The latter use of 'dcterms:isFormatOf' is quite >> common, using the pattern of linking different representations >> (e.g. in >> HTML or PDF for digital representations, or hardcover or >> paperback for >> physical books) to a general resource which they represent. >> Examples of >> this can be seen e.g. in legislation.gov.uk >> <http://legislation.gov.uk> <http://legislation.gov.uk> >> >> >> [5]. (For specifying the kind of format, schema:bookFormat is >> applicable, as is the more general dcterms:format property). >> >> As for the actual name, we could include 'isFormatOf' as is (and >> possibly its inverse, 'hasFormat'). Or we could relabel it >> somehow. The >> name is important, but only instrumentally so. The most >> important thing >> is to find a common meaning, and to do so we should base it on >> existing >> usage. >> >> (I'd also like to note that the solid proposal we do have on the >> table, >> 'hasPart'/'isPartOf', correlates very much to the existing >> Dublin Core >> properties of the same name (as has also been discussed). I do >> think we >> should mention that in the wiki page. I can address that unless >> anyone >> objects, following the pattern of the Datasets proposal [6]. In >> fact, if >> we can find a common ground in (at least parts of) the Dublin Core >> terms, we can also continue to import some other terms, such as >> 'isVersionOf', 'references' and 'source', if needed.) >> >> Regarding the necessity of an abstract class, I don't think it is >> a >> strict requirement for this pattern. The notion of variable >> generalization is already present in the fact that we don't >> describe one >> single item/copy even at the specific format level. That is, even >> a >> "manifestation" has the extent of a group, and thus we can >> relate that >> to a broader group representing the union of manifestations >> (i.e. the >> "expression" level), without needing to separate the classes. This >> notion seems very much present in the Product type as well, >> where it's >> up to the user of the vocabulary to determine the level of >> specificity >> for the subject described. Granted, there are additional >> specializations >> in IndividualProduct and ProductModel, but both derive from the >> general >> Product class. Thus, there is no principal divide. (In fact, if >> a case >> was made that there is, that would seem to be an argument for the >> applicability of WEMI in schema.org..) >> >> (The choice of which other properties (e.g. author, illustrator, >> subjects, publisher) should be specific to a certain >> format/representation is then up to the data publisher (cataloguer >> and/or library system) to determine. You might do selective >> copying of >> properties, or link to a prototypical uniform work. >> Consumers/services >> wishing to index data for each specific format in their entirety >> can >> also copy in the general properties from the general form. >> Others may >> choose to traverse graphs, or even create unions of related >> formats >> altogether into a mixed form described with all properties.) >> >> Cheers, >> Niklas >> >> [1]: >> http://lists.w3.org/Archives/_**_Public/public-schemabibex/__** >> 2013Mar/0077.html<http://lists.w3.org/Archives/__Public/public-schemabibex/__2013Mar/0077.html> >> <http://lists.w3.org/Archives/**Public/public-schemabibex/** >> 2013Mar/0077.html<http://lists.w3.org/Archives/Public/public-schemabibex/2013Mar/0077.html> >> > >> [2]: >> http://grammar.ccc.commnet.__**edu/grammar/composition/__** >> abstract.htm >> <http://grammar.ccc.commnet.**edu/grammar/composition/** >> abstract.htm<http://grammar.ccc.commnet.edu/grammar/composition/abstract.htm> >> > >> [3]: http://purl.org/dc/terms/ >> [4]: http://purl.org/dc/terms/__**isFormatOf<http://purl.org/dc/terms/__isFormatOf> >> <http://purl.org/dc/terms/**isFormatOf<http://purl.org/dc/terms/isFormatOf> >> > >> [5]: http://www.legislation.gov.uk/**__developer/formats/rdf<http://www.legislation.gov.uk/__developer/formats/rdf> >> <http://www.legislation.gov.**uk/developer/formats/rdf<http://www.legislation.gov.uk/developer/formats/rdf> >> > >> [6]: http://www.w3.org/wiki/__**WebSchemas/Datasets<http://www.w3.org/wiki/__WebSchemas/Datasets> >> <http://www.w3.org/wiki/**WebSchemas/Datasets<http://www.w3.org/wiki/WebSchemas/Datasets> >> > >> >> -- >> Niklas Lindström >> National Library of Sweden (KB) >> >> >> -- >> Karen Coyle >> kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net> http://kcoyle.net >> ph: 1-510-540-7596 <tel:1-510-540-7596> >> m: 1-510-435-8234 <tel: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 Wednesday, 3 July 2013 21:13:18 UTC