Establishing a sense of order in a graph-based resource description scheme
would require implementing succession relationships. The simplest
relationships would sound like this:

    Target succeeds Destination

Which from a graph-theoretical perspective is **not** the same as saying

    Destination is_preceeded_by Target

See: for more information

W3C doctrine seeks to ³economize² on graph construction by suggesting that
complementary links - e.g., for every ³succeeds" link there should be an
"is_preceded_by link² could be optional.

While convenient at one level, this strategy masks the ³full² costs of
graph representation by declaring that a complementary link will be
materialized as required by an inference computation. This graph data -
inference rules plus inference engine dependency forecloses the
application of clean, well-established graph operations that work on graph
data alone, e.g.:
     NeighborhoodGraph is especially handy

Other ways to implement order in RDA could involve schemes that likewise
require inferential processing, e.g., alphabetical, numerical, date, etc.

Ron Murray

On 6/9/15, 5:13 PM, "Karen Coyle" <[log in to unmask]> wrote:

>Mac, there is no such thing as "order" in RDF. If there are two
>statements that use the same property (e.g. bf:note) there is no order
>implied between them and there's no "record" in RDF that would maintain
>an order between two or more properties. There is a function called
>"rdf:List" but that is not a highly used function, and I highly doubt
>that anyone is anticipating using rdf:List for notes. In general, what
>was done with order in the card/record world is done in RDF with the
>meaning of the data element.
>It seems to me that the problem is that there are many different
>"messages" that are currently being coded as bf:note. If there is any
>time when a specific note must be identified for some purpose, say as a
>particular display, then that note type has to be differentiated. This
>should be solved by having different types of notes, not by imposing an
>order on undifferentiated notes.
>My guess is that a clear statement of use cases for different types of
>notes would take this discussion further. What are the uses for
>different notes? Under what circumstances will notes be acted on
>(searched, displayed)? (Note that the answer to this may not entirely
>coincide with the note elements currently defined in MARC or ISBD. We
>should ask the question without prejudice and see what answers arise.)
>On 6/9/15 1:05 PM, J. McRee Elrod wrote:
>> It concerns me that so many RDA specific notes (as well as MARC ones)
>> just map to <bf:note>, which means that if there is to be consistent
>> note order, it much be created by the cataloguer, not left to the
>> machine.
>>     __       __   J. McRee (Mac) Elrod ([log in to unmask])
>>    {__  |   /     Special Libraries Cataloguing   HTTP://
>>    ___} |__ \__________________________________________________________
>Karen Coyle
>[log in to unmask]
>m: +1-510-435-8234
>skype: kcoylenet/+1-510-984-3600