Print

Print


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:
> 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] 
> <mailto:[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] 
>> <mailto:[log in to unmask]>> wrote:
>>
>>>
>>> On 7/24/13 8:09 AM, Robert Sanderson wrote:
>>>>
>>>> * 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 <http://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
>>>
>>>> * 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] 
>>>> <mailto:[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
>>>>     <http://kcoyle.net/img/OAnBFcore.jpg>
>>>>
>>>>     --
>>>>     Tom Baker <[log in to unmask] <mailto:[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