access/license/ric in the main entity?

[eroux]

This is probably the last part of the ontology that makes me itch each time I'm dealing with it... I think the access/license/restricted triples should be attached to the entity itself and not to the admindata, because they are about accessing the images themselves, not the metadata...

Also, we should be able to attach license to normal instances too (not just image/etext ones), but it would be an addition more than a change, as we would keep the current license indication on the images.

Finally, I'm wondering where ideally the georestriction should be attached... well, probably on all instance but even on the admindata (if we want to restrict metadata access)...

@xristy wdyt?

Edit: sorry, license is attached on the legaldata, see comment below for that case. But I still think license should be attached on the normal instance too, it would be an additional information that we don't currently have (but that we can infer most of the time)

[eroux]

BTW, just realized that if we go this route, we can attached the contentLegal to the entity itself and replace it with hasLegal, which makes just one property necessary instead of two (metadataLegal + contentLegal).

[xristy]

Associating :contentLegal w/ the :Instance seems appropriate, and, if I'm understanding your idea, renaming :contentLegal to :hasLegal and then having some triples such as:

bdr:SomeThing :hasLegal bdr:LegalNotice1 ;
.
bda:SomethingAdmin adm:adminFor bdr:SomeThing ;
  :hasLegal bdr:LegalNotice2 ;
.

unambiguously indicates what the legal notices apply to.

This seems quite reasonable.

[eroux]

yes that would be it for the legal stuff. What do you think about the access/restricted in China?

[xristy]

I think adm:access can be replaced by :Instance :access :Access moving the adm:AccessType to :AccessScheme, and the bda:RestrictedInChina could be replaced by adm:AdminData adm:geoRestriction :Place so that the geographical restrictions can be placed on metadata and content which seems to me to be what we want so that there is no trace of the instance as it were when accessing from the restricted area.

Separating the access and restriction allows to indicate fair use or perhaps restricted by quality access w/o having to have some awkward interpretation of a combination of those intended access expressions which are logically independent of geographical restrictions.

Regarding

Also, we should be able to attach license to normal instances too (not just image/etext ones), but it would be an addition more than a change, as we would keep the current license indication on the images.

I'm not sure what would be licensed other than the content (images and etext) of an instance or the metadata describing the instance. Are you thinking of physical items or microfilm, both of which are most likely under the custody of other organizations?

[eroux]

ok for access and georestriction yes. For license I'm thinking of adding the property to works actually. It would serve to indicate if the work is under copyright in the US or not.

[xristy]

Are you thinking both Instance and Work or just Work? Do you have examples that might help distinguish the possibilities and point out the ramifications?

[eroux]

I think license should be usable on both. An example is a work in the public domain that has an instance that claims copyright, this is the case for most recent editions

Le lun. 6 avr. 2020 à 22:01, Chris Tomlinson notifications@github.com a écrit :

Are you thinking both Instance and Work or just Work? Do you have examples that might help distinguish the possibilities and point out the ramifications?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/buda-base/owl-schema/issues/163#issuecomment-610006690, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAO3RC3A264MDGMXCVQOCTRLIYITANCNFSM4MCDVA3Q .

[xristy]

I'm not sure on this. I understand you're idea to be that the common case for all Instances be placed on the common abstract Work; however, registration of copyright (at least in the U.S.) requires deposit of an item in tangible form, i.e., an Instance so shouldn't we attach the license to each Instance?

[eroux]

I don't think many of our works are registered in the US. The copyright we're dealing with is mostly ruled by international conventions in our case. In most countries (in France for instance) you have the copyright on anything you write, you don't have to register anything (although it can help in case of a trial I suppose)... I would be surprised that in the US you don't have any copyright on your creation until you register it somehow... In any case, some intellectual works (I insist on the work) are copyrighted, some are in the public domain... that's what we want to record. My understanding is that some sheets of paper stitched together with some ink on them cannot be copyrighted, only the intellectual work they carry can. But let's not debate this and be pragmatic, let's allow the :license property to be attached to:

• admindata
• instance
• work

that will cover what we want to cover in our cataloging.

[xristy]

ok. So a single property:

[ owl:unionOf ( :Work :Instance adm:AdminData ) ] :license adm:License

In the U.S., as you mention, as elsewhere, copyright automatically attaches in a legally less enforceable manner as soon as the creative content is reduced to a tangible form. As I understand it, the purpose of registration is to provide an effective legal basis for pursuing claims of infringement.

[eroux]

yes perfect! thanks a lot!

[xristy]

Do we want to reassign adm:icense as bdo:License taking it as a core concept rather than just a component of our metadata administration?

[eroux]

I think it would make sense yes

[xristy]

oops, it seems the :license needs to be:

[ owl:unionOf ( :Work :Instance adm:LegalData ) ] :license bdo:License .

or does it need to be both adm:LegalData and adm:AdminData?

[xristy]

final for now w/:

[ owl:unionOf ( :Work :Instance adm:AdminData adm:LegalData ) ] :license bdo:License .

[eroux]

oh yes right, no problem

[xristy]

I think this issue is complete with commit 0ef9eab