Comments (8)
I believe that using isPartOf may not be the best approach for modeling this kind of cases.
The Web Annotation Model defines the property "scope" (oa:hasScope). https://www.w3.org/TR/annotation-model/#scope-of-a-resource
It is defined as "The relationship between a Specific Resource and the resource that provides the scope or context for it in this Annotation."
In my opinion, the manifest should be referenced in the "scope" property, as follows:
"target": {
"type": "SpecificResource",
"source": {
"id": "https://preview.iiif.io/cookbook/0306-linking-annotations-to-manifests/recipe/0306-linking-annotations-to-manifests/canvas-1",
"type": "Canvas",
},
"scope" : "https://preview.iiif.io/cookbook/0306-linking-annotations-to-manifests/recipe/0306-linking-annotations-to-manifests/annotationpage.json",
"selector": {
"type": "FragmentSelector",
"conformsTo": "http://www.w3.org/TR/media-frags/",
"value": "xywh=300,800,1200,1200"
}
}
from trc.
That's a good point @nfreire, thanks a lot for your comment. That would make perfect sense what makes partOf very attractive is that we can specify the type of element that the resource is part of e.g. Manifest:
"partOf": [
{
"id": "https://preview.iiif.io/cookbook/0306-linking-annotations-to-manifests/recipe/0306-linking-annotations-to-manifests/annotationpage.json",
"type": "Manifest"
}
]
For a viewer, I think it could be very handy to have this because potentially an annotation could be part of many elements. And the "scope" is in fact "a resource that provides the scope" so it could be also a URL that a viewer can not consume. I don't think we can specify a type for the scope, at least I don't see any mention of it in the Web Annotation Data Model. Just to clarify: I used the definition of partOf of IIIF spec but in fact, in the web annotation data model partOf describes a relationship between the Page and the Annotation Collection but this is defined at the level of the Annotation Page, not at the Annotation. I think however we should ask for advice from @azaroth42.
from trc.
Ok, I see the importance for the use case in having type of element that the resource is part of.
The scope of the annotation is a resource, so one can add an rdf:type or other properties if necessary.
But the solution with dcterms:isPartOf looks valid to me as well. I don't think that there is any problem in using dcterms:isPartOf as an attribute of the source resource. The Web Annotation Model defines how the property should be used between Pages and Collections, but this does not restrict its use in other resources.
In general, my opinion is that both solutions are valid. In Europeana, we have a similar use case and we have chosen to use scope, so maybe my opinion is biased towards using scope :)
I hope we get more feedback from others experienced with Web Annotation.
from trc.
Both are valid -- the web annotation model says that you can have a scope
for a specific resource, and IIIF says that you can use partOf
to assert that a resource is part of another resource. So the question comes down to best practice and consistency, rather than which is right or wrong.
My view is that partOf
will be more consistent with other constructions, as it doesn't require the use of a SpecificResource. For example, if the annotation was instead targeting the entire canvas rather than a part of it, the annotation could have a target
of the Canvas directly which is then partOf
the manifest. Using scope
would require a SpecificResource without a Selector which is more complicated for the simple case.
So I'm in favor of the recipe as it stands
from trc.
Thanks a lot Nuno and Robert let me know if you think I should add some additional text to clarify.
from trc.
We were just discussing this in the cookbook authors meeting and came up with a couple of JSON-LD questions that we don't think impact the recipe but:
- IIIF defines
partOf
asdcterms:partOf
but the Web annotation data model defines it asas:partOf
part of the activity streams standard. IIIF Context and Web Annotations Context.
Will the use of partOf within the canvas conflict with the Web annotations use of partOf. We think not as the IIIF context looks like it overrides the annotations use but just wanted to check.
- Secondly we saw that IIIF defines partOf as
dcterms:partOf
but we couldn't find partOf in the list of dcterms: https://www.dublincore.org/specifications/dublin-core/dcmi-terms/ but there is isPartOf. Shoud the IIIF context point to this one? Actually it looks like there is already an issue for this.
from trc.
However, the target of the Annotation contained in the Annotation Page file will be a Specific Resource this allows us to use a partOf attribute inside the source element to point at the original Manifest containing the Canvas.
In this sentence, I feel like this allows us...
should rather be , which allows us...
? Or even be another sentence... 🤷♂️
from trc.
Issue 111 (Recipe #0306: Linking external Annotations targeting a Canvas to a Manifest )
+1: 16 [akrishnan15 azaroth42 digitaldogsbody dlpierce emilyewahl glenrobson jtweed julsraemy ksclarke markpbaggett mikeapp nfreire regisrob robcast thehabes tpendragon]
0: 0 []
-1: 0 []
Not TRC: 0 []
Ineligible: 1 [ioanrichards]
Result: 16 / 16 = 1.00
Super majority is in favor, issue is approved
from trc.
Related Issues (20)
- Georeference Extension HOT 9
- Recipe #0068: A basic newspaper - rewrite HOT 7
- IIIF Authorization Flow API 2.0 HOT 6
- Recipe #318: Locating an Item in Place and Time HOT 3
- Recipe #317: Image in annotations HOT 6
- Recipe #261: Annotation with a Non-Rectangular Polygon (update) HOT 4
- Recipe #0135: Annotating a specific point of an image HOT 2
- Proposal for adding 'timed-text' in the Text Granularity Extension HOT 4
- Migration of Selectors from Annex to Registry HOT 1
- Annotation Motivations TSG Charter HOT 2
- Recipe #283: Missing images in a sequence HOT 9
- Re-charter of the Authorization Flow TSG HOT 2
- Recipe #22: Redirecting from one Canvas to another resource (Hotspot linking) HOT 5
- Recipe #32: Simple Collection HOT 3
- Recipe #434: Multiple Choice of Audio Formats in a Single View (Canvas) HOT 8
- Recipe #466: Sharing a link to open a Manifest in a specific viewer. HOT 12
- Recipe #346: Annotating in Multiple Languages HOT 9
- Recipe #485 : Open a specific region of a canvas in a viewer
- Recipe #489 : Teaching with a Multimedia Canvas
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from trc.