RDARegistry / RDA-Vocabularies

http://www.rdaregistry.info
63 stars 16 forks source link

Unconstrained property for WEMI relationships #53

Closed kiegel closed 3 years ago

kiegel commented 9 years ago

There is a group of constrained properties that are difficult to handle when WEMI entities are removed from them, that is, they are unconstrained:

exemplarOfManifestation (P30103) expressionManifested (P30139) expressionOfWork (P10078) manifestationExemplified (P40049) manifestationOfExpression (P20059) manifestationOfWork (P10072) workExpressed (P20231) workManifested (P30135)

They reduce to either "blankOfBlank" or "blankBlankified". However, these properties embody relationships between WEMI entities and the relationships cannot be ignored, even in an unconstrained model. It is crucial to relate a Manifestation to its Expression or Work, even though we may not necessarily use those terms.

It seems that a generalized, unconstrained WEMI-relationship property must be created. The existing relatedResource (P60313) may be too narrow, or perhaps it is good enough.

GordonDunsire commented 9 years ago

The ISBD and FRBR Review Groups discussed a related issue: the relationship between ISBD Resource and FRBR WEMI (see http://www.ifla.org/files/assets/cataloguing/isbd/OtherDocumentation/resource-wemi.pdf). As a result, the relationship properties were added to the ISBD element set, for example http://iflastandards.info/ns/isbd/elements/P1190 (has expression aspect) with definition "Relates a bibliographic resource to an expression reflected in it."

These properties are constrained by ISBD and FRBR domains and ranges, but the ISBD RG intends to publish unconstrained versions of the whole element set, which leads to a similar issue.

There is an assumption in the RDA unconstrained property labels and definitions that "resource" is closer in semantics to the ISBD Resource class than to the RDA Toolkit definition and scope note "A work, expression, manifestation or item. The term includes not only an individual entity but also aggregates and components of such entities (e.g., three sheet maps, a single slide issued as part of a set of twenty, an article in an issue of a scholarly journal). It may refer to a tangible entity (e.g., an audiocassette) or an intangible entity (e.g., a website)." The semantics are unclear: "or" appears to mean "and/or", in any combination of WEMI entities.

That is why the RDA element set does not include a class Resource.

The WEMI relationship properties are not mapped as sub-properties of relatedResource (P60313) for similar reasons. The RDA Development Team can review this if you can elaborate on "good enough".

kiegel commented 9 years ago

The question is: using unconstrained RDA, is it sufficient to express all relations between WEMI entities (expressed as "resources") with a single property, or are there classes of relationships that should be differentiated from each other? If there are multiple classes of relationships, then we need more properties (that is, relatedResource (P60313) alone is not sufficient).

I can't answer this question, and indeed we may need more experience with unconstrained RDA to discover use cases. But as an example of a distinction that could be made: do we want to tell the difference between relationships that point "down" the WEMI chain and those that point "up"? Is this important information that should not be lost, and that would be with relatedResource?

Another example: do we want to distinguish relationships between resources that are at the conceptual level and those that are tangible? Three classes of relationships could be created:

Conceptual to conceptual expressionOfWork (P10078) workExpressed (P20231)

Conceptual to tangible expressionManifested (P30139) manifestationOfExpression (P20059) manifestationOfWork (P10072) workManifested (P30135)

Tangible to tangible exemplarOfManifestation (P30103) manifestationExemplified (P40049)

kcoyle commented 9 years ago

My impression was that with the unconstrained RDA you have a single RDF subject/graph so that are no WEMI "things" to relate to each other. Of course, you could bundle groups of properties into their own graphs, but I don't think there are relator properties available in that vocabulary

kc

On 3/11/15 9:30 AM, Joe Kiegel wrote:

The question is: using unconstrained RDA, is it sufficient to express all relations between WEMI entities (expressed as "resources") with a single property, or are there classes of relationships that should be differentiated from each other? If there are multiple classes of relationships, then we need more properties (that is, relatedResource (P60313) alone is not sufficient).

I can't answer this question, and indeed we may need more experience with unconstrained RDA to discover use cases. But as an example of a distinction that could be made: do we want to tell the difference between relationships that point "down" the WEMI chain and those that point "up"? Is this important information that should not be lost, and that would be with relatedResource?

Another example: do we want to distinguish relationships between resources that are at the conceptual level and those that are tangible? Three classes of relationships could be created:

Conceptual to conceptual expressionOfWork (P10078) workExpressed (P20231)

Conceptual to tangible expressionManifested (P30139) manifestationOfExpression (P20059) manifestationOfWork (P10072) workManifested (P30135)

Tangible to tangible exemplarOfManifestation (P30103) manifestationExemplified (P40049)

— Reply to this email directly or view it on GitHub https://github.com/RDARegistry/RDA-Vocabularies/issues/53#issuecomment-78299898.

Karen Coyle kcoyle@kcoyle.net http://kcoyle.net m: 1-510-435-8234 skype: kcoylenet/+1-510-984-3600

GordonDunsire commented 8 years ago

Karen is essentially right.

Take a dataset for a single bibliographic resource using the RDA constrained properties. This will usually contain separate URIs for the Work, Expression, and Manifestation "aspects" of the resource instance:

URI1 [expressionOfWork] URI2 . URI2 [manifestationOfExpression] URI3 .

The property constraints entail URI1 is-a [Work] .; URI2 is-a [Expression] . ; URI3 is-a [Manifestation]

If the dataset is mapped to unconstrained RDA:

URI1 [relatedResource] URI2 . URI2 [relatedResource] URI3 .

There are no entailments for the type of URI1, URI2, or URI3.

If the dataset is created using unconstrained RDA:

URI4 [titleOfTheResource] "My title" . etc.

That is, URI4 identifies the bibliographic resource as a whole.

We should not say URI1 is-a [ISBD Resource] .

We can use the ISBD properties to say:

URI1 isbd:P1197 URI4 . URI2 isbd:P1194 URI4 . URI3 isbd:P1196 URI4 .

URI4 (Resource) is a kind of package of URI1 (Work), URI2 (Expression), and URI3 (Manifestation).

More simply, an unconstrained closed-world application could treat the URIs as being equivalent, identifying the same thing. This would not be safe in an open-world application, of course.

Currently, the unconstrained related resource property has constrained sub-properties:

rdae:P20205 "has related expression" rdam:P30048 "has related manifestation" rdam:P30140 "has related item"

There are no sub-properties of the constrained properties.

The DevTeam will look into adding the missing sub-property relationships for

rdaw:P10198 "has related work" rdai:P40046 "has related item of item"

The RSC Technical Working Group is looking into the basic relationships between RDA entities, including the "cross-entity" primary relationships (between different entities) and the existing "same-entity" relationship discussed above. This should provide a high-level hierarchy of sub-property relationships between entities - the more detailed hieararchies are accommodated by the relationship designators, and the RSC Relationship Designators Working Group is reviewing those.