Add basic dcterms:conformsTo example

[mattgarrish]

One question I had is that there was already an example of dc:subject but the note before the example incorrectly suggested dc maps to dcterms.

Did we actually want to include a dc element set example, or is my correcting the prefix to dcterms fine?

---

Preview | Diff

[llemeurfr]

Both "dc:" and "dcterms:" are defined in the context doc of schema.org. Therefore it seems correct to find a dc:subject in a manifest.

EPUB specifies the use of "dc:" elements;
many Pub Manifests will be a translation of EPUB metadata;
most people know only about the 15 original DC elements, with this "dc:" prefix;
Therefore I wonder if describing only the use of "dcterms:" in the spec is a good move.

Or is the use of "dcterms:" over "dc:" recommended in json-ld for some RDF purity reason?

[iherman]

Indeed, schema.org includes both dc: and dcterms:. I tend to agree with @llemeurfr about the community still using dc:. Although, afaik, DCMI prefers users to use dcterms: I am not sure we have to make this decision in our spec. Leaving it open might be better.

Which means that:

• the note should include a reference to both dc: and dcterms: (suggesting that the decision is not ours)
• leave the first example using dc:subject
• the second example, however, must be dcterms:conformsTo, because that term is not defined in dc:. Which is actually good because we would then have an example for both vocabularies in our spec.

[mattgarrish]

Although, afaik, DCMI prefers users to use dcterms: I am not sure we have to make this decision in our spec.

Yes, but do we really need to get into this in the specification by introducing both when all we're aiming to do is show that other properties can be used. As in #57, if there's a need for the dc element set, it can be documented elsewhere.

EPUB banned the dc: prefix for properties since the restrictions on the elements wouldn't extend to the properties. Do the elements transform forward to dc or dcterms properties... we don't even know. Do they get treated equivalently, does one set take priority?

Given that dcterms exists for linked data, I'm perfectly fine having it as the only example prefix.

[iherman]

To very honest, I don't have strong feeling about this. I see that there is a similar discussion on the epub repo; I am perfectly fine aligning ourselves on Epub.

[llemeurfr]

Well, I can only say that reading dcterms:subject - even if technically ok - seems odd to me. I may be the only one.

nb: In the current DCMI spec I don't clearly see a preference for properties from the dcterms namespace; I agree with Matt that the presence of both dc:subject and dcterms:subjectin DCMI without assertion about their equivalence is odd.

[mattgarrish]

Could we maybe avoid this issue entirely and use some other prefix example?

What about using a bibo: example and drop the dc:subject one?

I don't have a preference for dcterms over dc so much as I'm just hoping to avoid this whole two DC vocabulary issue.

[tcole3]

As defined in schema.org's context doc, the dc:: prefix is tied to the (legacy) 2001 Dublin Core 1.1 elements namespace (http://purl.org/dc/elements/1.1/) while the dcterms: prefix is tied to the 'living' Dublin Core terms namespace (http://purl.org/dc/terms/). This is the convention generally followed by the library community. There have been no changes (no new elements, no changes in definitions) in the dc: namespace since 2001, while there have been many changes and updates to the dcterms: namespace over the last 2 decades.

Also, as used in the context of the Open Archives (OAI-PMH) and other legacy XML applications using Dublin Core, the practice has been that properties in the dc: namespace cannot have any children (e.g., so can't break name into family and surname) and do not have any sub-properties or attributes, while more flexibility is assumed for properties in the dcterms: namespace.

The latter are legacy conventions of course and not ones we (or schema) necessarily have to follow when serializing in json-ld, but I think it would occasion less confusion overall if we stuck exclusively in our examples to dcterms: and avoided any examples making use of dc:. The dc: 1.1 elements namespace is outdated and is generally seen in the library domain as not the best choice for Dublin Core in LD.

And though I personally could live with @mattgarrish's suggestion to avoid dc:/dcterms: by using bibo: for our examples, among US libraries at least, I think many would find a bibo: example more confusing then a dcterms: example.

Understanding that there will always be a few folks who prefer the fixity of dc:...

[tcole3]

And technically, dcterms:subject is a refinement of dc:subject, see: https://www.dublincore.org/specifications/dublin-core/dcmi-terms/#terms-subject rather than being exactly equivalent...

[mattgarrish]

I think many would find a bibo: example more confusing then a dcterms: example.

@tcole3 I'm not suggesting we use bibo: for examples anywhere else in the specification, just to be clear. These specific examples are in the section on how to extend the manifest using prefixes from the schema.org context file. I don't know that we need two examples of dublin core there, especially, as you say, if dcterms: is the preferred vocabulary to use.

Let's keep the new example of dcterms:conformsTo, since there's some desire to show this for versioning, not just as a prefix example. But let's add a second example that says here's how you could use X to add some other property, where X can be any other prefix than dc: (it could be foaf if that's more palatable; I just threw bibo out as it sometimes comes up).

[iherman]

Using dcterms for conforms to seems to be necessary, and is in the document due to #16. Seeing the discussion maybe the best is to keep to Matt's original proposal and use, in the examples dcterms only.

Maybe it is worth, in the note referring to schema.org, citing more of the namespaces that are predefined, like bibo, foaf, and indeed dc.

[mattgarrish]

Maybe it is worth, in the note referring to schema.org, citing more of the namespaces that are predefined

Works for me.

[mattgarrish]

I've updated the note to add more of the vocabularies.

I also noticed that we don't actually show an example of extending the context. I put in a fictitious example, but maybe someone can think of something better. Let me know if I didn't get the prefix declaration right, too.

[iherman]

Ship it:-)