Re: [CODE4LIB] Expressing negatives and similar in RDF

[Jeremy Nelson]

Hi Karen,
Thanks for the link. I have to admit a certain ignorance about using SPARQL 
over triple-stores although I've started researching how to provide a SPARQL 
end-point to the Redis Library Services Platform. So more to the topic in this 
email thread, in the Redis bibliographic datastore my approach has been to use 
the data structures themselves to provide primitive validations on the saved 
graph of the entity using the full range of Redis datastore primitives and 
commands. These same data structures and Redis commands are also used in 
end-user interface, json linked data feeds, and soon directly to RDF. I would 
be very interested in how to better express an entity's implicit negative 
relationships in Redis. 

Jeremy

-Original Message-
From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of Karen 
Coyle
Sent: Monday, September 23, 2013 6:11 PM
To: CODE4LIB@LISTSERV.ND.EDU
Subject: Re: [CODE4LIB] Expressing negatives and similar in RDF

Jeremy,

This is the kind of thing that people are doing with SPARQL, and I think the 
principle is the same although the technology is different. SPARQL has ways to 
do negation in a query:
   http://www.w3.org/TR/sparql11-query/#negation

The difference between that and stating that something positively does not 
exist is that the query result tells you whether or not it exists in whatever 
universe you are querying, and the original post was about positively stating 
that something does NOT exist in the real world resource, not that it does not 
exist in that set of data. And that's where the "purely monotonic and described 
in terms of positive inference rules" gets in the way. So in RDF you have true 
and unknown, but it's not easy to get a hard "false." That said, many of the 
validation techniques that were demonstrated at the W3C workshop were run on 
closed systems, so a strict RDF "unknown" could be interpreted for all intents 
and purposes as "false." But I don't recall anyone having suggested a way to 
state non-existence at the time of metadata creation.

kc


||
On 9/23/13 3:48 PM, Jeremy Nelson wrote:
> Just a quick follow-up to Steve's email. For the bibliographic datastore 
> (https://github.com/jermnelson/redis-library-services-platform) I've been 
> developing using Redis, we are able to use Redis commands to distinguish 
> between these three states (True, False, Unknown/null) for an entity's 
> properties that is stored in either hash, set, or sorted set data primitives.
>
> For an entity with its properties in a Redis hash data primitive:
>
> HGET 'bf:Book:1' 'title' => Either returns a value (can be any string; 
> either a literal of URI) or null HEXISTS 'bf:Book:1' 'title' => True 
> or False Boolean
>
> In implementing the client-side programming logic to handle these three 
> states, we are able to distinguish the negative from the null value and 
> provide appropriate logic to handle each case.
>
> Jeremy Nelson
> Metadata and Systems Librarian
> Colorado College
>
>
> -Original Message-----
> From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf 
> Of Karen Coyle
> Sent: Sunday, September 22, 2013 10:14 AM
> To: CODE4LIB@LISTSERV.ND.EDU
> Subject: Re: [CODE4LIB] Expressing negatives and similar in RDF
>
> Steve, yes, you've nailed it, IMO.
>
> There's a paper from some DERI folk that addresses negations, and it's all so 
> complex that it does make one want to say: fuggetaboudit. Here's a snippet:
>
> begin snippet
>
> The semantics of RDF(S) is purely monotonic and described in terms of 
> positive inference rules, so even if Charles added instead a new 
> statement
>
> :me myfoaf:doesntknow <http://alice.exa.org/i> .
>
> he would not be able to state that statements with the property 
> myfoaf:doesntknow should single out foaf:knows statements.
>
> Tim Berners-Lee’s Notation 3 (N3) [2] provides to some extent means to 
> express what we are looking for by the ability to declare falsehood over 
> reified statements which would be written as:
>
> { :me foaf:knows <http://alice.exa.org/i> } a n3:falsehood .
>
> Nonetheless, this solution is somewhat unsatisfactory, due to the lack 
> of formal semantics for N3; N3’s operational semantics is mainly 
> defined in terms of its implementation
> cwm3 only.
>
> The falsehood of Charles knowing Alice can be expressed in OWL, however in a 
> pretty contrived way, as follows (for the sake of brevity we use DL notation 
> here, the reader might translate this to OWL syntax straightforwardly):
>
> fcharlesg 2 8foaf:knows::faliceg  [kc:this is a bunch of logical 
> symbols that don't come through w cop

Re: [CODE4LIB] Expressing negatives and similar in RDF

[Karen Coyle]

Jeremy,

This is the kind of thing that people are doing with SPARQL, and I think 
the principle is the same although the technology is different. SPARQL 
has ways to do negation in a query:

  http://www.w3.org/TR/sparql11-query/#negation

The difference between that and stating that something positively does 
not exist is that the query result tells you whether or not it exists in 
whatever universe you are querying, and the original post was about 
positively stating that something does NOT exist in the real world 
resource, not that it does not exist in that set of data. And that's 
where the "purely monotonic and described in terms of positive inference 
rules" gets in the way. So in RDF you have true and unknown, but it's 
not easy to get a hard "false." That said, many of the validation 
techniques that were demonstrated at the W3C workshop were run on closed 
systems, so a strict RDF "unknown" could be interpreted for all intents 
and purposes as "false." But I don't recall anyone having suggested a 
way to state non-existence at the time of metadata creation.


kc


||
On 9/23/13 3:48 PM, Jeremy Nelson wrote:

Just a quick follow-up to Steve's email. For the bibliographic datastore 
(https://github.com/jermnelson/redis-library-services-platform) I've been 
developing using Redis, we are able to use Redis commands to distinguish 
between these three states (True, False, Unknown/null) for an entity's 
properties that is stored in either hash, set, or sorted set data primitives.

For an entity with its properties in a Redis hash data primitive:

HGET 'bf:Book:1' 'title' => Either returns a value (can be any string; either a 
literal of URI) or null
HEXISTS 'bf:Book:1' 'title' => True or False Boolean

In implementing the client-side programming logic to handle these three states, 
we are able to distinguish the negative from the null value and provide 
appropriate logic to handle each case.

Jeremy Nelson
Metadata and Systems Librarian
Colorado College


-Original Message-
From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of Karen 
Coyle
Sent: Sunday, September 22, 2013 10:14 AM
To: CODE4LIB@LISTSERV.ND.EDU
Subject: Re: [CODE4LIB] Expressing negatives and similar in RDF

Steve, yes, you've nailed it, IMO.

There's a paper from some DERI folk that addresses negations, and it's all so 
complex that it does make one want to say: fuggetaboudit. Here's a snippet:

begin snippet

The semantics of RDF(S) is purely monotonic and described in terms of positive 
inference rules, so even if Charles added instead a new statement

:me myfoaf:doesntknow <http://alice.exa.org/i> .

he would not be able to state that statements with the property 
myfoaf:doesntknow should single out foaf:knows statements.

Tim Berners-Lee’s Notation 3 (N3) [2] provides to some extent means to express 
what we are looking for by the ability to declare falsehood over reified 
statements which would be written as:

{ :me foaf:knows <http://alice.exa.org/i> } a n3:falsehood .

Nonetheless, this solution is somewhat unsatisfactory, due to the lack of 
formal semantics for N3; N3’s operational semantics is mainly defined in terms 
of its implementation
cwm3 only.

The falsehood of Charles knowing Alice can be expressed in OWL, however in a 
pretty contrived way, as follows (for the sake of brevity we use DL notation 
here, the reader might translate this to OWL syntax straightforwardly):

fcharlesg 2 8foaf:knows::faliceg  [kc:this is a bunch of logical symbols that 
don't come through w copy/paste]

Reasoning with such statements firstly involves OWL reasoning with nominals, 
which most DL reasoners are not particularly good at, and secondly does not buy 
us too much, as the simple merge of this DL statement with the information in 
Bob’s FOAF file would just generate a contradiction, invalidating all, even the 
useful answers. Para-consistent reasoning on top of OWL, such as for instance 
proposed in [9] and related approaches, solve this problem of classical 
inference, but still requiring full OWL DL reasoning.

***end snippet

Anyway, for one's reading pleasure:

http://ftp.informatik.rwth-aachen.de/Publications/CEUR-WS/Vol-314/55.pdf

I suspect this is something like validation that will come up in some STEM 
communities in areas where they really must solve it, and therefore there will 
be folks working on a solution. i'm happy to leave it to others, personally. 
It's way over my head.

kc



On 9/22/13 7:05 AM, Steve Meyer wrote:

Isn't the issue here that it is very hard to break from the object/property
model into an RDF/assertion model [1]? It seems to me that the rare book
cataloger's assertion:

"This book does not have a title"

only looks like it should translate to

example:book1 dc:title 

Re: [CODE4LIB] Expressing negatives and similar in RDF

[Jeremy Nelson]

Just a quick follow-up to Steve's email. For the bibliographic datastore 
(https://github.com/jermnelson/redis-library-services-platform) I've been 
developing using Redis, we are able to use Redis commands to distinguish 
between these three states (True, False, Unknown/null) for an entity's 
properties that is stored in either hash, set, or sorted set data primitives.

For an entity with its properties in a Redis hash data primitive:

HGET 'bf:Book:1' 'title' => Either returns a value (can be any string; either a 
literal of URI) or null
HEXISTS 'bf:Book:1' 'title' => True or False Boolean

In implementing the client-side programming logic to handle these three states, 
we are able to distinguish the negative from the null value and provide 
appropriate logic to handle each case.

Jeremy Nelson
Metadata and Systems Librarian
Colorado College


-Original Message-
From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of Karen 
Coyle
Sent: Sunday, September 22, 2013 10:14 AM
To: CODE4LIB@LISTSERV.ND.EDU
Subject: Re: [CODE4LIB] Expressing negatives and similar in RDF

Steve, yes, you've nailed it, IMO.

There's a paper from some DERI folk that addresses negations, and it's all so 
complex that it does make one want to say: fuggetaboudit. Here's a snippet:

begin snippet

The semantics of RDF(S) is purely monotonic and described in terms of positive 
inference rules, so even if Charles added instead a new statement

:me myfoaf:doesntknow <http://alice.exa.org/i> .

he would not be able to state that statements with the property 
myfoaf:doesntknow should single out foaf:knows statements.

Tim Berners-Lee’s Notation 3 (N3) [2] provides to some extent means to express 
what we are looking for by the ability to declare falsehood over reified 
statements which would be written as:

{ :me foaf:knows <http://alice.exa.org/i> } a n3:falsehood .

Nonetheless, this solution is somewhat unsatisfactory, due to the lack of 
formal semantics for N3; N3’s operational semantics is mainly defined in terms 
of its implementation
cwm3 only.

The falsehood of Charles knowing Alice can be expressed in OWL, however in a 
pretty contrived way, as follows (for the sake of brevity we use DL notation 
here, the reader might translate this to OWL syntax straightforwardly):

fcharlesg 2 8foaf:knows::faliceg  [kc:this is a bunch of logical symbols that 
don't come through w copy/paste]

Reasoning with such statements firstly involves OWL reasoning with nominals, 
which most DL reasoners are not particularly good at, and secondly does not buy 
us too much, as the simple merge of this DL statement with the information in 
Bob’s FOAF file would just generate a contradiction, invalidating all, even the 
useful answers. Para-consistent reasoning on top of OWL, such as for instance 
proposed in [9] and related approaches, solve this problem of classical 
inference, but still requiring full OWL DL reasoning.

***end snippet

Anyway, for one's reading pleasure:

http://ftp.informatik.rwth-aachen.de/Publications/CEUR-WS/Vol-314/55.pdf

I suspect this is something like validation that will come up in some STEM 
communities in areas where they really must solve it, and therefore there will 
be folks working on a solution. i'm happy to leave it to others, personally. 
It's way over my head.

kc



On 9/22/13 7:05 AM, Steve Meyer wrote:
> Isn't the issue here that it is very hard to break from the object/property
> model into an RDF/assertion model [1]? It seems to me that the rare book
> cataloger's assertion:
>
> "This book does not have a title"
>
> only looks like it should translate to
>
> example:book1 dc:title someOntology:nil
>
> because of our familiarity with object oriented programming:
>
> BibliographicResource bib = new BibliographicResource();
> bib.getTitleStatement().getTitle(); // returns null
>
> However, does this incorrectly assign the predicate and object of the
> triple? Shouldn't it be:
>
> Subject: This book
> Predicate: does not have a
> Object: title
>
> and therefore look more like:
>
> example:book1 someOntology:lacksProperty dc:title
>
> The statement cannot be about the value of a book's title if it does not
> have one. But the rare book cataloger is not making an assertion about the
> book's title, but an assertion about the book's metadata.
>
> We seem to be mislead into thinking that null is a value because most
> programming languages use equivalence syntax as shorthand for determining
> if an object's property is set. That is, this:
>
> object.getTitle == "Semantic Web"
>
> looks a lot like this
>
> object.getTitle == null
>
> But it might be better to understand this problem in terms 

Re: [CODE4LIB] Expressing negatives and similar in RDF

[Karen Coyle]

Steve, yes, you've nailed it, IMO.

There's a paper from some DERI folk that addresses negations, and it's 
all so complex that it does make one want to say: fuggetaboudit. Here's 
a snippet:


begin snippet

The semantics of RDF(S) is purely monotonic and described in terms of 
positive

inference rules, so even if Charles added instead a new statement

:me myfoaf:doesntknow  .

he would not be able to state that statements with the property 
myfoaf:doesntknow

should single out foaf:knows statements.

Tim Berners-Lee’s Notation 3 (N3) [2] provides to some extent means to 
express what
we are looking for by the ability to declare falsehood over reified 
statements which

would be written as:

{ :me foaf:knows  } a n3:falsehood .

Nonetheless, this solution is somewhat unsatisfactory, due to the lack 
of formal semantics
for N3; N3’s operational semantics is mainly defined in terms of its 
implementation

cwm3 only.

The falsehood of Charles knowing Alice can be expressed in OWL, however 
in a pretty
contrived way, as follows (for the sake of brevity we use DL notation 
here, the reader

might translate this to OWL syntax straightforwardly):

fcharlesg 2 8foaf:knows::faliceg  [kc:this is a bunch of logical symbols 
that don't come through w copy/paste]


Reasoning with such statements firstly involves OWL reasoning with 
nominals, which
most DL reasoners are not particularly good at, and secondly does not 
buy us too much,
as the simple merge of this DL statement with the information in Bob’s 
FOAF file would
just generate a contradiction, invalidating all, even the useful 
answers. Para-consistent
reasoning on top of OWL, such as for instance proposed in [9] and 
related approaches,
solve this problem of classical inference, but still requiring full OWL 
DL reasoning.


***end snippet

Anyway, for one's reading pleasure:

http://ftp.informatik.rwth-aachen.de/Publications/CEUR-WS/Vol-314/55.pdf

I suspect this is something like validation that will come up in some 
STEM communities in areas where they really must solve it, and therefore 
there will be folks working on a solution. i'm happy to leave it to 
others, personally. It's way over my head.


kc



On 9/22/13 7:05 AM, Steve Meyer wrote:

Isn't the issue here that it is very hard to break from the object/property
model into an RDF/assertion model [1]? It seems to me that the rare book
cataloger's assertion:

"This book does not have a title"

only looks like it should translate to

example:book1 dc:title someOntology:nil

because of our familiarity with object oriented programming:

BibliographicResource bib = new BibliographicResource();
bib.getTitleStatement().getTitle(); // returns null

However, does this incorrectly assign the predicate and object of the
triple? Shouldn't it be:

Subject: This book
Predicate: does not have a
Object: title

and therefore look more like:

example:book1 someOntology:lacksProperty dc:title

The statement cannot be about the value of a book's title if it does not
have one. But the rare book cataloger is not making an assertion about the
book's title, but an assertion about the book's metadata.

We seem to be mislead into thinking that null is a value because most
programming languages use equivalence syntax as shorthand for determining
if an object's property is set. That is, this:

object.getTitle == "Semantic Web"

looks a lot like this

object.getTitle == null

But it might be better to understand this problem in terms of a set of
key/value pairs in a Hash or Map:

object.hasKey("title")

-sm

[1] "It is difficult to get a man to understand something, when his salary
depends upon his not understanding it!"


On Wed, Sep 18, 2013 at 10:58 AM, Karen Coyle  wrote:


On 9/18/13 6:25 AM, aj...@virginia.edu wrote:


-BEGIN PGP SIGNED MESSAGE

and without disagreeing with you, I would point out that if you say that
a given type of resource can have at most one dct:title (which is easy to
declare using OWL), and then apply that ontology to an instance that
features a resource of that type with two dct:titles, you're going to get
back useful information from the operation of your reasoner. An
inconsistency in your claims about the world will become apparent. I now
realize I should have been using the word "consistency" and not "validity".

I suppose what I really want to know, if you're willing to keep "playing
reporter" on the workshop you attended, is whether there was an
understanding present that people are using OWL in this way, and that it's
useful in this way (far more useful than writing and maintaining lots and
lots and lots of SPARQL) and that this is a use case for ontology languages.


The workshop was expressly on validation of data. No one reported using
"reasoners" to do validation, and one speaker talked about relying on OWL
for their validation rules (but admitted that it was all in their closed
world and was a bit apologetic abou

Re: [CODE4LIB] Expressing negatives and similar in RDF

[Steve Meyer]

Isn't the issue here that it is very hard to break from the object/property
model into an RDF/assertion model [1]? It seems to me that the rare book
cataloger's assertion:

"This book does not have a title"

only looks like it should translate to

example:book1 dc:title someOntology:nil

because of our familiarity with object oriented programming:

BibliographicResource bib = new BibliographicResource();
bib.getTitleStatement().getTitle(); // returns null

However, does this incorrectly assign the predicate and object of the
triple? Shouldn't it be:

Subject: This book
Predicate: does not have a
Object: title

and therefore look more like:

example:book1 someOntology:lacksProperty dc:title

The statement cannot be about the value of a book's title if it does not
have one. But the rare book cataloger is not making an assertion about the
book's title, but an assertion about the book's metadata.

We seem to be mislead into thinking that null is a value because most
programming languages use equivalence syntax as shorthand for determining
if an object's property is set. That is, this:

object.getTitle == "Semantic Web"

looks a lot like this

object.getTitle == null

But it might be better to understand this problem in terms of a set of
key/value pairs in a Hash or Map:

object.hasKey("title")

-sm

[1] "It is difficult to get a man to understand something, when his salary
depends upon his not understanding it!"


On Wed, Sep 18, 2013 at 10:58 AM, Karen Coyle  wrote:

> On 9/18/13 6:25 AM, aj...@virginia.edu wrote:
>
>> -BEGIN PGP SIGNED MESSAGE
>>
>> and without disagreeing with you, I would point out that if you say that
>> a given type of resource can have at most one dct:title (which is easy to
>> declare using OWL), and then apply that ontology to an instance that
>> features a resource of that type with two dct:titles, you're going to get
>> back useful information from the operation of your reasoner. An
>> inconsistency in your claims about the world will become apparent. I now
>> realize I should have been using the word "consistency" and not "validity".
>>
>> I suppose what I really want to know, if you're willing to keep "playing
>> reporter" on the workshop you attended, is whether there was an
>> understanding present that people are using OWL in this way, and that it's
>> useful in this way (far more useful than writing and maintaining lots and
>> lots and lots of SPARQL) and that this is a use case for ontology languages.
>>
>
> The workshop was expressly on validation of data. No one reported using
> "reasoners" to do validation, and one speaker talked about relying on OWL
> for their validation rules (but admitted that it was all in their closed
> world and was a bit apologetic about it). I don't have experience with
> reasoners, but one of the issues for validation using SPARQL is getting
> back specific information about what precise part of the query returned
> "false". I suspect that reasoners aren't good at returning such
> information, since that is not their purpose. I don't believe that they
> operate on a T/F basis, but now I'll start looking into them.
>
> One thing to remember about OWL is that it affects the semantics of your
> classes and properties in the open world. OWL intends to describe truths
> about a world of your design. It should affect not only your use of your
> data, but EVERYONE's use of your data in the cloud. Yet even you may have
> more than one application operating on the data, and those applications may
> have different requirements. Also, remember that the graph grows, so
> something that may be true at the moment of cataloging, for example, may
> not be true when your graph combines with other graphs. So you may say that
> there is one and only one main author to a work title, but that means one
> and only one URI. If your data combines with data from another source, and
> that source has used a different author URI, then what should happen? Each
> OWL rule makes a statement about a supposed reality, yet you may not have
> much control over that reality. Fewer rules ("least ontological
> commitment") means more possibilities for re-use and re-combining of your
> data; more rules makes it very hard for your data to play well in the world
> graph.
>
> There are cases where OWL *increases* the utility of your properties and
> classes, in particular declaring sub-class/sub-property relations. If we
> say that RDA:titleProper is a subproperty of dct:title then anyone who
> "knows" dct:title can make use of RDA:titleProper. But OWL as a way to
> *restrict* the definition of the world should be used with caution.
>
> I would like to see a discussion of what kinds of inferences we would like
> to make (or see made) of our data in the open world, and then those
> inferences should inform how we would use OWL. Do we want to infer that
> every resource has a title? Obviously not, from how this discussion
> started. How about that every resource has a known creato

Re: [CODE4LIB] Expressing negatives and similar in RDF

[Karen Coyle]

On 9/18/13 6:25 AM, aj...@virginia.edu wrote:

-BEGIN PGP SIGNED MESSAGE

and without disagreeing with you, I would point out that if you say that a given type of resource 
can have at most one dct:title (which is easy to declare using OWL), and then apply that ontology 
to an instance that features a resource of that type with two dct:titles, you're going to get back 
useful information from the operation of your reasoner. An inconsistency in your claims about the 
world will become apparent. I now realize I should have been using the word "consistency" 
and not "validity".

I suppose what I really want to know, if you're willing to keep "playing 
reporter" on the workshop you attended, is whether there was an understanding 
present that people are using OWL in this way, and that it's useful in this way (far more 
useful than writing and maintaining lots and lots and lots of SPARQL) and that this is a 
use case for ontology languages.


The workshop was expressly on validation of data. No one reported using 
"reasoners" to do validation, and one speaker talked about relying on 
OWL for their validation rules (but admitted that it was all in their 
closed world and was a bit apologetic about it). I don't have experience 
with reasoners, but one of the issues for validation using SPARQL is 
getting back specific information about what precise part of the query 
returned "false". I suspect that reasoners aren't good at returning such 
information, since that is not their purpose. I don't believe that they 
operate on a T/F basis, but now I'll start looking into them.


One thing to remember about OWL is that it affects the semantics of your 
classes and properties in the open world. OWL intends to describe truths 
about a world of your design. It should affect not only your use of your 
data, but EVERYONE's use of your data in the cloud. Yet even you may 
have more than one application operating on the data, and those 
applications may have different requirements. Also, remember that the 
graph grows, so something that may be true at the moment of cataloging, 
for example, may not be true when your graph combines with other graphs. 
So you may say that there is one and only one main author to a work 
title, but that means one and only one URI. If your data combines with 
data from another source, and that source has used a different author 
URI, then what should happen? Each OWL rule makes a statement about a 
supposed reality, yet you may not have much control over that reality. 
Fewer rules ("least ontological commitment") means more possibilities 
for re-use and re-combining of your data; more rules makes it very hard 
for your data to play well in the world graph.


There are cases where OWL *increases* the utility of your properties and 
classes, in particular declaring sub-class/sub-property relations. If we 
say that RDA:titleProper is a subproperty of dct:title then anyone who 
"knows" dct:title can make use of RDA:titleProper. But OWL as a way to 
*restrict* the definition of the world should be used with caution.


I would like to see a discussion of what kinds of inferences we would 
like to make (or see made) of our data in the open world, and then those 
inferences should inform how we would use OWL. Do we want to infer that 
every resource has a title? Obviously not, from how this discussion 
started. How about that every resource has a known creator? (Not) Do we 
want to limit the number of titles or creators of a resource in the 
world graph? The number of identities they can have? Does it make sense 
to say that a FRBR:Work can have an "adaptationOf" relationship *only* 
with another FRBR:Work (when no one except libraries  is defining their 
resources in terms of FRBR:Work)?


On the other hand, if two resources have the same title and the same 
date, are they the same resource? (maybe, maybe not).


Oops. gotta run. I'm going to try to pull all of this together into 
something more coherent.


Thanks,
kc




- ---
A. Soroka
The University of Virginia Library

On Sep 17, 2013, at 11:00 PM, CODE4LIB automatic digest system wrote:


From: Karen Coyle 
Date: September 17, 2013 12:54:33 PM EDT
Subject: Re: Expressing negatives and similar in RDF


Agreed that SPARQL is ugly, and there was  discussion at the RDF validation 
workshop about the need for friendly interfaces that then create the 
appropriate SPARQL queries in the background. This shouldn't be surprising, 
since most business systems do not require users to write raw SQL or even 
anything resembling code - often users fill in a form with data that is turned 
into code.

But it really is a mistake to see OWL as a constraint language in the sense of 
validation. An ontology cannot constrain; OWL is solely *descriptive* not 
*prescriptive.* [1]

Inferencing is very different from validation, and this is an area where the 
initial RDF documentation was (IMO) quite unclear. The OWL 2 documents are 
better, but everyone admits tha

Re: [CODE4LIB] Expressing negatives and similar in RDF

[aj...@virginia.edu]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I appreciate the time you're taking to unpack this point. I agree that it's 
subtle and important.

Speaking of prescription and description, I suspect that we're "talking past 
each other" along those lines. I understand you to be expositing the prescribed 
use of OWL, and I'm describing one of the uses to which I see it being put 
today. I also suspect that I've been making this more difficult by using 
language loosely. When I used the word "validation", I didn't mean simply the 
functionality of accepting or rejecting an instance based on a set of rules, 
especially not on syntactic grounds. I meant the discovery of inconsistencies. 
For example, you say:

>> If you say that every resource MUST have a dct:title, then if you come 
>> across a resource without a dct:title that is NOT wrong. The reasoner would 
>> conclude that there is a dct:title somewhere because that's the rule.  (This 
>> is where the Open World comes in) When data contradicts reasoners, they 
>> can't work correctly, but they act on existing data, they do not modify or 
>> correct data.

and without disagreeing with you, I would point out that if you say that a 
given type of resource can have at most one dct:title (which is easy to declare 
using OWL), and then apply that ontology to an instance that features a 
resource of that type with two dct:titles, you're going to get back useful 
information from the operation of your reasoner. An inconsistency in your 
claims about the world will become apparent. I now realize I should have been 
using the word "consistency" and not "validity".

I suppose what I really want to know, if you're willing to keep "playing 
reporter" on the workshop you attended, is whether there was an understanding 
present that people are using OWL in this way, and that it's useful in this way 
(far more useful than writing and maintaining lots and lots and lots of SPARQL) 
and that this is a use case for ontology languages. 

- ---
A. Soroka
The University of Virginia Library

On Sep 17, 2013, at 11:00 PM, CODE4LIB automatic digest system wrote:

> From: Karen Coyle 
> Date: September 17, 2013 12:54:33 PM EDT
> Subject: Re: Expressing negatives and similar in RDF
> 
> 
> Agreed that SPARQL is ugly, and there was  discussion at the RDF validation 
> workshop about the need for friendly interfaces that then create the 
> appropriate SPARQL queries in the background. This shouldn't be surprising, 
> since most business systems do not require users to write raw SQL or even 
> anything resembling code - often users fill in a form with data that is 
> turned into code.
> 
> But it really is a mistake to see OWL as a constraint language in the sense 
> of validation. An ontology cannot constrain; OWL is solely *descriptive* not 
> *prescriptive.* [1]
> 
> Inferencing is very different from validation, and this is an area where the 
> initial RDF documentation was (IMO) quite unclear. The OWL 2 documents are 
> better, but everyone admits that it's still an area of confusion. (In a major 
> act of confession at the DC2013 meeting, Ivan Herman, head of the W3C 
> semantic web work, said that this was a mistake that he himself made for many 
> years. Fortunately, he now helps write the documentation, and it's good that 
> he has that perspective.) In effect, inferencing is the *opposite* of 
> constraining. Inferencing is:
> 
> "All men are liars. Socrates is a man. Therefore Socrates is a liar."
> "Every child has a parent. Johnny is a child. Therefore, Johnny has a 
> parent." (whether you can find one or not is irrelevant)
> "Every child has two parents. Johnny is a child. Therefore Johnny has two 
> parents. Mary is Johnny's parent." (no contradiction here, we just don't know 
> who the other parent is)
> "Every child has two parents. Johnny is a child. Therefore Johnny has two 
> parents. Mary is Johnny's parent. Jane is Johnny's parent. Fred is Johnny's 
> parent." Here the reasoner detects a contradiction.
> 
> The issue of dct:titles is an interesting example. dct:title takes a literal 
> value. If you create a dct:title with:
> 
> X dct:title http://example.com/junk
> 
> with OWL rules that is NOT wrong. It simply provides the inference that 
> "http://example.com/junk"; is a string - but it can't prevent you from 
> creating that triple, because it only operates on existing data.
> 
> If you say that every resource MUST have a dct:title, then if you come across 
> a resource without a dct:title that is NOT wrong. The reasoner would conclude 
> that there is a dct:title somewhere because that's the rule.  (This is where 
> the Open World comes in) When data contradicts reasoners, they can't work 
> correctly, but they act on existing data, they do not modify or correct data.
> 
> I'm thinking that OWL and constraints would be an ideal training webinar, and 
> I think I know who could do it!
> 
> kc
> 
> [1] http://www.w3.org/TR/2012/REC-owl2-primer-20121211/
> "OW

Re: [CODE4LIB] Expressing negatives and similar in RDF

[stuart yeates]

On 13/09/13 23:32, Meehan, Thomas wrote:


However, it would be more useful, and quite common at least in a bibliographic context, to say "This book does not 
have a title". Ideally (?!) there would be an ontology of concepts like "none", "unknown", or 
even "something, but unspecified":

This book has no title:
example:thisbook dc:title hasobject:false .

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 .


The root of the cure here is having a model that defines the exact 
semantics of the RDF tags you're using.


For example the FRBRoo model, to assert that an F1 (Work) exists 
logically implies the existence of an E39 (Creator), an F27 (Work 
Conception), an F28 (Expression Creation), an F4 (Manifestation 
Singleton) and an F2 Expression, as well as two E52 (TimeSpan)s and two 
E53 (Place)s. See 
http://www.cidoc-crm.org/frbr_graphical_representation/graphical_representation/work_time.html


The bibliographer / cataloguer need not mention any of these, unless 
they wish to use them to add metadata to the F1 or to connect them with 
other items in the collection.


cheers
stuart
--
Stuart Yeates
Library Technology Services http://www.victoria.ac.nz/library/

Re: [CODE4LIB] Expressing negatives and similar in RDF

[Riley, Jenn]

Hi Tom,

I think it comes down to what you really mean by a book not having a
title. A few options I can think of:

1) This book was published without a title (or whatever verb you want
there if you want to cover unpublished material)
2) The author did not give this work a title
3) I've never heard of anyone calling this work by a formal title

There are certainly lots more options for a definition of untitled. But if
you're thinking along the lines of #3, I agree the open world assumption
comes into play, and you just done have a triple with a title-like
property, and if someone somewhere else has one, great. If #1 or #2 or
anything similar in structure, how about declaring titleless-ness as a
class that's a subclass of book? The semantics there would be "books
published without titles" or "books not given titles by their authors" or
whatever. You'd then just have a triple declaring this book part of that
class. Or the titleless-ness class could be broader than just books, and a
subclass of creative work (as defined in your vocabulary of choice).

Jenn


Jenn Riley
Head, Carolina Digital Library and Archives
The University of North Carolina at Chapel Hill
http://cdla.unc.edu/
http://www.lib.unc.edu/users/jlriley

jennri...@unc.edu
(919) 843-5910





On 9/13/13 7:32 AM, "Meehan, Thomas"  wrote:

>Hello,
>
>I'm not sure how sensible a question this is (it's certainly
>theoretical), but it cropped up in relation to a rare books cataloguing
>discussion. Is there a standard or accepted way to express negatives in
>RDF? This is best explained by examples, expressed in mock-turtle:
>
>If I want  to say this book has the title "Cats in RDA" I would do
>something like:
>
>example:thisbook dc:title "Cats in RDA" .
>
>Normally, if a predicate like dc:title is not relevant to
>example:thisbook I believe I am right in thinking that it would simply be
>missing, i.e. it is not part of a record where a set number of fields
>need to be filled in, so no need to even make the statement. However,
>there are occasions where a positively negative statement might be
>useful. I understand OWL has a way of managing the statement This book
>does not have the title "Cats in RDA" [1]:
>
>[]  rdf:type owl:NegativePropertyAssertion ;
> owl:sourceIndividual   example:thisbook ;
> owl:assertionProperty  dc:title ;
> owl:targetIndividual   "Cats in RDA" .
>
>However, it would be more useful, and quite common at least in a
>bibliographic context, to say "This book does not have a title". Ideally
>(?!) there would be an ontology of concepts like "none", "unknown", or
>even "something, but unspecified":
>
>This book has no title:
>example:thisbook dc:title hasobject:false .
>
>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
>[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
>
>t.mee...@ucl.ac.uk

Re: [CODE4LIB] Expressing negatives and similar in RDF

[Karen Coyle]

Agreed that SPARQL is ugly, and there was  discussion at the RDF 
validation workshop about the need for friendly interfaces that then 
create the appropriate SPARQL queries in the background. This shouldn't 
be surprising, since most business systems do not require users to write 
raw SQL or even anything resembling code - often users fill in a form 
with data that is turned into code.


But it really is a mistake to see OWL as a constraint language in the 
sense of validation. An ontology cannot constrain; OWL is solely 
*descriptive* not *prescriptive.* [1]


Inferencing is very different from validation, and this is an area where 
the initial RDF documentation was (IMO) quite unclear. The OWL 2 
documents are better, but everyone admits that it's still an area of 
confusion. (In a major act of confession at the DC2013 meeting, Ivan 
Herman, head of the W3C semantic web work, said that this was a mistake 
that he himself made for many years. Fortunately, he now helps write the 
documentation, and it's good that he has that perspective.) In effect, 
inferencing is the *opposite* of constraining. Inferencing is:


"All men are liars. Socrates is a man. Therefore Socrates is a liar."
"Every child has a parent. Johnny is a child. Therefore, Johnny has a 
parent." (whether you can find one or not is irrelevant)
"Every child has two parents. Johnny is a child. Therefore Johnny has 
two parents. Mary is Johnny's parent." (no contradiction here, we just 
don't know who the other parent is)
"Every child has two parents. Johnny is a child. Therefore Johnny has 
two parents. Mary is Johnny's parent. Jane is Johnny's parent. Fred is 
Johnny's parent." Here the reasoner detects a contradiction.


The issue of dct:titles is an interesting example. dct:title takes a 
literal value. If you create a dct:title with:


X dct:title http://example.com/junk

with OWL rules that is NOT wrong. It simply provides the inference that 
"http://example.com/junk"; is a string - but it can't prevent you from 
creating that triple, because it only operates on existing data.


If you say that every resource MUST have a dct:title, then if you come 
across a resource without a dct:title that is NOT wrong. The reasoner 
would conclude that there is a dct:title somewhere because that's the 
rule.  (This is where the Open World comes in) When data contradicts 
reasoners, they can't work correctly, but they act on existing data, 
they do not modify or correct data.


I'm thinking that OWL and constraints would be an ideal training 
webinar, and I think I know who could do it!


kc

[1] http://www.w3.org/TR/2012/REC-owl2-primer-20121211/
"OWL 2 is not a schema language for syntax conformance. Unlike XML, OWL 
2 does not provide elaborate means to prescribe how a document should be 
structured syntactically. In particular, there is no way to enforce that 
a certain piece of information (like the social security number of a 
person) has to be syntactically present. This should be kept in mind as 
OWL has some features that a user might misinterpret this way. "



On 9/17/13 4:50 AM, aj...@virginia.edu wrote:

I don't think anyone would want to use one ontology for all work, especially 
not a public ontology. I can imagine people using ontology extensions that are 
specific to the purpose of validation, and I've found them useful myself.

I'm not arguing against using SPARQL for validation. I do think that OWL offers 
a more natural-feeling language for discussing constraint for most folks, and I 
suppose that's why we've seen the introduction of extension languages like SPIN 
to intermediate a little between the user and plain SPARQL.

---
A. Soroka
The University of Virginia Library

On Sep 16, 2013, at 11:00 PM, CODE4LIB automatic digest system wrote:


From: Karen Coyle 
Date: September 16, 2013 10:22:47 AM EDT
Subject: Re: CODE4LIB Digest - 12 Sep 2013 to 13 Sep 2013 (#2013-237)


On 9/16/13 6:29 AM, aj...@virginia.edu wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I'd suggest that perhaps the confusion arises because "This instance is (not) 'valid' 
according to that ontology." might be inferred from an instance and an ontology (under certain 
conditions), and that's the soul of what we're asking when we define constraints on the data. 
Perhaps OWL can be used to express conditions of validity, as long as we represent the quality 
"valid" for use in inferences.

Based on the results of the RDF Validation workshop [1], validation is being 
expressed today as SPARQL rules. If you express the rules in OWL then 
unfortunately you affect downstream re-use of your ontology, and that can 
create a mess for inferencing and can add a burden onto any reasoners, which 
are supposed to apply the OWL declarations.

One participant at the workshop demonstrated a system that used the OWL 
"constraints" as constraints, but only in a closed system. I think that the use 
of SPARQL is superior because it does not affect the semantics of the classes a

Re: [CODE4LIB] Expressing negatives and similar in RDF

[Karen Coyle]

On 9/17/13 1:14 AM, Meehan, Thomas wrote:

Karen,

Yes, I mean that if you have something like:

- example:book1 dc:title example:unknownTitle .
- example:book2 dc:title example:noTitle .


Thomas, this does not work because the object of dc:title is the title 
of the work (actually, the defintion is "A name given to the resource".) 
Therefore, you have just declared the title of the work to be 
"example:unknownTitle." That obviously isn't right, but most importantly 
it isn't helpful. It isn't just a question of dcterms requiring a 
literal, it has to do with the meaning of dc:title. You need a property 
with a different meaning.


If you do this, then most dc-aware programs would display:

Title: example:unknownTitle

It would actually probably be more useful to say:

dc:title "unknown title"

although again you would be declaring that string to be the actual title 
of the item, which then gets us into the "Title varies" issue -- that 
is, you cannot prevent someone from creating a resource and giving it 
the actual title "unknown title."


Now, if you were to have the object of dc:title defined as "Content as 
Text", then, as the conversation continued between Esme and I, you could 
have a blank text (which would be saying that dc:title = ""), and, since 
the object of dc:title would be a URI (not a string), you could 
potentially mint a new property with the semantics of "title status" 
that could take an object like "example:unknownTitle."


kc

"

then this approach only works for the dc:title element (putting aside for now 
what you said about dc:title requiring a literal). For any other elements you 
would need to define a similar example:unknownThing:

- example:book2 example:claspNote "brass" .
- example:book2 example:claspNote example:noClasp .

The same would go for the following approach:

- example:book2 example:hasATitle egboolean:false .
- example:book2 example:hasAClasp egboolean:false .

I hope these make sense. An approach that could be used for any element might 
be useful. I admit at this stage that I need to reread the second half of the 
thread again. I can't decide in my head if this is something that the rules 
(RDA, etc) should handle. If so, RDA in particular has an entertaining variety 
of ways of doing so.

Thanks,

Tom






---

Thomas Meehan
Head of Current Cataloguing
Library Services
University College London
Gower Street
London WC1E 6BT

t.mee...@ucl.ac.uk


-Original Message-
From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of
Karen Coyle
Sent: 16 September 2013 16:23
To: CODE4LIB@LISTSERV.ND.EDU
Subject: Re: [CODE4LIB] Expressing negatives and similar in RDF

On 9/16/13 2:05 AM, Meehan, Thomas wrote:

Don: As I understand it, the open world view implies knowledge not

asserted for whatever reason, whereas sometimes a negative is a definite
(and ultimately verifiable) fact, such as a painting simply not having a title. 
I
think you're ultimately right about unknown things.

Esmé's solution does seem to work, although would perhaps require

redefinition for every element (title, place of pub, presence of clasp,
binding, etc.). I did wonder if a more generic method existed.

Can you say more about what you mean by "redefinition for every element"?

kc



Thank you,

Tom


---

Thomas Meehan
Head of Current Cataloguing
Library Services
University College London
Gower Street
London WC1E 6BT

t.mee...@ucl.ac.uk



-Original Message-
From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf
Of Donald Brower
Sent: 13 September 2013 14:46
To: CODE4LIB@LISTSERV.ND.EDU
Subject: Re: [CODE4LIB] Expressing negatives and similar in RDF

At a theoretical level, doesn't the Open World Assumption in RDF rule
out outright negations? That is, someone else may know the title, and
could assert it in a separate RDF document. RDF semantics seem to
conflate unknown with nonexistent.

Practically, Esme's approach seems better in these cases.


-Don


--
Donald Brower, Ph.D.
Digital Library Infrastructure Lead
Hesburgh Libraries, University of Notre Dame




On 9/13/13 8: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.

You could then describe example:unknownTitle with a label or comment
to fully describe the states you wanted to capture with the
different categories.

-Esme
--
Esme Cowles 

"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/13/2013, at 7:32 AM, "Meehan, Thomas" 

wrote:

Hello,

I'm not sure how sensible a questio

Re: [CODE4LIB] Expressing negatives and similar in RDF

[aj...@virginia.edu]

I don't think anyone would want to use one ontology for all work, especially 
not a public ontology. I can imagine people using ontology extensions that are 
specific to the purpose of validation, and I've found them useful myself.

I'm not arguing against using SPARQL for validation. I do think that OWL offers 
a more natural-feeling language for discussing constraint for most folks, and I 
suppose that's why we've seen the introduction of extension languages like SPIN 
to intermediate a little between the user and plain SPARQL.

---
A. Soroka
The University of Virginia Library

On Sep 16, 2013, at 11:00 PM, CODE4LIB automatic digest system wrote:

> From: Karen Coyle 
> Date: September 16, 2013 10:22:47 AM EDT
> Subject: Re: CODE4LIB Digest - 12 Sep 2013 to 13 Sep 2013 (#2013-237)
> 
> 
> On 9/16/13 6:29 AM, aj...@virginia.edu wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>> 
>> I'd suggest that perhaps the confusion arises because "This instance is 
>> (not) 'valid' according to that ontology." might be inferred from an 
>> instance and an ontology (under certain conditions), and that's the soul of 
>> what we're asking when we define constraints on the data. Perhaps OWL can be 
>> used to express conditions of validity, as long as we represent the quality 
>> "valid" for use in inferences.
> 
> Based on the results of the RDF Validation workshop [1], validation is being 
> expressed today as SPARQL rules. If you express the rules in OWL then 
> unfortunately you affect downstream re-use of your ontology, and that can 
> create a mess for inferencing and can add a burden onto any reasoners, which 
> are supposed to apply the OWL declarations.
> 
> One participant at the workshop demonstrated a system that used the OWL 
> "constraints" as constraints, but only in a closed system. I think that the 
> use of SPARQL is superior because it does not affect the semantics of the 
> classes and properties, only the instance data, and that means that the same 
> properties can be validated differently for different applications or under 
> different contexts. As an example, one community may wish to say that their 
> metadata can have one and only one dc:title, while others may allow more than 
> one. You do not want to constrain dc:title throughout the Web, only your own 
> use of it. (Tom Baker and I presented a solution to this on the second day as 
> Application Profiles [2], as defined by the DC community).
> 
> kc
> [1] https://www.w3.org/2012/12/rdf-val/agenda
> [2] 
> http://www.w3.org/2001/sw/wiki/images/e/ef/Baker-dc-abstract-model-revised.pdf



PGP.sig
Description: This is a digitally signed message part

Re: [CODE4LIB] Expressing negatives and similar in RDF

[Meehan, Thomas]

Karen,

Yes, I mean that if you have something like:

- example:book1 dc:title example:unknownTitle .
- example:book2 dc:title example:noTitle .

then this approach only works for the dc:title element (putting aside for now 
what you said about dc:title requiring a literal). For any other elements you 
would need to define a similar example:unknownThing:

- example:book2 example:claspNote "brass" .
- example:book2 example:claspNote example:noClasp .

The same would go for the following approach:

- example:book2 example:hasATitle egboolean:false .
- example:book2 example:hasAClasp egboolean:false .

I hope these make sense. An approach that could be used for any element might 
be useful. I admit at this stage that I need to reread the second half of the 
thread again. I can't decide in my head if this is something that the rules 
(RDA, etc) should handle. If so, RDA in particular has an entertaining variety 
of ways of doing so.

Thanks,

Tom






---

Thomas Meehan
Head of Current Cataloguing
Library Services
University College London
Gower Street
London WC1E 6BT

t.mee...@ucl.ac.uk

> -Original Message-
> From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of
> Karen Coyle
> Sent: 16 September 2013 16:23
> To: CODE4LIB@LISTSERV.ND.EDU
> Subject: Re: [CODE4LIB] Expressing negatives and similar in RDF
> 
> On 9/16/13 2:05 AM, Meehan, Thomas wrote:
> > Don: As I understand it, the open world view implies knowledge not
> asserted for whatever reason, whereas sometimes a negative is a definite
> (and ultimately verifiable) fact, such as a painting simply not having a 
> title. I
> think you're ultimately right about unknown things.
> >
> > Esmé's solution does seem to work, although would perhaps require
> redefinition for every element (title, place of pub, presence of clasp,
> binding, etc.). I did wonder if a more generic method existed.
> 
> Can you say more about what you mean by "redefinition for every element"?
> 
> kc
> 
> 
> >
> > Thank you,
> >
> > Tom
> >
> >
> > ---
> >
> > Thomas Meehan
> > Head of Current Cataloguing
> > Library Services
> > University College London
> > Gower Street
> > London WC1E 6BT
> >
> > t.mee...@ucl.ac.uk
> >
> >
> >> -----Original Message-----
> >> From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf
> >> Of Donald Brower
> >> Sent: 13 September 2013 14:46
> >> To: CODE4LIB@LISTSERV.ND.EDU
> >> Subject: Re: [CODE4LIB] Expressing negatives and similar in RDF
> >>
> >> At a theoretical level, doesn't the Open World Assumption in RDF rule
> >> out outright negations? That is, someone else may know the title, and
> >> could assert it in a separate RDF document. RDF semantics seem to
> >> conflate unknown with nonexistent.
> >>
> >> Practically, Esme's approach seems better in these cases.
> >>
> >>
> >> -Don
> >>
> >>
> >> --
> >> Donald Brower, Ph.D.
> >> Digital Library Infrastructure Lead
> >> Hesburgh Libraries, University of Notre Dame
> >>
> >>
> >>
> >>
> >> On 9/13/13 8: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.
> >>>
> >>> You could then describe example:unknownTitle with a label or comment
> >>> to fully describe the states you wanted to capture with the
> >>> different categories.
> >>>
> >>> -Esme
> >>> --
> >>> Esme Cowles 
> >>>
> >>> "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/13/2013, at 7:32 AM, "Meehan, Thomas" 
> >> wrote:
> >>>> Hello,
> >>>>
> >>>> I'm not sure how sensible a question this is (it's certainly
> >>>> theoretical), but it cropped up in relation to a rare books
> >>>> cataloguing discussion. Is there a standard or accepted way to
> >>>> express negatives in RDF? This is best explained by examples,
> >>

Re: [CODE4LIB] Expressing negatives and similar in RDF

[Karen Coyle]

On 9/16/13 2:05 AM, Meehan, Thomas wrote:

Don: As I understand it, the open world view implies knowledge not asserted for 
whatever reason, whereas sometimes a negative is a definite (and ultimately 
verifiable) fact, such as a painting simply not having a title. I think you're 
ultimately right about unknown things.

Esmé's solution does seem to work, although would perhaps require redefinition 
for every element (title, place of pub, presence of clasp, binding, etc.). I 
did wonder if a more generic method existed.


Can you say more about what you mean by "redefinition for every element"?

kc




Thank you,

Tom


---

Thomas Meehan
Head of Current Cataloguing
Library Services
University College London
Gower Street
London WC1E 6BT

t.mee...@ucl.ac.uk



-Original Message-
From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of
Donald Brower
Sent: 13 September 2013 14:46
To: CODE4LIB@LISTSERV.ND.EDU
Subject: Re: [CODE4LIB] Expressing negatives and similar in RDF

At a theoretical level, doesn't the Open World Assumption in RDF rule out
outright negations? That is, someone else may know the title, and could
assert it in a separate RDF document. RDF semantics seem to conflate
unknown with nonexistent.

Practically, Esme's approach seems better in these cases.


-Don


--
Donald Brower, Ph.D.
Digital Library Infrastructure Lead
Hesburgh Libraries, University of Notre Dame




On 9/13/13 8: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.

You could then describe example:unknownTitle with a label or comment to
fully describe the states you wanted to capture with the different
categories.

-Esme
--
Esme Cowles 

"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/13/2013, at 7:32 AM, "Meehan, Thomas" 

wrote:

Hello,

I'm not sure how sensible a question this is (it's certainly
theoretical), but it cropped up in relation to a rare books
cataloguing discussion. Is there a standard or accepted way to express
negatives in RDF? This is best explained by examples, expressed in mock-

turtle:

If I want  to say this book has the title "Cats in RDA" I would do
something like:

example:thisbook dc:title "Cats in RDA" .

Normally, if a predicate like dc:title is not relevant to
example:thisbook I believe I am right in thinking that it would simply
be missing, i.e. it is not part of a record where a set number of
fields need to be filled in, so no need to even make the statement.
However, there are occasions where a positively negative statement
might be useful. I understand OWL has a way of managing the statement
This book does not have the title "Cats in RDA" [1]:

[]  rdf:type owl:NegativePropertyAssertion ;
 owl:sourceIndividual   example:thisbook ;
 owl:assertionProperty  dc:title ;
 owl:targetIndividual   "Cats in RDA" .

However, it would be more useful, and quite common at least in a
bibliographic context, to say "This book does not have a title".
Ideally
(?!) there would be an ontology of concepts like "none", "unknown", or
even "something, but unspecified":

This book has no title:
example:thisbook dc:title hasobject:false .

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
[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

t.mee...@ucl.ac.uk


--
Karen Coyle
kco...@kcoyle.net http://kcoyle.net
m: 1-510-435-8234
skype: kcoylenet

Re: [CODE4LIB] Expressing negatives and similar in RDF

[Meehan, Thomas]

Don: As I understand it, the open world view implies knowledge not asserted for 
whatever reason, whereas sometimes a negative is a definite (and ultimately 
verifiable) fact, such as a painting simply not having a title. I think you're 
ultimately right about unknown things.

Esmé's solution does seem to work, although would perhaps require redefinition 
for every element (title, place of pub, presence of clasp, binding, etc.). I 
did wonder if a more generic method existed.

Thank you,

Tom


---

Thomas Meehan
Head of Current Cataloguing
Library Services
University College London
Gower Street
London WC1E 6BT

t.mee...@ucl.ac.uk


> -Original Message-
> From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of
> Donald Brower
> Sent: 13 September 2013 14:46
> To: CODE4LIB@LISTSERV.ND.EDU
> Subject: Re: [CODE4LIB] Expressing negatives and similar in RDF
> 
> At a theoretical level, doesn't the Open World Assumption in RDF rule out
> outright negations? That is, someone else may know the title, and could
> assert it in a separate RDF document. RDF semantics seem to conflate
> unknown with nonexistent.
> 
> Practically, Esme's approach seems better in these cases.
> 
> 
> -Don
> 
> 
> --
> Donald Brower, Ph.D.
> Digital Library Infrastructure Lead
> Hesburgh Libraries, University of Notre Dame
> 
> 
> 
> 
> On 9/13/13 8: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.
> >
> >You could then describe example:unknownTitle with a label or comment to
> >fully describe the states you wanted to capture with the different
> >categories.
> >
> >-Esme
> >--
> >Esme Cowles 
> >
> >"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/13/2013, at 7:32 AM, "Meehan, Thomas" 
> wrote:
> >
> >> Hello,
> >>
> >> I'm not sure how sensible a question this is (it's certainly
> >>theoretical), but it cropped up in relation to a rare books
> >>cataloguing discussion. Is there a standard or accepted way to express
> >>negatives in RDF? This is best explained by examples, expressed in mock-
> turtle:
> >>
> >> If I want  to say this book has the title "Cats in RDA" I would do
> >>something like:
> >>
> >> example:thisbook dc:title "Cats in RDA" .
> >>
> >> Normally, if a predicate like dc:title is not relevant to
> >>example:thisbook I believe I am right in thinking that it would simply
> >>be missing, i.e. it is not part of a record where a set number of
> >>fields need to be filled in, so no need to even make the statement.
> >>However, there are occasions where a positively negative statement
> >>might be useful. I understand OWL has a way of managing the statement
> >>This book does not have the title "Cats in RDA" [1]:
> >>
> >> []  rdf:type owl:NegativePropertyAssertion ;
> >> owl:sourceIndividual   example:thisbook ;
> >> owl:assertionProperty  dc:title ;
> >> owl:targetIndividual   "Cats in RDA" .
> >>
> >> However, it would be more useful, and quite common at least in a
> >>bibliographic context, to say "This book does not have a title".
> >>Ideally
> >>(?!) there would be an ontology of concepts like "none", "unknown", or
> >>even "something, but unspecified":
> >>
> >> This book has no title:
> >> example:thisbook dc:title hasobject:false .
> >>
> >> 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
> >> [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
> >>
> >> t.mee...@ucl.ac.uk

Re: [CODE4LIB] Expressing negatives and similar in RDF

[Esmé Cowles]

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:

  _:bn1 .
_:bn1   .
_:bn1  "UTF-8" .
_:bn1  "" .


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 

"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  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 
> | 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 
>> 
>> "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  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 
 
 "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  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 lea

Re: [CODE4LIB] Expressing negatives and similar in RDF

[Karen Coyle]

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 
| 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 

"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  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 

"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  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  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 COU

Re: [CODE4LIB] Expressing negatives and similar in RDF

[Esmé Cowles]

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 

"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  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 
>> 
>> "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  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  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 v

Re: [CODE4LIB] Expressing negatives and similar in RDF

[Karen Coyle]

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 

"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  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  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 
Refines:
http://purl.org/dc/elements/1.**1/title
Version:
http://dublincore.org/usage/**terms/history/#titleT-002

Re: [CODE4LIB] Expressing negatives and similar in RDF

[Karen Coyle]

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  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 
Refines:
http://purl.org/dc/elements/1.**1/title
Version:
http://dublincore.org/usage/**terms/history/#titleT-002
Has Range:  
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
Label:  Title
Definition: A name given to the resource.
Type of Term:   Property 
Version:
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/ )
for an explanation.


I still think you are going outsi

Re: [CODE4LIB] Expressing negatives and similar in RDF

[Karen Coyle]

OWL contains some negative assertions, as Thomas noted. Nothing prevents 
anyone else from negating your negative, however, in that Open World. 
Assuming that we have provenance on statements, then you might be able 
to make sense of two conflicting bits of information.


I've found two vocabularies that do a Boolean negation (Not, as well as 
And and Or):


http://vocab.deri.ie/csp
http://vocab.deri.ie/ppo#

The CSP is used for car models, where there can be hundreds of options 
on a car (color, radio, #doors, gps, etc etc). However, looking at the 
diagram [1] I think it would take me great concentration to figure out 
what they are doing (not to mention their weird use of the term 
"Fluent"). I'm going to look for examples but am not sure how to do that 
- hunt and peck, I guess.


kc
[1] http://vocab.deri.ie/csp#Not

On 9/13/13 6:46 AM, Donald Brower wrote:

At a theoretical level, doesn't the Open World Assumption in RDF rule out
outright negations? That is, someone else may know the title, and could
assert it in a separate RDF document. RDF semantics seem to conflate
unknown with nonexistent.

Practically, Esme's approach seems better in these cases.


-Don


--
Donald Brower, Ph.D.
Digital Library Infrastructure Lead
Hesburgh Libraries, University of Notre Dame




On 9/13/13 8: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.

You could then describe example:unknownTitle with a label or comment to
fully describe the states you wanted to capture with the different
categories.

-Esme
--
Esme Cowles 

"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/13/2013, at 7:32 AM, "Meehan, Thomas"  wrote:


Hello,

I'm not sure how sensible a question this is (it's certainly
theoretical), but it cropped up in relation to a rare books cataloguing
discussion. Is there a standard or accepted way to express negatives in
RDF? This is best explained by examples, expressed in mock-turtle:

If I want  to say this book has the title "Cats in RDA" I would do
something like:

example:thisbook dc:title "Cats in RDA" .

Normally, if a predicate like dc:title is not relevant to
example:thisbook I believe I am right in thinking that it would simply
be missing, i.e. it is not part of a record where a set number of fields
need to be filled in, so no need to even make the statement. However,
there are occasions where a positively negative statement might be
useful. I understand OWL has a way of managing the statement This book
does not have the title "Cats in RDA" [1]:

[]  rdf:type owl:NegativePropertyAssertion ;
 owl:sourceIndividual   example:thisbook ;
 owl:assertionProperty  dc:title ;
 owl:targetIndividual   "Cats in RDA" .

However, it would be more useful, and quite common at least in a
bibliographic context, to say "This book does not have a title". Ideally
(?!) there would be an ontology of concepts like "none", "unknown", or
even "something, but unspecified":

This book has no title:
example:thisbook dc:title hasobject:false .

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
[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

t.mee...@ucl.ac.uk


--
Karen Coyle
kco...@kcoyle.net http://kcoyle.net
m: 1-510-435-8234
skype: kcoylenet

Re: [CODE4LIB] Expressing negatives and similar in RDF

[Stephen Hearn]

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  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  rdf-syntax-ns#Property
> >
> Refines:
> http://purl.org/dc/elements/1.**1/title
> Version:
> http://dublincore.org/usage/**terms/history/#titleT-002
> Has Range:  
> 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
> Label:  Title
> Definition: A name given to the resource.
> Type of Term:   Property  rdf-syntax-ns#Property
> >
> Version:
> 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/ )
> 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 t

Re: [CODE4LIB] Expressing negatives and similar in RDF

[Karen Coyle]

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 


Refines:http://purl.org/dc/elements/1.1/title
Version:http://dublincore.org/usage/terms/history/#titleT-002
Has Range:  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
Label:  Title
Definition: A name given to the resource.
Type of Term: 	Property 


Version: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/) 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
[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

t.mee...@ucl.ac.uk


--
Karen Coyle
kco...@kcoyle.net http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet

Re: [CODE4LIB] Expressing negatives and similar in RDF

[Donald Brower]

At a theoretical level, doesn't the Open World Assumption in RDF rule out
outright negations? That is, someone else may know the title, and could
assert it in a separate RDF document. RDF semantics seem to conflate
unknown with nonexistent.

Practically, Esme's approach seems better in these cases.


-Don


--
Donald Brower, Ph.D.
Digital Library Infrastructure Lead
Hesburgh Libraries, University of Notre Dame




On 9/13/13 8: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.
>
>You could then describe example:unknownTitle with a label or comment to
>fully describe the states you wanted to capture with the different
>categories.
>
>-Esme
>--
>Esme Cowles 
>
>"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/13/2013, at 7:32 AM, "Meehan, Thomas"  wrote:
>
>> Hello,
>> 
>> I'm not sure how sensible a question this is (it's certainly
>>theoretical), but it cropped up in relation to a rare books cataloguing
>>discussion. Is there a standard or accepted way to express negatives in
>>RDF? This is best explained by examples, expressed in mock-turtle:
>> 
>> If I want  to say this book has the title "Cats in RDA" I would do
>>something like:
>> 
>> example:thisbook dc:title "Cats in RDA" .
>> 
>> Normally, if a predicate like dc:title is not relevant to
>>example:thisbook I believe I am right in thinking that it would simply
>>be missing, i.e. it is not part of a record where a set number of fields
>>need to be filled in, so no need to even make the statement. However,
>>there are occasions where a positively negative statement might be
>>useful. I understand OWL has a way of managing the statement This book
>>does not have the title "Cats in RDA" [1]:
>> 
>> []  rdf:type owl:NegativePropertyAssertion ;
>> owl:sourceIndividual   example:thisbook ;
>> owl:assertionProperty  dc:title ;
>> owl:targetIndividual   "Cats in RDA" .
>> 
>> However, it would be more useful, and quite common at least in a
>>bibliographic context, to say "This book does not have a title". Ideally
>>(?!) there would be an ontology of concepts like "none", "unknown", or
>>even "something, but unspecified":
>> 
>> This book has no title:
>> example:thisbook dc:title hasobject:false .
>> 
>> 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
>> [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
>> 
>> t.mee...@ucl.ac.uk

Re: [CODE4LIB] Expressing negatives and similar in RDF

[Ethan Gruber]

+1


On Fri, Sep 13, 2013 at 8: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.
>
> You could then describe example:unknownTitle with a label or comment to
> fully describe the states you wanted to capture with the different
> categories.
>
> -Esme
> --
> Esme Cowles 
>
> "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/13/2013, at 7:32 AM, "Meehan, Thomas"  wrote:
>
> > Hello,
> >
> > I'm not sure how sensible a question this is (it's certainly
> theoretical), but it cropped up in relation to a rare books cataloguing
> discussion. Is there a standard or accepted way to express negatives in
> RDF? This is best explained by examples, expressed in mock-turtle:
> >
> > If I want  to say this book has the title "Cats in RDA" I would do
> something like:
> >
> > example:thisbook dc:title "Cats in RDA" .
> >
> > Normally, if a predicate like dc:title is not relevant to
> example:thisbook I believe I am right in thinking that it would simply be
> missing, i.e. it is not part of a record where a set number of fields need
> to be filled in, so no need to even make the statement. However, there are
> occasions where a positively negative statement might be useful. I
> understand OWL has a way of managing the statement This book does not have
> the title "Cats in RDA" [1]:
> >
> > []  rdf:type owl:NegativePropertyAssertion ;
> > owl:sourceIndividual   example:thisbook ;
> > owl:assertionProperty  dc:title ;
> > owl:targetIndividual   "Cats in RDA" .
> >
> > However, it would be more useful, and quite common at least in a
> bibliographic context, to say "This book does not have a title". Ideally
> (?!) there would be an ontology of concepts like "none", "unknown", or even
> "something, but unspecified":
> >
> > This book has no title:
> > example:thisbook dc:title hasobject:false .
> >
> > 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
> > [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
> >
> > t.mee...@ucl.ac.uk
>

Re: [CODE4LIB] Expressing negatives and similar in RDF

[Esmé Cowles]

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.

You could then describe example:unknownTitle with a label or comment to fully 
describe the states you wanted to capture with the different categories.

-Esme
--
Esme Cowles 

"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/13/2013, at 7:32 AM, "Meehan, Thomas"  wrote:

> Hello,
> 
> I'm not sure how sensible a question this is (it's certainly theoretical), 
> but it cropped up in relation to a rare books cataloguing discussion. Is 
> there a standard or accepted way to express negatives in RDF? This is best 
> explained by examples, expressed in mock-turtle:
> 
> If I want  to say this book has the title "Cats in RDA" I would do something 
> like:
> 
> example:thisbook dc:title "Cats in RDA" .
> 
> Normally, if a predicate like dc:title is not relevant to example:thisbook I 
> believe I am right in thinking that it would simply be missing, i.e. it is 
> not part of a record where a set number of fields need to be filled in, so no 
> need to even make the statement. However, there are occasions where a 
> positively negative statement might be useful. I understand OWL has a way of 
> managing the statement This book does not have the title "Cats in RDA" [1]:
> 
> []  rdf:type owl:NegativePropertyAssertion ;
> owl:sourceIndividual   example:thisbook ;
> owl:assertionProperty  dc:title ;
> owl:targetIndividual   "Cats in RDA" .
> 
> However, it would be more useful, and quite common at least in a 
> bibliographic context, to say "This book does not have a title". Ideally (?!) 
> there would be an ontology of concepts like "none", "unknown", or even 
> "something, but unspecified":
> 
> This book has no title:
> example:thisbook dc:title hasobject:false .
> 
> 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
> [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
> 
> t.mee...@ucl.ac.uk

[CODE4LIB] Expressing negatives and similar in RDF

[Meehan, Thomas]

Hello,

I'm not sure how sensible a question this is (it's certainly theoretical), but 
it cropped up in relation to a rare books cataloguing discussion. Is there a 
standard or accepted way to express negatives in RDF? This is best explained by 
examples, expressed in mock-turtle:

If I want  to say this book has the title "Cats in RDA" I would do something 
like:

example:thisbook dc:title "Cats in RDA" .

Normally, if a predicate like dc:title is not relevant to example:thisbook I 
believe I am right in thinking that it would simply be missing, i.e. it is not 
part of a record where a set number of fields need to be filled in, so no need 
to even make the statement. However, there are occasions where a positively 
negative statement might be useful. I understand OWL has a way of managing the 
statement This book does not have the title "Cats in RDA" [1]:

[]  rdf:type owl:NegativePropertyAssertion ;
 owl:sourceIndividual   example:thisbook ;
 owl:assertionProperty  dc:title ;
 owl:targetIndividual   "Cats in RDA" .

However, it would be more useful, and quite common at least in a bibliographic 
context, to say "This book does not have a title". Ideally (?!) there would be 
an ontology of concepts like "none", "unknown", or even "something, but 
unspecified":

This book has no title:
example:thisbook dc:title hasobject:false .

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
[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

t.mee...@ucl.ac.uk