- From: Niklas Lindström <lindstream@gmail.com>
- Date: Mon, 8 Jul 2013 14:28:18 +0200
- To: Karen Coyle <kcoyle@kcoyle.net>
- Cc: "public-schemabibex@w3.org" <public-schemabibex@w3.org>
- Message-ID: <CADjV5jcryPihmL+wWPkrXhe9vDwegXhmzj77tdqdDkQX9XMupA@mail.gmail.com>
Hi Karen,
On Thu, Jul 4, 2013 at 6:03 AM, Karen Coyle <kcoyle@kcoyle.net> wrote:
>
>
> On 7/3/13 2:12 PM, Niklas Lindström wrote:
>
>> Karen,
>>
>> On Wed, Jul 3, 2013 at 10:47 PM, Karen Coyle <kcoyle@kcoyle.net
>> <mailto: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.
>>
>
> Niklas, are you implying that one would use two triples to describe a
> single relationship? In a world of triples, I'm just not sure what a
> "combination of" two properties might mean.
Ah, no. I only meant combination of usage. For any given case, you'd use
one of them. For many given cases, either 'isFormatOf' or 'isVersionOf' is
applicable (in others, 'dcterms:source' is). And if so, their respective
usage also provides more meaning to the relationship, which makes is
possible to answer more detailed questions, and to present this distinction
coherently in user interfaces. (For instance, many users may not be very
interested in the differences in format, but differences in versions can be
very important.)
> 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".
>>
>
> I don't know of anything in DC's "isVersionOf" that implies a temporal
> precedence, although that may be a common usage. For example, United
> Nations documents are published simultaneously in multiple languages, and
> they are definitely versions of each other, but there is no temporal
> precedence. It does imply a change of some sort (like being in different
> languages), and commonEndeavor does not require that there be a change in
> the resource content. It can be two publications of the same text.
>
Yes. I should have said in general. A text can be simultaneously translated
into several languages, very much being versions of each other. (In other
contexts, such texts are published as a multilingual unit.) The point
however, was that this does not necessitate a relationship from something
specific to something general, but, as in the translation example, between
two things conceived of at the same level of specificity.
>
> I would be open to a broader interpretation of dc:isVersionOf except for
> the note on that property that reads:
>
> "Changes in version imply substantive changes in content rather
> than differences in format."
>
> That "substantive changes in content" is the key point.
Indeed. It is the key to distinguish between 'isFormatOf' and 'isVersionOf'
in DC, as opposed to "is format of" and "is version of" in daily speech,
where the distinction can be quite ambiguous. I agree that "substantive"
appears somewhat demanding. But that inherently depends on the nature of
the work. I'd argue that even a bunch of spelling corrections, a change in
foreword, or for certain works even a different book cover could constitute
such a change. Though importantly, the less substantive the change is, the
less meaningful it is to describe the result as a separate entity.
There are also guidelines, e.g. at [1] (though dated), which further
exemplifies applicability:
Use only in cases where the relationship expressed is at the content
level. Relationships need not be close for the relationship to be relevant.
"West Side Story" is a version of "Romeo and Juliet" and that may be
important enough in the context of the resource description to be expressed
using isVersionOf. The Broadway Show and the movie of "West Side Story"
also relate at a similar level, but the video and DVD of the movie are more
usefully expressed at the level of format, the content being essentially
the same.
>
> .
>> 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.
>>
>
>
> Yes, dc:relation is very much along the same lines, although it doesn't
> specify that there is common intellectual content. It is defined as "A
> related resource." I do wish that the definition were a bit clearer, or
> that there were examples. Would it include two different monographs in a
> monographic series? Two books by the same author (but totally different in
> content)? If it doesn't imply a commonality of content then it seems to be
> not terribly useful.
>
It is very general, and I agree that it is not very useful by itself. Other
than perhaps to link together things which share something *else* in
common, where that "else" is unknown. It is much more valuable to describe
that specific commonality. In terms of how these properties relate, it
certainly seems that 'commonEndeavor' is more specific than
'dcterms:relation', and that 'dcterms:isFormatOf', 'dcterms:isVersionOf'
and 'dcterms:source' are all more specific than 'commonEndeavor'.
(Note that in Dublin Core, 'relation' is the superproperty of: source,
isVersionOf/hasVersion, isReplacedBy/replaces, isRequiredBy/requires,
isPartOf/hasPart, isReferencedBy/references, isFormatOf/hasFormat and
conformsTo.)
> Of course anyone could say that resourceA -> dc:relation -> resourceB. But
> that wouldn't be recognized as being part of schema.org, which has to be
> in the schema.org namespace, so I'm not sure what the relevance of the dc
> properties are to our discussion. If we want resource relationships to be
> recognized by schema.org we need to define them in schema.org, right?
>
By definition, yes, of course. While it would be nice if the big search
engines committed to understanding a bit more of the existing vocabularies
in the world, alas, we're not there yet. My point though, is that in order
to keep schema.org from becoming a total reinvention, I strongly encourage
us to ground our proposals in existing work (especially that which is used
in the wild), and to be explicit about that, whenever possible. There seems
to be a lot to gather from the Dublin Core terms which is pertinent to the
debate about usage and meaning of 'commonEndeavor' and 'instanceOf'. My
proposal is to include some of these terms in schema.org. That is, their
definitions, and if workable, their names.
I must repeat that the DC terms have given shape and meaning to lots of
data in the wild, supporting various methods of description (including, but
in no way restricted to, FRBR). I wonder why they could not do so in this
context? Why do we need to invent other delineations?
And even if we do, and thus cannot find any other DC term valuable in this
context (though I'd be somewhat surprised by that), at least we can
establish a relation between those terms and the precise meaning of the
proposals 'commonEndeavor' and 'instanceOf' (or variants thereof).
Cheers,
Niklas
[1]: http://dublincore.org/documents/usageguide/qualifiers.shtml#isVersionOf
>
> kc
>
>
>
>> 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> <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>
>> <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>
>> <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>
>> <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>
>>
>> <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>
>>
>> <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>
>> <mailto: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>
>>
>> <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>
>> <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> <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>
>> >
>>
>>
>> <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<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>
>> >
>>
>> <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>
>> >
>> <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>
>> >
>>
>> <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>
>> <mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net>>
>> http://kcoyle.net
>> ph: 1-510-540-7596 <tel:1-510-540-7596> <tel:1-510-540-7596
>> <tel:1-510-540-7596>>
>> m: 1-510-435-8234 <tel:1-510-435-8234> <tel:1-510-435-8234
>>
>> <tel:1-510-435-8234>>
>> skype: kcoylenet
>>
>>
>>
>> --
>> 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 Monday, 8 July 2013 12:29:18 UTC