Re: Using dc:isFormatOf to unify instanceOf and commonEndeavor with existing practise

Hi Jeff,

That might be, but I imagine it's rather a case of schema.org and DC terms
coinciding and having been subsequently correlated (it appears so to me
after studying information published e.g. at [1]). I'd rather think that,
just as was the case with GoodRelations, members of this initiative, along
with e.g. the DC community, have more in-depth needs and knowledge to be
able to add additional, valuable properties and classes applicable to more
specific needs regarding bibliographic information (and indeed related
descriptions about human documents and artifacts).

I also agree that an Agent class can be quite useful. Not the least for
when you're not really sure what kind of agent you're talking about. ;) And
right now, the lack thereof restricts a bunch of properties in schema.org.
For instance, 'publisher' can only be an Organization.

While the word "format" brings different things to mind, it is simply
defined [2] for Dublin Core as:

    The file format, physical medium, or dimensions of the resource.

    Examples of dimensions include size and duration. Recommended best
practice is to use a controlled vocabulary such as the list of Internet
Media Types.

A minimal and open, but to me rather usable definition.

.. Now, it might be argued that the *naming* of properties in DC are a bit
strange at times. For example, you're supposed to describe a specific
resource, say a PDF representation of a book, to be 'isFormatOf' the book,
and also have a 'format' of "PDF" (well, rather "application/pdf", or link
(with a URI) to a definition thereof). I personally think there aren't real
problems though, as it is the meaning and not the name that's important,
and as long as there is a difference. But if we come to agreement about
meaning and usage (again, ideally without inventing something new), I am
also for considering a suitable naming of the properties we propose for
addition in schema.org.

Perhaps 'sameContentAs' would be a better name than 'isFormatOf' (though
still based on 'dcterms:isFormatOf'). Somewhat closer to 'commonEndeavor'
(the names imply little about horizontal vs. generalizes), but still with a
difference to 'isVersionOf' – which I think is a useful distinction.

Cheers,
Niklas

[1]: http://wiki.dublincore.org/index.php/Schema.org_Alignment
[2]: http://purl.org/dc/terms/format



On Wed, Jul 3, 2013 at 3:14 AM, Young,Jeff (OR) <jyoung@oclc.org> wrote:

> I'm inclined to agree with Karen. I get the sense that Schema.org has
> already cherry-picked all the terms from Dublin Core that people readily
> understand. (Personally I think they underestimate foaf/dcterms:Agent as a
> superclass of schema:Person and schema:Organization, but that opinion can
> be discounted by how long it took me to realized that Lynyrd Skynyrd wasn't
> a person. :-)
>
> The concept of "format" tends to confuse me. It seems to mean so many
> different things to so many different people. So much so, that I've never
> been tempted to use it. If others disagree, though, I would be happy to
> reconsider.
>
> Jeff
>
> Sent from my iPad
>
> On Jul 2, 2013, at 6:37 PM, "Karen Coyle" <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/> (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>).
> >>
> >> 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>
> >> [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
> >> [2]: http://grammar.ccc.commnet.edu/grammar/composition/abstract.htm
> >> [3]: http://purl.org/dc/terms/
> >> [4]: http://purl.org/dc/terms/isFormatOf
> >> [5]: http://www.legislation.gov.uk/developer/formats/rdf
> >> [6]: http://www.w3.org/wiki/WebSchemas/Datasets
> >>
> >> --
> >> Niklas Lindström
> >> National Library of Sweden (KB)
> >>
> >
> > --
> > Karen Coyle
> > kcoyle@kcoyle.net http://kcoyle.net
> > ph: 1-510-540-7596
> > m: 1-510-435-8234
> > skype: kcoylenet
> >
> >
>
>
>