Resource role -- Proposal for an extension of SDShare to support Topic Maps

[heuer]

I don't want to spoil the party but I think supporting Topic Maps would be nice and could easily be done.

I propose to extend the <resource> element with an optional, TM-specific role attribute which takes the following values:

• subject-identifier
• subject-locator
• item-identifier

The role attribute is an indicator for a Topic Maps implementation which kind of IRI is meant by the resource element.

Fragment generation algorithm

• Include in S all statements in G in which R is the parent (topic names, occurrences)
• Include in S all identities (subject identifiers, subject locators, and item identifiers) of R
• Include in S all associations in G where R plays a role
• Include in S all Topic Maps constructs in G where R is used as type
• Set the role attribute of the sd:resource element to an appropriate value. If the topic has more than one identity, use either a subject identifier (preferred) or subject locator. If the topic has no subject identifiers or subject locators, use an item identifier.

Note: The algorithm assumes that's not possible to update an individual name, occurrence, association or role; the algorithm works subject-centric or topic-centric. It would be possible to extend the algorithm to support names, occurrences, and associations which have an item identifier, though.

2nd note: The fragment generation algorithm is just a draft, an option would be to keep the typed Topic Maps constructs out of the fragment, like the RDF algorithm keeps the predicate and object statments out of the fragment. Decisions could be made after the role attribute has been accepted, if it gets accepted at all.

The client update algorithm for Topic Maps would be the same as for RDF.

[gra-moore]

I like the simplicity of this from a technical point of view but right now dont want to pollute the RDF message. Once the main spec is bedded down then having this and (maybe an OData) extension would be good. They could be seperate documents link from the specification page. We could consider modularising the specs so that no one spec is favoured, but again, at the moment having one small concise, well bounded spec feels good.

[ihenriksen]

I'm a topic maps fan, don't get me wrong. But let us keep the specification simple and not mix in other semantic technologies etc., at least for V1.0.