RelatedItem: Should this section focus on expressing relationships to other element sets rather than wrapping another element set into the existing one?

[raydAtLC]

"Should this section focus on expressing relationships to other element sets rather than wrapping another element set into the existing one?"

I don't understand the question at all. Could you give an example?

[melanieWacker]

Anna and Brian volunteered to collaborate on this topic (1/29/14)

[melanieWacker]

From 1.29.14 call: (RD) We shouldn't preclude the use of related items as an inline element (RG) We should have both options: A URI pointing to the related item or nested within a record (AK) Having both options is important AK and BL will collaborate on this topic.

[blunalucero]

According to the MODS/RDF ontology (http://www.loc.gov/standards/mods/modsrdf/primer.html#relatedItem)

MODS relatedItem is treated as described in A property for each Enumerated Type. It is described by a triple of the form: {MODS resource} {property} #ModsResource Where {property} depends on the type of related item, as shown in the following table:

For a related item where type=	the RDF property is
"host”	relatedHost
"isReferencedBy”	relatedReferencedBy
"original”	relatedOriginal
"otherFormat”	relatedFormat
"otherVersion”	relatedVersion
"preceding”	relatedPreceding
"references”	relatedReference
"reviewOf"	relatedReview
"series”	relatedSeries
"succeeding”	relatedSucceeding

---

This is a straightforward translation of a MODS element that already lends itself to triples.

What about cases of relatedness that don't conform to these types? I am thinking specifically about published data that is used in another resource. None of the types describes that relationship. How to we express alternate forms of relatedness?

[raydAtLC]

"What about cases of relatedness that don't conform to these types"

Perhaps we need to review the charge, which includes:

development of a MODS/RDF ontology that will allow MODS/XML users to express their existing MODS records in RDF -

"existing MODS records" (i.e. not an ontology supporting original cataloging). Existing MODS records would not have cases of relatedness that don't conform to these types.

I'm just raising the question, I don't object to discussion of expanding the charge, however I think folks who will be doing original cataloging using an RDF ontology will be using BIBFRAME.

Ray

From: blunalucero [mailto:notifications@github.com] Sent: Monday, March 24, 2014 12:43 PM To: blunalucero/MODS-RDF Cc: Denenberg, Ray Subject: Re: [MODS-RDF] RelatedItem: Should this section focus on expressing relationships to other element sets rather than wrapping another element set into the existing one? (#4)

According to the MODS/RDF ontology (http://www.loc.gov/standards/mods/modsrdf/primer.html#relatedItem)

MODS relatedItem is treated as described in A property for each Enumerated Type. It is described by a triple of the form: {MODS resource} {property} #ModsResource Where {property} depends on the type of related item, as shown in the following table:

For a related item where type=

the RDF property is

"host”

relatedHost

"isReferencedBy”

relatedReferencedBy

"original”

relatedOriginal

"otherFormat”

relatedFormat

"otherVersion”

relatedVersion

"preceding”

relatedPreceding

"references”

relatedReference

"reviewOf"

relatedReview

"series”

relatedSeries

"succeeding”

relatedSucceeding

---

This is a straightforward translation of a MODS element that already lends itself to triples.

What about cases of relatedness that don't conform to these types? I am thinking specifically about published data that is used in another resource. None of the types describes that relationship. How to we express alternate forms of relatedness?

— Reply to this email directly or view it on GitHub https://github.com/blunalucero/MODS-RDF/issues/4#issuecomment-38468112 . https://github.com/notifications/beacon/4854536__eyJzY29wZSI6Ik5ld3NpZXM6QmVhY29uIiwiZXhwaXJlcyI6MTcxMTI5ODU5NCwiZGF0YSI6eyJpZCI6MjMxNTY3NTB9fQ==--0ad3febc8d212bebd7b96d6508bf495b0421ad07.gif

[melanieWacker]

In this case I suppose dataSource would cover this case in BIBFRAME? http://bibframe.org/vocab/dataSource.html

[melanieWacker]

See continued discussion on #19