Print

Print


On 1/26/14, 11:45 AM, Simon Spero wrote:
>
> Using annotations instead of properties in this case should be very 
> strongly motivated.
>

?? Did you get this backwards?

> Karen's annotation turtle is upside down* ( there is no subject for 
> the property to which the blank node is attached).
>

Could you send a corrected example? Thanks.


> Also, a well defined ontology should entail the class of the 
> illustrator, so there might not be a need to specify the "... a 
> foaf:Person" triple.
>

This is something I've wondered about, but it does seem that even when 
an ontology has defined a class, the rdf:type is explicitly stated. I've 
asked around and haven't gotten a good answer, but I think it is a 
courtesy/time saver, since it doesn't require a lookup of the ontology. 
All of the foaf examples that I can find explicitly include the 
foaf:Person type. If there are "best practices" around this I'd love to 
know what they are.

Meanwhile, something else occurred to me regarding the typing of the 
target for bibliographic data. I said that you probably want to consider 
the target to be the thing described by the bib data, not the metadata 
itself. That said, you still have choices in terms of typing -- is it 
"sound" or a "CD"? "text" or a "hardback book"? If your annotation is a 
review, you probably want to emphasize the content ("text" or "novel" or 
"sound recording"), not the carrier. However, if your annotation is a 
holding statement, it would seem that the carrier is the appropriate 
target type.  (And note that the target types in Open Annotation are 
just the dct:type vocabulary, which is quite general, somewhat like mime 
types.)

kc

> Simon
> * it's turtles all the way up
>
> On Jan 26, 2014 11:10 AM, "Karen Coyle" <[log in to unmask] 
> <mailto:[log in to unmask]>> wrote:
>
>
>     On 1/25/14, 8:42 AM, [log in to unmask]
>     <mailto:[log in to unmask]> wrote:
>
>     Jörg, thanks. One thing, though, that makes me cautious about
>     using annotations is that unless you supply a type for body and
>     target, you have no idea what kinds of things are annotated and
>     are annotating. In fact, in the below, I would want to do
>     something like (see inline):
>>
>>     @prefix oa: <http://www.w3.org/ns/openannotation/core/> .
>>     @prefix dc: <http://purl.org/dc/elements/1.1/> .
>>     @prefix lcrel: <http://id.loc.goc/vocabulary/relators/> .
>>     @prefix lobid: <http://lobid.org/organisation/> .
>>     @prefix xbib: <http://xbib.org/vocab/example/> .
>>
>>     <http://id.loc.goc/vocabulary/relators/ill> rdfs:label
>>     "illustrated by"@en .
>>
>>     xbib:work1 a xbib:Work;
>>         lcrel:ill [
>>             a xbib:Illustrator;
>>             xbib:identifier <URI for illustrator's name>
>>         ] ;
>
>     As a property, not an annotation:
>
>       xbib:work1 a xbib:Work;
>           xbib:ill <URI> .
>       <URI> a foaf:Person .
>
>     then as triples (which is the only way I can check what I've done)
>
>     xbibwork1 rdf:type xbib:Work .
>     xbibwork1 xbib:ill <URI> .
>     <URI> rdf:type foaf:Person .
>
>     As an annotation:
>
>         xbib:annotation [
>             a oa:Annotation;
>             oa:hasBody xbib:work1;
>
>             oa:hasTarget lcrel:ill;
>     oa:annotated
>     "2014-01-25T16:35:00Z"^^<http://www.w3.org/2001/XMLSchema#dateTime> <http://www.w3.org/2001/XMLSchema#dateTime>
>     ;
>            oa:annotator lobid:DE-605#joerg;
>             oa:motivatedBy oa:identifying
>       ] .
>       xbib:work1 a dctypes:?? .
>       lcrel:ill a foaf:Person .
>
>     triples:
>
>     xbib:annotation rdf:type oa:Annotation .
>     xbib:annotation oa:hasBody xbib:work1 .
>     xbib:annotation oa:hasTarget lcred:ill .
>     xbib:annotation oa:annotated
>     "2014-01-25T16:35:00Z"^^<http://www.w3.org/2001/XMLSchema#dateTime> <http://www.w3.org/2001/XMLSchema#dateTime>
>     .
>     xbib:annotation oa:annotator lobid:DE-605#joerg .
>     xbib:annotation oa:motivatedBy oa:identifying .
>
>     xbib:work1 rdf:type dctype:?? .
>     lcrel:ill rdf:type foaf:Person .
>
>     Looking at this, I'm just not sure this fits into the annotation
>     model. The "illustrated by" is not a thing (and annotations are
>     relations between two things) -- it is a property.
>
>     I also have a hard time deciding how I should type the
>     bibliographic record as a target - it's not the book or the CD or
>     the map, it's a metadata record representing those. However, most
>     bodies will be annotating the represented content, not the
>     metadata record. So, in terms of typing, do we 1) refer to the
>     underlying expression ("text" "sound") (this is what the dctypes
>     are best for) 2) the package ("book" "CD") 3) the bibliographic
>     entity ("frbr:Work" "BIBFRAME:Work")?
>
>     kc
>
>>     xbib:annotation [
>>     a oa:Annotation;
>>             oa:hasBody xbib:work1;
>>             oa:hasTarget lcrel:ill;
>>     oa:annotated
>>     "2014-01-25T16:35:00Z"^^<http://www.w3.org/2001/XMLSchema#dateTime>
>>     ;
>>     oa:annotator lobid:DE-605#joerg;
>>         oa:motivatedBy oa:identifying
>>     ] .
>>
>>     Jörg
>>
>>
>>
>>     On Sat, Jan 25, 2014 at 2:06 AM, Karen Coyle <[log in to unmask]
>>     <mailto:[log in to unmask]>> wrote:
>>
>>         The following is from a discussion paper [1] being presented
>>         at the MARC Advisory Committee at ALA. It has information
>>         about BIBFRAME treatment of relators (MARC relators [2] and
>>         RDA/FRBR entity relationships [3]) that I have not yet seen
>>         on the BIBFRAME site, so I thought it might be of interest:
>>
>>>
>>>             5. BIBFRAME DISCUSSION
>>>
>>>         In BIBFRAME these relationships are handled as follows.  The
>>>         illustrations shown below use the RDF turtle notation. (See
>>>         Introduction to Turtle used in MAC Papers
>>>         <http://loc.gov/marc/mac/turtle4mac.html>.)
>>>
>>>         In the BIBFRAME vocabulary the relationships between
>>>         cataloging resources and between cataloging resources and
>>>         names (commonly called roles or relators) such as those in
>>>         Appendices J and I respectively are accommodated by sets of
>>>         properties with the "escape" to designate any relationship
>>>         not specifically provided.  This provides flexibility and
>>>         encourages efficiency in expressing the relationships via
>>>         URIs for the descriptions of the related resources where
>>>         possible.
>>>
>>>         For the cataloging resource relationships the set goes from
>>>         the most general, relatedResource, to the general (which are
>>>         essentially the high level relationship categories in the
>>>         RDA Appendix J (e.g., equivalent, accompanies, precedes,
>>>         etc.) to a number of specific relationships (series,
>>>         translation, dataSource, supplement, etc.). The latter
>>>         includes the specific supersedes and precedes sub
>>>         relationships used by the ISSN system.  Not all of the 300+
>>>         and their reciprocals are expressed as properties.  All of
>>>         the included properties efficiently link directly to the URI
>>>         of the description of the related resource.  If a more
>>>         specific relationship is needed, then the relationship can
>>>         be expressed in URI or literal form, and the link to the
>>>         description of the related resource can be specified via the
>>>         Related class.
>>>
>>>         work1  a  bf:Work;
>>>                     bf:accompanies  <work2 URI>.
>>>
>>>         work1 a bf:Work
>>>                     bf:accompanies   relationship1.
>>>         relationship1  a  bf:Related;
>>>                     bf:relationship  "augmented by catalogue";
>>>                     bf:identifier  <work2 URI>.
>>>
>>>         The relationships between cataloging resources and names as
>>>         RDA list in Appendix J and the one aligned with it in MARC
>>>         that also provides codes are similarly expressed as
>>>         properties with a very general property relatedAgent and
>>>         three general properties, agent, creator, and contributor,
>>>         with additional relationships expressed in literal or URI
>>>         form as above.
>>>
>>>         work1  a  bf:Work;
>>>                     bf:contributor  <URI for illustrator's name>.
>>>
>>>         work1 a bf:Work
>>>                     bf:contributor   relationship1.
>>>         relationship1  a  bf:Related;
>>>                     bf:relationshipID
>>>         id.loc.gov/vocabulary/relators/ill
>>>         <http://id.loc.gov/vocabulary/relators/ill>;
>>>                     bf:identifier  <URI for illustrator's name>.
>>>
>>         I'm assuming that the "relationship1" in these examples is a
>>         blank node, although it isn't indicated as such. I'm not
>>         clear on how one knows the nature of the value of
>>         bf:identifier, particularly when the relationship is a
>>         literal string. Perhaps I'm overlooking something?
>>
>>         kc
>>
>>         [1] http://loc.gov/marc/mac/2014/2014-dp04.html
>>         [2] http://loc.gov/marc/relators/
>>         and
>>         http://id.loc.gov/vocabulary/relators.html
>>         [3] Not having access to the RDA toolkit, I guess the best
>>         other source for these is the registry recently announced:
>>         http://www.rdaregistry.info/
>>
>>         -- 
>>         Karen Coyle
>>         [log in to unmask]  <mailto:[log in to unmask]>  http://kcoyle.net
>>         m:1-510-435-8234  <tel:1-510-435-8234>
>>         skype: kcoylenet
>>
>>
>
>     -- 
>     Karen Coyle
>     [log in to unmask]  <mailto:[log in to unmask]>  http://kcoyle.net
>     m:1-510-435-8234  <tel:1-510-435-8234>
>     skype: kcoylenet
>

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