Issues in the current draft
Issue 1: Datatypes
Can we support ex:prop --> "blabla"^^ex:datatype ?
Problem
Using RDF datatypes on value strings (=SES) is unproblematic. However, using datatyped literals as values of DCAM properties is more challenging. The DCAM allows several value strings for a single statement. Using an RDF datatype would make that impossible. Related descriptions and rich values representations would also be impossible.
On the other hand, literal values is actually a perfect representation of a value, are very handy, and should therefore be supported if possible.
The same situation arises when plain literals are used, for example for dc:title.
Solutions
-
Disallow literal values
-
Allow literal values if certain specific criteria are met.
Proposal
When:
-
The VES is an rdfs:Datatype or equals rdfs:Literal.
-
There is only one value string
-
There is no language tag on the value string
-
The SES of the value string is a subClass or equals the VES of the value.
-
There are no rich value representations
-
There are no related descriptions.
a datatyped literal or plain literal can be used.
Plain literals correspond to VES=SES=rdfs:Literal.
Issue 2: Value string property
Problem
Which property should be used for denoting value strings?
Solutions
-
rdf:value "<rdfs:comment>Idiomatic property used for structured values.</rdfs:comment>"
-
rdfs:label "<rdfs:comment>A human-readable name for the subject.</rdfs:comment>"
-
dcrdf:valueString (or similar)
-
others?
Proposal
The definition of rdfs:label does not really fit. rdf:value is better, albeit maybe too idiomatic...
A sub-property dcrdf:valueString of rdf:value with rdfs:Literal range and improved definition seems the best solution.
Issue 3: Vocabulary encoding schemes should not be classes
See ![[Self]](/wiki/dcmi/img/moin-inter.png){kind=small}
DCAM Issues.
Proposal
This is not an DCRDF issue, but a DCAM issue, as the DCAM is 100% clear on that VES=Class.
"VES" should possibly be renamed "Value class" or similar.
Issue 4: Rich representations?
It's at this point very unclear what to do about rich representations. Do we use the same property as for value strings, but with a different value type? Or do we use a separate property?
Proposal
Use rdfs:seeAlso. Mention explicitly the use of XMLLiteral, otherwise recommend use of URI ref to separate resource.
Issue 5: Related descriptions
How do we implement related descriptions?
Proposal
-
Blank nodes within same RDF doc: no property necessary, RDF handles the case.
-
URI ref to external description. Works when Value URI is used. Property needed, range is
dcrdf:Description or similar.
Property proposal: dcrdf:relatedDescription? Sub-property of dc:relation ... ?
Editorial issues
Editorial issue 1: dc:identifier
I'm thinking that we need to state somewhere that
<http://example.org> dc:identifier <doi:blabla>
is *not* the right way to do it (that form is used in DCQ/RDF). Instead, I think we all agree that
<http://example.org> dc:identifier "doi:blabla"^^<dcterms:URI>
or similar is right. How and where do we best say this?