relationships

[Hugh Paterson III]

Greetings,

I am looking for the difference between:

LRMI's relationship "isBasedOn" which expects the URL to the related resource and a Dublin Core relationship such as: "hasPart", "isPartOf", "hasFormat", "isVersionOf", "isFormatOf".

Is there an intentional and unique semantic difference between the LRMI relationship and each one of these DC relationships? 

My system architect wants to make sure that we are not duplicating data/relationships (and I agree). In the documentation and discussion on LRMI I am not easily finding the unique contribution that lrmi.isBasedOn provides over and above DC declarations. If we already have the DC elements for objects, which DC relationship is congruent (and perhaps interoperable with the value of a "isBasedOn" declaration)?

Any assistance or clarity to guide our thinking in this would be appreciated.

Thank-You,

- Hugh Paterson III

[Phil Barker]

On 14/04/16 18:17, Hugh Paterson III wrote:

Greetings,

I am looking for the difference between:

LRMI's relationship "isBasedOn" which expects the URL to the related resource and a Dublin Core relationship such as: "hasPart", "isPartOf", "hasFormat", "isVersionOf", "isFormatOf".

Is there an intentional and unique semantic difference between the LRMI relationship and each one of these DC relationships?

Hello Hugh,
first of all, there is no reason why LRMI isBasedOnUrl (as it is currently called, though that may change) should make a unique contribution over and above DC terms. LRMI properties were designed to supplement *schema.org* to enable the description of learning resources. If there were terms useful for describing educational properties and relationships in the DC namespace that were not part of schema.org, then they were candidates for being included in LRMI. Of course, there are differences in approach between and history between schema.org and DC which mean that they might not look the same once they get there.

That said, the answer to your question is:

The use case for isBasedOnUrl was that very often open educational resources are repurposed before being reused. For example, I, in the UK, may take a resource which compares rainfall between US cities (Seattle and Utah) and change it to make reference to UK cities (Manchester and Norwich) and therefore more suitable for my students. isBasedOnUrl allows me to express the relationship between my resource and the original.

Looking at the the DC terms you mention:
* hasPart, isPartOf: no, being based on a resource is not the same as being part of it (and schema.org has http://schema.org/hasPart and http://schema.org/isPartOf)

* isFormatOf / hasFormat: no, this would do for changing a Word file to PDF, but that's not a substantive change (and schema.org has http://schema.org/encoding which can be used for this)

* hasVersion: yes, in the sense that this links to "A related resource that is a version, edition, or adaptation of the described resource"-- isBasedOnUrl covers the 'adaptation of the described reasource.'  Schema.org has http://schema.org/workExample / http://schema.org/workExample which covers some of the same ground as hasVersion

Hope this helps, Phil

My system architect wants to make sure that we are not duplicating data/relationships (and I agree). In the documentation and discussion on LRMI I am not easily finding the unique contribution that lrmi.isBasedOn provides over and above DC declarations. If we already have the DC elements for objects, which DC relationship is congruent (and perhaps interoperable with the value of a "isBasedOn" declaration)?

Any assistance or clarity to guide our thinking in this would be appreciated.

Thank-You,

- Hugh Paterson III

--
You received this message because you are subscribed to the Google Groups "Learning Resource Metadata Initiative" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lrmi+uns...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

-- 
--  
Phil Barker           @philbarker
LRMI, Cetis, ICBL     http://people.pjjk.net/phil
Heriot-Watt University

Ubuntu: http://xkcd.com/456/
  not so much an operating system as a learning opportunity.

[Phil Barker]

On 14/04/16 19:25, Phil Barker wrote:
...

> That said, the answer to your question is:
>
> The use case for isBasedOnUrl was that very often open educational
> resources are repurposed before being reused. For example, I, in the
> UK, may take a resource which compares rainfall between US cities
> (Seattle and Utah) and change it to make reference to UK cities
> (Manchester and Norwich) and therefore more suitable for my students.
> isBasedOnUrl allows me to express the relationship between my resource
> and the original.
>
> Looking at the the DC terms you mention:
> * hasPart, isPartOf: no, being based on a resource is not the same as
> being part of it (and schema.org has http://schema.org/hasPart and
> http://schema.org/isPartOf)
>

On second thoughts, for reuse in aggregate works, this hasPart/isPartOf
makes sense.

P.

[Paul Libbrecht]

Phil,

this is clearly an example of relationship specialization or?

Phil Barker wrote:
> * hasVersion: yes, in the sense that this links to "A related resource
> that is a version, edition, or adaptation of the described resource"--
> isBasedOnUrl covers the 'adaptation of the described reasource.'
> Schema.org has http://schema.org/workExample /
> http://schema.org/workExample which covers some of the same ground as
> hasVersion

Hugh,

which document confused you about the sense of these relationships?
Is this this label?
A resource that was used in the creation of this resource.
I suppose the answer of Phil is sufficient then.

I agree however, that this description is a bit vague and does not
include "isPartOf" (so, isPartOf would be a sub-type relationship of
isBasedOn).

I wonder if the text should explicitly stipulate the re-use since this
is an academic term and could include "dark re-uses" as D Wiley coined
them (re-uses which are more like "imitations" or "inspirations" and are
likely to be a lot more frequent).

Paul

[Hugh Paterson III]

Paul,

There is no document on the LRMI side of things which is confusing. We have a repository which uses DC metadata. We are adding metadata to better describe our learning resources. We have a process to add new schemas or metadata elements to our existing schema. That process requires that any element added add new semantic information. If there is already an element with a given semantic purpose, then that previous element should be used (at least in our policy). So, I was coming at LRMI from the perspective of looking through the eyes of Dublin Core, and wondering if any of our existing relationships would successfully map to the LRMI relationship isBasedOnUrl. We currently have a custom relationship which is called dc.relation.isbasedon for a very similar use case as what Phil described. So, that might work for us. But having Phil explain his use case was very helpful. If anything I would say the specification document was not clear enough, to describe the kind of based-on-relationship. i.e. a creative work which is a translation of a second work is still in a based-on-relationship, but the nature of the relationship is different than Phil's example. we are currently doing something for translation relationships like: dc.relation.isTranslationOf but I believe that in schema.org terminology translationOfWork http://bib.schema.org/translationOfWork would express the same relationship. All the best,

Hugh Paterson III