Should versions be namespaces?

[jpstroop]

http://www.loc.gov/standards/mads/rdf/v1.rdf
http://www.loc.gov/standards/mods/modsrdf/v1/modsrdf.owl
http://www.loc.gov/premis/rdf/v1.rdf

All have v1 in them (but not http://id.loc.gov/vocabulary/preservation/eventType/, because LC). What happens when v+=1? Everyone is not like to migrate at the same time and may even want to rely on this gem to supply multiple versions.

[jpstroop]

To finish the thought...should it be, e.g. RDF::MADS::V1 < RDF::StrictVocabulary?

[dchandekstark]

I'm OK with namespacing as you suggest. Can we get another couple +1's? @acoburn @awead @mjgiarlo

[dchandekstark]

We need to be careful about what version we are using -- the version of the vocab itself, or the version of the ontology document, which may be different (cf. PREMIS).

[dchandekstark]

We might also need something like RDF::MADS::LATEST to map to the latest version? Then we could have ugly but accurate version numbers like RDF::PREMIS::V2_2_1.

[acoburn]

+1 I would be in favor of namespacing the version

[jpstroop]

+1 to ...::LATEST. Also, very good point about the version of the ontology vs. the version of the vocab. I think mirroring the version of the ontology (the .owl or .rdf file) makes more sense, since that's what the class is derived from.

[dchandekstark]

@jpstroop I take your point about the version mirroring the ontology doc, although I think we would need to make this an explicit and consistent practice -- i.e., only use versions in the class names to refer to the version of the source document from which the RDF vocab class is derived. /cc @acoburn

[dchandekstark]

Here's an interesting alternative. Ruby allow defining a method (private on Object) with the same name as a class (cf. Array and Array()). So, we could do something like this:

RDF::MODS("V1") => RDF::MODS::V1
RDF::MODS() => latest version

[jpstroop]

RDF::MODS::V1 would still exist, RDF::MODS("V1") would just be a convenience for getting at it, correct?

[dchandekstark]

Yeah, although now I kind of want to retract the idea. Maybe we should just start simple and direct. We can revisit it later if we're not happy.

[jpstroop]

Either way. If you did need to parameterize the version, I guess that would be a nice convenience, but not tough to add at any point either.

[acoburn]

So, are you thinking that (at present) an implementing class could be written like this:

property :title, predicate: RDF::MODS::V1.titlePrincipal, class_name: "Title"

class Title < ActiveTriples::Resource
      configure type: RDF::MADS::V1.Title
      property :label, predicate: RDF::RDFS.label
      property :list, predicate: RDF::MADS::V1.elementList, class_name: "ElementList"
end

or like this:

property :title, predicate: RDF::MODS.titlePrincipal, class_name: "Title"

class Title < ActiveTriples::Resource
      configure type: RDF::MADS.Title
      property :label, predicate: RDF::RDFS.label
      property :list, predicate: RDF::MADS.elementList, class_name: "ElementList"
end

and have the same meaning?

[jpstroop]

Would e.g. MODS need to be pinned to particular versions of MADS to avoid implying latest?

[dchandekstark]

@acoburn I'm not sure offhand how to do exactly what you described (i.e., RDF::MODS is not the same as RDF::MODS() -- in this case for Ruby the empty parens would matter). In any case, we may be somewhat conflating usage with code structure. For usage, perhaps a decent pattern would be:

MADS = RDF::MADS::V1

class Title < ActiveTriples::Resource
  configure type: MADS.Title
end

@jpstroop I'm not sure how to answer your question ...

How about we begin by being explicit -- i.e., don't use implicit "latest" -- unless/until we can get more input/clarity on that? So, we would have RDF::MODS::V1 and RDF::MODS::LATEST (=>V1 initially).

[dchandekstark]

For the moment I think we reached a lazy consensus that we would namespace versions.