You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I like how the definition of Asset is based on FRBR entities, but I am unsure if combining the FRBR entities Work and Expression is a good idea. Let me explain where I feel it may benefit us to keep these distinct, using an example.
Suppose I maintain a data model. Over time multiple versions have come to exist, including versions which break compatibility with historical data. Still, one can validly choose to consider these to be versions of the same data model (unlike REST would btw).
Applying ADMS and hierarchical versioning as described in DCAT3, I could state something like this:
ex:myDataModel a adms:Asset .
ex:myDataModel-1 a adms:Asset .
ex:myDataModel-2 a adms:Asset .
ex:myDataModel-1 dct:isVersionOf ex:myDataModel .
ex:myDataModel-2 dct:isVersionOf ex:myDataModel .
ex:myDataModel-2 adms:prev ex:myDataModel-1 .
Now, since each asset is a combination of a FRBR expression and a FRBR work, all of these subjects are both a work and (their) expression. This means ADMS does not allow me to state multiple expressions for a work. But I think that's exactly what would be more semantically expressive here.
Let me show you by contrast how I would have modeled this using FRBR:
ex:myDataModel a frbr:Work .
ex:myDataModel-1 a frbr:Expression .
ex:myDataModel-2 a frbr:Expression .
ex:myDataModel-1 frbr:isRealizationOf ex:myDataModel .
ex:myDataModel-2 frbr:isRealizationOf ex:myDataModel .
ex:myDataModel-2 frbr:isRevisionOf ex:myDataModel-1 .
(I'm being explicit and verbose on purpose for clarity.)
This way, the (abstract) data model ex:DataModel becomes the work, of which all versions are expressions frbr:Expression. I feel like both more information is stated here, and more clarity obtained.
Note
To keep speaking the language of ADMS with respect to versioning, one could perhaps create alignments between dct:isVersionOf and frbr:isRealizationOf etc., or if this comes with undesired reasoning consequences a custom adms:isVersionOf with a maximally broad domain and range could be incepted.
Curious to hear your thoughts. Am I misunderstanding how Asset intends to combine Work and Expression? Am I perhaps applying FRBR wrong to my example? Etc. :)
Hello,
I like how the definition of
Assetis based on FRBR entities, but I am unsure if combining the FRBR entitiesWorkandExpressionis a good idea. Let me explain where I feel it may benefit us to keep these distinct, using an example.Suppose I maintain a data model. Over time multiple versions have come to exist, including versions which break compatibility with historical data. Still, one can validly choose to consider these to be versions of the same data model (unlike REST would btw).
Applying ADMS and hierarchical versioning as described in DCAT3, I could state something like this:
Now, since each asset is a combination of a FRBR expression and a FRBR work, all of these subjects are both a work and (their) expression. This means ADMS does not allow me to state multiple expressions for a work. But I think that's exactly what would be more semantically expressive here.
Let me show you by contrast how I would have modeled this using FRBR:
(I'm being explicit and verbose on purpose for clarity.)
This way, the (abstract) data model
ex:DataModelbecomes the work, of which all versions are expressionsfrbr:Expression. I feel like both more information is stated here, and more clarity obtained.Note
To keep speaking the language of ADMS with respect to versioning, one could perhaps create alignments between
dct:isVersionOfandfrbr:isRealizationOfetc., or if this comes with undesired reasoning consequences a customadms:isVersionOfwith a maximally broad domain and range could be incepted.Curious to hear your thoughts. Am I misunderstanding how
Assetintends to combineWorkandExpression? Am I perhaps applying FRBR wrong to my example? Etc. :)Greetings,
Bart