Dear Gordon,

I wanted to respond to this email about the deprecation/deletion issue you raised.

The idea, rightly or wrongly (has this ground been tread before?), was to change the nature of the resource.  To change its type.  Full stop. (In which case there would be no disjoint-ness - my:Cookery a mads:Authority would no longer be asserted, at least not from the source.)

Your point "a)" correctly identifies our intention and records your suggestion to deprecate the triple versus delete it (though that still leaves the disjoint issue, point "b)" ).

Regarding your point "a)" - triples should be deprecated, NOT deleted - I have a few questions, which sound more challenging than I mean them to sound:

1)Is this an established rule/guideline?
2)With 1, what is the source of the rule/guideline?
3)Is this established practice?
4)With 4, where might I find an example?  (Particularly, a Linked Data example.)

Again, not challenging - I ask because this would be really, really helpful information.  In my own search for answers, I actually came across a 2009 DesignIssues article by TimBL that, if I understand clearly, not only accepts that data changes, but also proposes a few ways to modify triples (including deletes) in the Web of Linked Data [1].

We're open to suggestions about this, so your feedback is most appreciated.  To restate the problem/use case briefly: 
1)Authoritative headings change.  This is a simple reality.  Currently, when a term is deprecated, the (MARC) record for the deprecated term includes a pointer to the term(s) with which the deprecated term has been replaced.  The deprecated term is no longer authoritative.  It is, however, added as a variant on its replacement(s).  
2)Example (slightly restated): "Cookery" was antiquated; more people naturally searched "Cooking" (or "Cookbooks") when looking for material described with the term "Cookery." So, the authority record for "Cookery," within LCSH, was deleted.  The term "Cookery" became a variant term for the new authorities "Cooking" and "Cookbooks," both of which received new LCCNs (these are part of HTTP URIs).  The LCCN for "Cookery" was not re-used.
3)For Linked Data purposes, we feel it important to honor the URIs for "deprecated" terms; they shouldn't simply disappear.  Someone may have used the HTTP URI for "Cookery."  We must communicate to the user (human or machine) following a URI of a deprecated term that the term is no longer valid and, to hark back to the example above, "Cooking" or "Cookbooks" should be used.

There are a number of ways to indicate that terms are no longer valid as authoritative.  They could be removed from the MADSScheme (LCSH); there is a recordStatus of "deleted"; the record includes a mads:hasLaterEstablishedForm property (the presence of this property alone, however, does not conclusively mean the term has been deprecated).  Changing the type from Authority to Variant not only provided a way to communicate that something had changed - that the term was no longer authoritative -  but also reflected the reality of what happens when a term is deprecated in favor of a new one (incidentally, the variant for "Cookery" associated with "Cooking" would be identified by an HTTP URI in this case - more linkage). 

Reification, which you proposed, is a possible solution, but I'm wary.  For example, we've been discussing the idea of NOT changing a term's type.  "Cookery," therefore, would remain a mads:Authority, and so avoid the disjoint issue altogether.  Naturally, it would include new triples: 

my:Cookery mads:hasLaterEstablishedForm my:Cooking
my:Cookery mads:hasLaterEstablishedForm my:Cookbooks

Adding triples is easy.  However, it would be proper to remove my:Cookery from the LCSH scheme (my:Cookery is, quite simply, no longer an authoritative term in LCSH).  For this, one can deprecate, via reification, the following triple:  

my:Cookery mads:isMemberOfMADSScheme my:LCSH

But, who naturally queries RDF data and includes, as part of the query, a check for reified statements pertaining to any and all triples?  Reifying statements is entirely possible, of course, but is it practical?  Is there some kind of standard reified statement that effectively deprecates a triple, perhaps so RDF data could be loaded into a triplestore and the triplestore "knows" what is valid and what is not? 

More broadly, in your opinion, is it not possible to change data once it has been added to the Linked Data pool (without reification)?  (Again, not challenging - asking for clarification and pointers.)

Based on your comments and others, we've contemplated altering the model so that deprecated authorities remain a mads:Authority type and using other indicators to communicate the (deprecated) status of the mads:Authority.  This is basically what happens today with MARC records.  Alternatively, we could add a another Class to the ontology in order to neatly indicate deprecation.  Something like mads:DeprecatedAuthority.  Adding a new Class (or not) still does not solve my mads:isMemberOfMADSScheme problem.  I'd prefer to no longer assert the mads:isMemberOfMADSScheme triple, but at least with the addition of mads:DeprecatedAuthority the query for identifying authorities in LCSH that have NOT been deprecated becomes easier, and a little more natural than looking for reified statements.  In the end, I still see a need to delete, or otherwise modify, at least one triple.

In terms of Linked Data, we're interested in providing users with a model, and eventual service, that not only makes the data available, but also usable by humans and machines even as the data change and evolve.  Clearly and unambiguously identifying changes in the data, which are simply a reality, is one of our aims.

I look forward to your thoughts, not only about the best way to indicate deprecation, but also the modification of triples in the Web of Linked Data.  On this last notion, I can't stop wondering about the sustainability of LD if triples are immutable.

Warmly,

Kevin

p.s.   I would very much like to invite others to offer their opinions on this matter, particularly about the notion that triples cannot, or should not, be deleted in a LD world.

[1] http://www.w3.org/DesignIssues/ReadWriteLinkedData.html

________________________________________
From: Metadata Object Description Schema List [[log in to unmask]] On Behalf Of [log in to unmask] [[log in to unmask]]
Sent: Wednesday, January 19, 2011 19:31
To: [log in to unmask]
Subject: Re: [MODS] MADS/RDF for review

Karen


My reading of the ontology is that a term is assigned to the Authority class when it is "preferred", or the Variant class when it is "non-preferred". But:



a) once the triple [my:Cookery a madsrdf:Authority] is published, you should deprecate it, not delete it. To deprecate it, you can use reification and meta-metadata (admin) properties.



b) [madsrdf:Authority owl:disjointWith madsrdf:Variant] - so you cannot add the triple [my:Cookery a madsrdf:Variant] to the linked data pool, as it will cause an inference problem: a thing cannot belong to two or more disjoint classes.



You can avoid a) and delete the triple if it is not in the linked data pool, of course (say if it was on an intranet), but there doesn't seem to be much point in using an RDF representation of authority data if that were the case.



So I don't see how the term can be demoted when the new terms are added.



Cheers



Gordon



On 19 January 2011 at 23:07 Karen Coyle <[log in to unmask]> wrote:

> Gordon, I have read this through a couple of times, and I feel like I
> *should* understand the question, but I don't. So I'll start with a
> question about your question:
>
> >
> > Later, the label "Cookery" is deprecated in favour of the labels
> > "Cooking" and
> > "Cookbooks". Each of these is the authoritative term for a concept,
> > with URIs,
> > say, my:Cooking and my:Cookbooks; we cannot say:
> >
> > *my:Cookery a madsrdf:Variant.
> >
> > because Authority and Variant are disjoint classes.
>
> Isn't the assumption that Cookery has been demoted to "Variant" at the
> same time that Cooking and Cookbooks are added to the vocabulary list?
>
> kc
>
> >
> > Ignoring "Cookbooks", we have:
> >
> > my:Cooking a madsrdf:Authority.
> >
> > We cannot say:
> >
> > *my:Cooking madsrdf:hasVariant my:Cookery.
> >
> > because the range of hasVariant is Variant.
> >
> > So we have to create another URI for the concept with the label
> > "Cookery" as a
> > variant heading, say my:Cookery2. We can now say:
> >
> > My:Cookery2 a madsrdf:Variant.
> > My:Cooking madsrdf:hasVariant my:Cookery2.
> >
> > To link the initial Authority and subsequent Variant, both with the label
> > "Cookery", we try:
> >
> > *my:Cookery madsrdf:hasLaterEstablishedForm my:Cookery2
> >
> > But this is wrong, because the range of hasLaterEstablishedForm is Authority.
> > Trivially,:
> >
> > *my:Cookery2 madsrdf:hasLaterEstablishedForm my:Cookery
> >
> > fails for similar reasons.
> >
> > We can correctly say:
> >
> > My:Cookery hasLaterEstablishedForm my:Cooking.
> >
> > But this is indistiguishable from the case given in section 3.3,
> > item a), where
> > the earlier heading remains valid and is not "deprecated".
> >
> > The only way we have of directly linking my:Cookery as Authority to
> > my:Cookery2
> > as Variant is:
> >
> > My:Cookery2 madsrdf:hasLaterEstablishedForm my:Cookery1
> >
> > We can do this because hasLaterEstablishedForm has no specified
> > domain. But the
> > statement is counter-intuitive, of course.
> >
> > So it seems that the ontology fails to meet the imperative support for
> > deprecated headings, except by some tortuous method involving
> > comparing labels
> > of concepts that are related by a specific combination of properties.
> >
> > I'm sure I am misinterpreting the ontology, but I can't see where.
> >
> > Cheers
> >
> > Gordon
> >
> >
>
>
>
> --
> Karen Coyle
> [log in to unmask] http://kcoyle.net
> ph: 1-510-540-7596
> m: 1-510-435-8234
> skype: kcoylenet