Is `dct:references` necessary to index Subjects in a Document?


#1

I noticed that when Markbook adds a new Subject representing a Bookmark, it also adds a link to that Subject from the Document itself using dct:references. So far when developing apps, I haven’t done that - I’ve just added my Subjects directly, depending on their presence in the Document being sufficient for identifying them as part of it. So my question is: should I be adding dct:references as well, and what happens if I don’t?


#2

I think there are four ways to ‘step through’ the web of data:

  • from thing to thing (e.g. follow a triple from subject to object)
  • from thing to document (i.e. dereference)
  • from document to document (looking at containment triples, or truncating the URL at a slash)
  • from document to thing (i.e. the thing is mentioned in the document)

Another way to look at it is to say only the first way is really valid, and then you only ever point the cursor at a thing, not a a document, so then you do need something like dct:references, in order to step from the document-as-a-thing to a thing that is mentioned in that doc.

So both views would make sense. In other words, I don’t know. :slight_smile:


#3

It depends :smile: important is that all data can be discovered by links (follow your nose).

Regarding Bookmarks and in general all stuff that is discovered by using the type index, the “problem” is that the type registy refers to documents. So as @michielbdejong already stated correctly, we need to move from document to thing, and that is where dct:references comes in handy.

But if you can navigate from thing to thing it should not be necessary. This is e.g. the case for my talks. You can navigate from my WebID via schema:performerIn to events and from there follow your nose down to slide files. No dct:references involved whole way.


#4

Ah I see, it should be reachable by following links. Is there a reason the server shouldn’t add those automatically, just like it adds an ldp:contains to a Container for things inside it - or is that implementation-specific behaviour?


#5

Might be a good idea. Never thought that through