 |
 |
It's too bad rdf:nil is only for lists -- I think it could be handy in many other contexts. But just using an empty string should be fine: <example:book1> <dc:title> _:bn1 . _:bn1 <rdf:type> <content:ContentAsText> . _:bn1 <content:characterEncoding> "UTF-8" . _:bn1 <content:chars> "" . I'm not sure I got much from that "Problems of the RDF model" piece, other than the fact that literals aren't URIs, and they lack many of the convenient properties of URIs. I suppose there is a nuanced semantic argument about the value being different from the thing itself. That distinction doesn't seem that practically important to me. There are certainly some places where documents with RDF(a) markup would be a lot more convenient than trying to put everything in triples. That can lead to something like the companion ContentAsXML element (and the general idea of putting markup in a literal), which usually seems like a bad fit to me. -Esme -- Esme Cowles <[log in to unmask]> "Necessity is the plea for every infringement of human freedom. It is the argument of tyrants; it is the creed of slaves." -- William Pitt, 1783 On 09/14/2013, at 2:22 PM, Karen Coyle <[log in to unmask]> wrote: > This mentions empty strings but doesn't give an example of one: > > *Lexical Space.* An rdf:PlainLiteral lexical form is a string of the form "/abc/@/langTag/" where "/abc/" is an arbitrary (possibly empty) string, and "/langTag/" is either the empty string or a (not necessarily lowercase) language tag. Each such lexical form is mapped to a data value dv as follows: > > * If "/langTag/" is empty, then dv is equal to the string "/abc/" and > * If "/langTag/" is not empty, then dv is equal to the pair <"/abc/", > "/lc-langtag/" > where "/lc-langtag/" is "/langTag/" normalized to > lowercase. > > [http://www.w3.org/TR/rdf-plain-literal/] > > I'm assuming it would be "". Do you think that works? > > rdf:nil seems to be only for lists. > "5.2.4 rdf:nil > > The resource |rdf:nil| is an instance of |rdf:List <http://www.w3.org/TR/rdf-schema/#ch_list>| that can be used to represent an empty list or other list-like structure." > > [http://www.w3.org/TR/rdf-schema/#ch_nil] > > And I think I might be further along in this thinking if I could understand this discussion: > http://milicicvuk.com/blog/2011/07/16/problems-of-the-rdf-model-literals/ > > The fact that much of library data consists of literals is an issue, and I don't (yet) understand what that means in terms of RDF. Sometimes I think that we should be treating our bibliographic descriptions as documents with RDF/RDFa markup where appropriate, rather than pretending that all of these strings are data. Sometimes I don't think that. ;-) > > kc > > > On 9/14/13 9:06 AM, Esmé Cowles wrote: >> Yes, I was thinking you would create a content as text node, and just leave the value blank (or maybe use something like rdf:nil). >> >> And the good thing about qnames is that you can use whatever you want. I always use "mads:" instead of "madsrdf:" for MADS, and would use "cat:" or "content:" for content as text. >> >> -Esme >> -- >> Esme Cowles <[log in to unmask]> >> >> "Necessity is the plea for every infringement of human freedom. It is the >> argument of tyrants; it is the creed of slaves." -- William Pitt, 1783 >> >> On 09/14/2013, at 10:27 AM, Karen Coyle <[log in to unmask]> wrote: >> >>> Hmm. For the missing title would you create a content as text node with a blank body? How does RDF handle empty strings?! >>> >>> (And I'm sorry to say that the qname for content as text is "cnt" - I'm going to have to just get over the dis-ease that causes me ) >>> >>> kc >>> >>> On 9/14/13 6:47 AM, Esmé Cowles wrote: >>>> That looks like a nice way to handle many different cases where you have a textual value, and may also want to attach other triples about certainty, source, definiteness, etc. This would neatly handle the missing or definitely non-existent title problem. And it also avoids sub-optimal approaches like reification or having to create a new class for every possible value that you might want to annotate. >>>> >>>> -Esme >>>> -- >>>> Esme Cowles <[log in to unmask]> >>>> >>>> "Necessity is the plea for every infringement of human freedom. It is the >>>> argument of tyrants; it is the creed of slaves." -- William Pitt, 1783 >>>> >>>> On 09/14/2013, at 9:02 AM, Karen Coyle <[log in to unmask]> wrote: >>>> >>>>> This reminds me of a conversation (that did not come to a conclusion) on the BIBFRAME list about the need to have a way to say that a bit of data is transcribed, not transcribed, or supplied. And that reminds me of the issues with SKOS labels, which is that if your data is text, not a URI, you can't say anything further about that because text cannot be the subject of a triple. And this was also the issue between BIBFRAME and Open Annotation because BIBFRAME wanted to have annotations that are plain text, and Open Annotation doesn't allow that for the reason that you can't further describe the text. >>>>> >>>>> Which leads me to conclude that we would need to be using Content as Text >>>>> http://www.w3.org/TR/Content-in-RDF10/#ContentAsTextClass >>>>> >>>>> kc >>>>> >>>>> >>>>> On 9/13/13 8:57 AM, Stephen Hearn wrote: >>>>>> The MARC21 Authority format does have some negative assertions. Field 675 >>>>>> asserts that a source contains no relevant information (vs. 670 which >>>>>> asserts the source and its relevant information). Field 673 asserts that a >>>>>> title is not related to the entity in the 1XX (vs. 672 which asserts that >>>>>> the two are related). These aren't yet mapped in any detail to RDF or to >>>>>> MADS, but finding a way to map them could be a practical approach the >>>>>> question of negative assertions. >>>>>> >>>>>> Stephen >>>>>> >>>>>> >>>>>> On Fri, Sep 13, 2013 at 9:12 AM, Karen Coyle <[log in to unmask]> wrote: >>>>>> >>>>>>> On 9/13/13 5:51 AM, Esmé Cowles wrote: >>>>>>> >>>>>>>> Thomas- >>>>>>>> >>>>>>>> This isn't something I've run across yet. But one thing you could do is >>>>>>>> create some URIs for different kinds of unknown/nonexistent titles: >>>>>>>> >>>>>>>> example:book1 dc:title example:unknownTitle >>>>>>>> example:book2 dc:title example:noTitle >>>>>>>> etc. >>>>>>>> >>>>>>> I'm bothered by the semantics of this... but maybe I'm being too rigid. >>>>>>> This states that the title is a URI, not a string, and that the URI is a >>>>>>> status, not the actual title. Your system will have a mixture of literal >>>>>>> strings that ARE titles and URIs that say something about titles, both as >>>>>>> objects of dc:title. The object of DC title needs to be the title. The >>>>>>> title COULD be a URI if the URI represents the title (e.g. a uniform title >>>>>>> in an authority file). >>>>>>> >>>>>>> Even if this turns out to be "legal" from an RDF point of view, it seems >>>>>>> that this would complicate title displays because you'd have to treat these >>>>>>> URIs differently from the usual title literals, which you could just grab >>>>>>> and toss into a display. >>>>>>> >>>>>>> I'd probably leave title as the literal string, and create a new property >>>>>>> for title status that takes its value from a controlled list. In fact, >>>>>>> wouldn't we need something almost identical for anonymous works, to say >>>>>>> that there really isn't an author. (Cataloging knowledge lapse: we quit >>>>>>> using "Anonymous" as an author a while ago, right?) Given the open world >>>>>>> assumption, we are going to need to make these kinds of negative statements. >>>>>>> >>>>>>> Also, remember that OWL does NOT constrain your data, it constrains only >>>>>>> the inferences that you can make about your data. OWL operates at the >>>>>>> ontology level, not the data level. (The OWL 2 documentation makes this >>>>>>> more clear, in my reading of it. I agree that the example you cite sure >>>>>>> looks like a constraint on the data... it's very confusing.) >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> This book has no title: >>>>>>>> example:thisbook dc:title hasobject:false . >>>>>>>> >>>>>>> I don't think the title itself can be "hasobject:false". I think you need >>>>>>> to have a property like: xx:hasATitle and this can be true or false. But >>>>>>> I'm going to run this by the folks who developed dc in RDF and see what >>>>>>> they say. [Did so, they concur = value of title must be a title, not >>>>>>> information about title or status of title.] >>>>>>> >>>>>>> Note that dcterms title is defined specifically as having a literal value: >>>>>>> >>>>>>> Term Name: title >>>>>>> URI: http://purl.org/dc/terms/title >>>>>>> Label: Title >>>>>>> Definition: A name given to the resource. >>>>>>> Type of Term: Property <http://www.w3.org/1999/02/22-** >>>>>>> rdf-syntax-ns#Property<http://www.w3.org/1999/02/22-rdf-syntax-ns#Property> >>>>>>> Refines: http://purl.org/dc/elements/1.**1/title<http://purl.org/dc/elements/1.1/title> >>>>>>> Version: http://dublincore.org/usage/**terms/history/#titleT-002<http://dublincore.org/usage/terms/history/#titleT-002> >>>>>>> Has Range: http://www.w3.org/2000/01/rdf-**schema#Literal<http://www.w3.org/2000/01/rdf-schema#Literal> >>>>>>> >>>>>>> >>>>>>> Whereas dc 1.1 (the old 15 element set) is more open: >>>>>>> >>>>>>> URI: http://purl.org/dc/elements/1.**1/title<http://purl.org/dc/elements/1.1/title> >>>>>>> Label: Title >>>>>>> Definition: A name given to the resource. >>>>>>> Type of Term: Property <http://www.w3.org/1999/02/22-** >>>>>>> rdf-syntax-ns#Property<http://www.w3.org/1999/02/22-rdf-syntax-ns#Property> >>>>>>> Version: http://dublincore.org/usage/**terms/history/#title-006<http://dublincore.org/usage/terms/history/#title-006> >>>>>>> Note: A second property with the same name as this property has been >>>>>>> declared in the dcterms: namespace (http://purl.org/dc/terms/). See the >>>>>>> Introduction to the document "DCMI Metadata Terms" (http://dublincore.org/ >>>>>>> **documents/dcmi-terms/ <http://dublincore.org/documents/dcmi-terms/>) >>>>>>> for an explanation. >>>>>>> >>>>>>> >>>>>>> I still think you are going outside of the definition of dc:title, which >>>>>>> is "The name of the resource." UNLESS you treat your "no title" as the >>>>>>> actual name of the resource, like "untitled" as the title of a painting. >>>>>>> But then we do have a serial with the actual title "Title varies" ... ;-) >>>>>>> >>>>>>> kc >>>>>>> >>>>>>> >>>>>>> >>>>>>>> It is unknown if this book has a title (sounds undesirable but I can >>>>>>>> think of instances where it might be handy[2]): >>>>>>>> example:thisbook dc:title hasobject:unknown . >>>>>>>> >>>>>>>> This book has a title but it has not been specified: >>>>>>>> example:thisbook dc:title hasobject:true . >>>>>>>> >>>>>>>> In terms of cataloguing, the answer is perhaps to refer to the rules >>>>>>>> (which would normally mandate supplied titles in square brackets and so >>>>>>>> forth) rather than use RDF to express this kind of thing, although the >>>>>>>> rules differ depending on the part of description and, in the case of the >>>>>>>> kind of thing that prompted the question- the presence of clasps on rare >>>>>>>> books- there are no rules. I wonder if anyone has any more wisdom on this. >>>>>>>> >>>>>>>> Many thanks, >>>>>>>> >>>>>>>> Tom >>>>>>>> >>>>>>>> [1] Adapted from http://www.w3.org/2007/OWL/** >>>>>>>> wiki/Primer#Object_Properties<http://www.w3.org/2007/OWL/wiki/Primer#Object_Properties> >>>>>>>> [2] No many tbh, but e.g. title in an unknown script or indecipherable >>>>>>>> hand. >>>>>>>> >>>>>>>> --- >>>>>>>> >>>>>>>> Thomas Meehan >>>>>>>> Head of Current Cataloguing >>>>>>>> Library Services >>>>>>>> University College London >>>>>>>> Gower Street >>>>>>>> London WC1E 6BT >>>>>>>> >>>>>>>> [log in to unmask] >>>>>>>> >>>>>>> -- >>>>>>> Karen Coyle >>>>>>> [log in to unmask] http://kcoyle.net >>>>>>> ph: 1-510-540-7596 >>>>>>> m: 1-510-435-8234 >>>>>>> skype: kcoylenet >>>>>>> >>>>>> >>>>> -- >>>>> Karen Coyle >>>>> [log in to unmask] http://kcoyle.net >>>>> m: 1-510-435-8234 >>>>> skype: kcoylenet >>>> >>> -- >>> Karen Coyle >>> [log in to unmask] http://kcoyle.net >>> m: 1-510-435-8234 >>> skype: kcoylenet > > -- > Karen Coyle > [log in to unmask] http://kcoyle.net > m: 1-510-435-8234 > skype: kcoylenet