Shlomo - not so much "simpler" but easier to maintain, to extend as needed, etc. The use of a type that can take any identifier as a value is by far the easiest and most extensible. What we must avoid is having to change our standard every time a new value is needed. That's what we have with MARC and it is a huge time sink to add even the smallest  new bit of information.

kc

On 7/25/13 11:02 PM, Shlomo Sanders wrote:
[log in to unmask]" type="cite">
In order for this to work for years to come we need to also keep in mind that it needs to stay as simple as possible (perhaps at some cost to theory).

Which approach is simpler?

Thanks,
Shlomo Sanders

On Jul 26, 2013, at 1:24, "Rob Sanderson" <[log in to unmask]> wrote:

Hi Karen 

I completely agree, and Open Annotation recommends exactly this pattern of using types (rdf:type) to provide additional classes for the resources involved in the annotation. 

Thus it's even more confusing that bib frame wants to re-invent every possible relationship between body and target, or class of body/target, as already expressed in this thread.

Rob

Sent from my iPad

On Jul 25, 2013, at 18:09, Karen Coyle <[log in to unmask]> wrote:


On 7/24/13 8:09 AM, Robert Sanderson wrote:
[log in to unmask]" type="cite">

* The use of predicates, which are not subProperties of hasBody, to link what OpAn would consider a body. A client would assume that there's no body and thus not know what to do with the target.  Without also a motivation, it's simply meaningless in Open Annotation.
* The different semantics -- hasCoverArt conveys a very different relationship to hasBody.  The /annotation/ does not have the image as its cover art, the target of the annotation is the resource that it is the cover art for.

I find it often helps to break things down into triples. In this case you would have:

A has target B
A has cover art C

If this means that B is the target of A, then it also means that C is the cover art of A.

Instead, what I believe BIBFRAME is looking for is a way to say:

C is a X (cover art, table of contents, publisher review)

Then you would have:

A has target B
A has body C
C is a X

Presumably X could be any class, so it would be a matter of finding or creating the appropriate set of classes.

If this were a schema.org discussion, someone would immediately suggest using http://www.productontology.org/, which is an ontology that makes use of Wikipedia page names for things. You would then have

http://www.productontology.org/Cover_art
http://www.productontology.org/Thumbnail

If such an option were chosen, this would either replace or co-exist with the DC Type vocabulary in the annotations. The key thing about the product ontology is that it is much more detailed than DC Type.

kc

[log in to unmask]" type="cite">
* Multiple bodies, and their semantics, are covered very clearly in OpAn -- having multiple resolutions of an image is semantically an oa:Choice.  Clients would display both the thumbnail and the full resolution resource, as semantically both are individual bodies.
* The motivation vs subclass issue and the literal body vs body as resource were discussed at length and the consensus was reached for the model based on interoperability and cross-community requirements.  If Bibframe wishes to not be interoperable with other communities, that's perfectly fine, but there's no point using an interoperability framework at that point.
(and so forth)

So while the reaction to explicitly and intentionally not be compatible with Open Annotation is definitely disappointing, it is in my view the correct decision rather than claiming compatibility where none really exists.  Bibframe's apparent requirement to re-invent everything within the bibframe namespace world view is equally confusing and disappointing.

Rob



On Wed, Jul 24, 2013 at 10:15 AM, Thomas Baker <[log in to unmask]> wrote:
Hi Ray,

On Tue, Jul 23, 2013 at 03:26:17PM -0400, Ray Denenberg wrote:
> > The loss of this very sensible mapping would be a pity if the basic
> > models -- at the level of what OA calls the Open Annotation Core --
> > really were compatible which, as far as I can see, they really are.
>
> Tom -  No, they really aren't. [...]
>
> One example of how BIBFRAME is different: each different type of Annotation
> has properties defined for that type.  For example, consider cover art.  We
> define a class CoverArt, and properties bf:coverArt and bf:coverArtThumb.

Okay, that's fine.  But I see nothing in the OA ontology -- i.e., the
beautifully generic properties and classes underpinning the more specifically
constrained OA Data Model -- that would preclude this.

> I.e. the Annotation provides a link to a thumbnail of the cover art which
> the user can examine to determine if he wants to retrieve the larger cover
> art image.  Thus, the payload of an Annotation isn't a single resource as in
> OA, it often may be several resources.

If by "payload of an Annotation" you mean what OA calls a "body" -- or in this
case two things, a thumbnail and a larger image, together constituting a body
-- then this appears to be consistent with the OA Data Model, which says:
"There SHOULD be 1 or more oa:hasBody relationships associated with an
Annotation but there MAY be 0" [1].  It is at any rate consistent with the
nicely minimal formal definition of oa:hasBody in the OA ontology.  If the idea
is to use bf:coverArt and bf:coverArtThumb instead of oa:hasBody, that is a
legitimate implementation decision but I do not see how this would be
inconsistent with either the OA Data Model or the OA ontology.

[1] http://www.openannotation.org/spec/core/core.html#BodyTarget

> (And I should mention here, we
> continue to define Annotation classes, rather than motivations as suggested
> by OA, for this reason, that each Annotation class has properties defined
> specifically for that class.)

Another legitimate decision, but I see no obvious contradiction to the OA
ontology there either.

> So, in fact, there is no formal "Body" defined. (There is the concept of a
> Body, defined to be the aggregate of triples corresponding to properties
> defined for that Annotation class, but there is no property hasBody formally
> defined.)

I think I get your point.  To "aggregate" them as a Body, if they are indeed
being "defined for" the Annotation class, perhaps you could declare
bf:coverArt, etc, as sub-properties of bf:annotationBody.  Then
bf:annotationBody could be a sub-property of oa:hasBody.

> On the other hand though, the concept of Target remains the same, and is
> still the same concept as an OA Target.  So, you could legitimately argue
> that
>
>        bf:annotates ->  subPropertyOf -> oa:hasTarget
>
> still makes sense, I suppose.  Does it really though, with all the other
> differences?

Yes, it can indeed be useful.  Consider the case of a single triple using
oa:hasTarget.  This tells you that the subject of that triple is an instance of
oa:Annotation, and that the triple links an annotation to some target resource.
In a Linked Data context, such a link can be useful independently of whatever
other properties that annotation may have.

Bottom line: If OA and BF properties are compatible [2], it is helpful to map
them explicitly.

Tom

[2] http://kcoyle.net/img/OAnBFcore.jpg

--
Tom Baker <[log in to unmask]>


-- 
Karen Coyle
[log in to unmask] http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet

-- 
Karen Coyle
[log in to unmask] http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet