My first N3 representation of the example Service document, with 3
classes :Service, :Workspace, and :Collection
<> a :Service;
:workspace [ a :Workspace;
:title "Main Site"@en;
:primaryCollection [ a :Collection;
:title "entries"@en;
:href <http://example.org/myblog/entries>;
:member-type :entry ];
:primaryCollection [ a :Collection;
:title "photos"@en;
:href <http://example.org/myblog/fotes>
:member-type :media ]
];
:workspace [ a :Workspace;
:title "Side Bar Blog"@en;
:primaryCollection [ a :Collection;
:title "Remaindered Links"@en;
:href <http://example.org/
reilly/list>;
:member-type :entry ]
] .
We can think of a Collection as a Feed. Perhaps a subclass of feeds
document resources at which one can also post? Perhaps we can even
specify this by creating two classes :EntryCollection
and :MediaCollection which we can define as follows
:Collection rdfs:subClassOf atom:Feed;
rdfs:label "Atom Application Collection";
rdfs:comment "An resource to which one can POST
resources, and which presents itself as an atom feed";
owl:unionOf ( :EntryCollection :MediaCollection ).
:EntryCollection rdfs:subClassOf :Collection;
rdfs:label "Entry Collection class";
rdfs:comment "One should only POST atom entries to entry
collections" .
:MediaCollection rdfs:subClassOf :Collection;
rdfs:label "Media Collection class";
rdfs:comment "Content posted to this collection will
create an entry and be the content of the created entry";
owl:disjointWith :EntryCollection .
Let us keep it simple and ignore the primary and secondary collection
distinction. Our example above could then be better written as
<> a :Service;
:workspace [ a :Workspace;
:title "Main Site"@en;
:collection [ = <http://example.org/myblog/entries>;
a :EntryCollection;
:title "entries"@en ];
:collection [ = <http://example.org/myblog/fotes>;
a :MediaCollection;
:title "photos"@en ]
];
:workspace [ a :Workspace;
:title "Side Bar Blog"@en;
:collection [ = <http://example.org/reilly/list>;
a :EntryCollection;
:title "Remaindered Links"@en;
]
] .
Because collections are subclasses of Feeds, we can also add the
other feed properties, such as id, author, updated, etc, to them if
we want. Of course no need to add entries in the Service document
itself as that would be of no interest.
If we represent things as above then we would have to specify that
the title be the title of the feed at the href location. But that
does not seem very controversial. Why not nail that down in the spec?
Henry
