...
Planning | Description | Requirements | UI Mockup | Triples Examples | Queries Examples
...
Table of Contents
Table of Contents |
---|
...
Name | Prefix | URL | Details | Comments |
---|---|---|---|---|
RDF | rdf | http://www.w3.org/1999/02/22-rdf-syntax-ns# | specification | |
RDF Schema | rdfs | http://www.w3.org/2000/01/rdf-schema# | specification | |
Dublin Core | dc | http://purl.org/dc/elements/1.1/ | specification | |
Dublin Core Terms | dcterms | http://purl.org/dc/terms | specification | Required by OA |
Dublin Core Types | dctype | http://purl.org/dc/dcmitype | specification | Required by OA |
Content | cnt | http://www.w3.org/2011/content# | specification | Required by OA |
ORE | ore | http://www.openarchives.org/ore/ 1.0terms/vocabulary#otherRelationships | specification | Recommended as an alternative to the Collections ontology by Rob. Represents both ordered and unordered items using the Aggregation class. |
IANA | iana | http://www.iana.org/assignments/relation/ | specification | ORE uses this ontology for first, last, next, and prev predicates. |
Collections | co | http://purl.org/co | Can represent unordered items using the Bag class and ordered items using the List class. | |
Open Annotation | oa | http://www.w3.org/ns/oa | specification | |
Friend of a Friend | foaf | http://xmlns.com/foaf/0.1 | specification | Also used by OA |
...
- Should dc:creator be used for ownership role?
- ANSWER: NO - per Paolo
- REASON: Muddy concept. Did the user create the resource or add the resource to the collection?
- ALTERNATIVE: Under exploration. Paolo recommends looking at...
- PROV ontology - provenance
- PAV ontology - provenance, authoring, and versioning
...
(Paolo) I apologize that should have been a co:Set to be clearer. For Bags you need to have an instance of Item to support for repeated elements. Once you flatten down to co:element the repeated items become one. The idea of the co:element (defined as chain) in general is to provide a shortcut to the elements. In that case we are interested in finding the existence (one of them), the repetitions are irrelevant at that level.
(Rebecca) I see on the description of the Collections Ontology that "the Collections Ontology (CO) defines unordered collections (Set and Bag) and ordered collections (or List)." It seems awkward to select an ontology in which the type of the collection has to change if ordering is added to an originally unordered collection, or vice versa. That seems to me an advantage of the ORE ontology.
(Paolo) that is a fair point but the description is not accurate, the approach has been described in the paper, here it is:
...
<x> a ore:Aggregation ;
ore:aggregates <a> ; // should be repeated at the end
ore:aggregates <b> ;
ore:aggregates <c> .
<p1> a ore:Proxy ;
ore:proxyFor <a> ;
ore:proxyIn <x> ;
iana:next <p2> .
<p2> a ore:Proxy ;
ore:proxyFor <b> ;
ore:proxyIn <x> ;
iana:next <p3> .
<p3> a ore:Proxy ;
ore:proxyFor <c> ;
ore:proxyIn <x> ;
iana:next <p4> .
<p4> a ore:Proxy ;
ore:proxyFor <a> ;
ore:proxyIn <x> .
(Rebecca) I don't actually find this so strange. If proxies are the means to specify relationships, such as sequencing, among the aggregated resources, then if an aggregated resource has more than one relationship to other resources, as in occurring at multiple positions in a sequence, it seems natural that it would have a proxy for each.
(Paolo) I do find it strange but not 'that strange'. In CO you can infer the top part so the co:element will have only three objects (with no repetition). But the actual declarative structure will list all of them.
Example 4-ore: A Virtual Collection as an unordered collection of items using ORE Ontology's Aggregation with multiple unordered items
...