LISTSERV mailing list manager LISTSERV 16.0

Help for MODS Archives


MODS Archives

MODS Archives


[email protected]


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

MODS Home

MODS Home

MODS  February 2011

MODS February 2011

Subject:

Re: MADS/RDF for review

From:

Antoine Isaac <[log in to unmask]>

Reply-To:

Metadata Object Description Schema List <[log in to unmask]>

Date:

Wed, 9 Feb 2011 11:18:02 +0100

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (223 lines)

Hi Gordon,

Very valid points, to which I truly wouldn't object in the principle. The issue is whether it is MADS to solve this versioning problem. And whether they really would prevent people from working.

I believe not: these semantic inconsistencies raised by the pattern of replacing the class would harm applications no more than what happens currently with the "non-RDF" version. If a term changes in the central authority, the local data is inconsistent/obsolete, it's just that you don't notice it (in most cases). With the current pattern, people interested in detecting inconsistencies so that they can update their data would have a relatively easy way to do it. And of course there is also the option of not running OWL validation tools and detecting the inconsistencies.

In fact I believe that the pattern provides a nice motivation for opting in to apply reasoners. And it is much simpler for data consumers than solutions that would require fully worked out versioning (note that it is still possible to apply such solutions later on top of the data: you still need to say that at one point a resource was an authority and then it was turned into a variant, anyway).

Cheers,

Antoine



>
> I don't know of a specific rule about not deleting triples. A quick scan of Google hits seems to show that deletion of triples is discussed in the context of consuming data (e.g. deleting triples that have been harvested or otherwise ingested into a local triple store), while deprecation (and version control in general) is discussed in the context of producing and maintaining data.
>
> I suspect that deleting a triple runs counter to the Open World Assumption (OWA). It certainly reduces semantic coherence. If my application uses the Cookery-isa-Authority triple, in all good faith, then anyone consuming my application together with a later version of MADS/LCSH will encounter the semantic collision with the Cookery-isa-Variant triple. More simply, it will weaken the Web by creating broken links.
>
> Deleting or re-using a URI immediately destroys semantic coherence, and is not an option if MADS is to be taken seriously. Use of mads:hasLaterEstablishedForm is more appropriate. I'm not sure why the inference that the earlier established form is deprecated is not conclusive, unless you are referring to, say, the name of a corporate body which remains "valid" after it changes. I guess this hinges on what is meant by "deprecated". In the context of controlled vocabularies and ontologies, there is a strong implication of time-boundedness. A term is "valid" for use at the start, and then at some point it becomes "invalid", and should not be used beyond that time (the LCSH case); on the other hand, a term is valid for use at the start, becomes invalid after a certain point, but remains valid for application to documents created before that point (the corporate body case). I think this points to a version-control solution for handling deprecation. Which in turn means reificatio
n ...
>
> I think applications which use data/triples from vocabularies which are volatile will have to take account of version control, whatever form it takes (reification, quadruples, etc.). Applications will need to distinguish what is currently valid, what was valid and is no longer, what was valid and remains valid for then but is not valid for now, etc. What about historic data, where validity is relative to a time period? An application might want to recast a snapshot (or final state) of an old catalogue as triples which retain the data as-it-was: Cookery-isa-Authority.
>
> btw, a bit far-fetched but not impossible: what happens if Cookery is an Authority, then is deprecated so that Cookery is a Variant, and then is re-instated so Cookery is an Authority again? Unless you have timestamps or some other form of version control, the result is completely incoherent.
>
> Generally, all the information pertaining to a "resource" in the Semantic Web needs to be encoded in RDF so that it can be processed by machine. This includes changes of status/version/etc. Triples can be "changed" only by adding the new version of the triple to the Semantic Web pool. I don't think it's possible to amend every copy of a triple, so the new version sits alongside the old and we need a way of distinguishing them if semantic collisions are to be avoided.
>
> The idea of adding yet another class to represent the status of a term is, I think, indicative that the model needs re-examined.
>
> But whatever model is used, it seems to me that a volatile vocabulary must choose between version control (reification, etc.) and semantic incoherence. The former will enhance the perceived quality of the data; the latter will diminish it.
>
> The sustainability of LD appears to be threatened from the get-go by the AAA rule (Anyone can say Anything about Anything). Provenance will be very, very important, and there is likely to be an evolutionary/ecological organizing principle for the Semantic Web, in much the same way as has occurred with the Web of documents. Good quality, useful data will prevail, and Semantic browsers, applications, etc. will "learn" to avoid poor quality sources of triples - and the absence of version control, etc. will be a factor.
>
> But it would be good to hear comments from those with more expertise and experience; I'm just a cataloguer at heart.
>
> Cheers
>
> Gordon
>
> On 27 January 2011 at 17:07 "Ford, Kevin" <[log in to unmask]> wrote:
>
>  > 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
>

Top of Message | Previous Page | Permalink

Advanced Options


Options

Log In

Log In

Get Password

Get Password


Search Archives

Search Archives


Subscribe or Unsubscribe

Subscribe or Unsubscribe


Archives

December 2023
November 2023
August 2023
July 2023
June 2023
November 2022
October 2022
September 2022
July 2022
June 2022
May 2022
April 2022
March 2022
February 2022
January 2022
December 2021
November 2021
October 2021
September 2021
August 2021
May 2021
November 2020
September 2020
August 2020
July 2020
May 2020
April 2020
March 2020
February 2020
January 2020
December 2019
October 2019
September 2019
August 2019
June 2019
May 2019
March 2019
February 2019
January 2019
November 2018
October 2018
September 2018
August 2018
July 2018
June 2018
May 2018
April 2018
February 2018
January 2018
December 2017
November 2017
October 2017
September 2017
July 2017
June 2017
May 2017
April 2017
March 2017
February 2017
November 2016
October 2016
September 2016
August 2016
July 2016
June 2016
May 2016
April 2016
March 2016
February 2016
January 2016
December 2015
October 2015
September 2015
August 2015
July 2015
June 2015
May 2015
April 2015
March 2015
February 2015
January 2015
December 2014
November 2014
October 2014
September 2014
August 2014
July 2014
June 2014
May 2014
April 2014
March 2014
February 2014
January 2014
December 2013
November 2013
October 2013
September 2013
August 2013
July 2013
June 2013
May 2013
April 2013
March 2013
February 2013
January 2013
December 2012
November 2012
October 2012
September 2012
August 2012
July 2012
June 2012
May 2012
April 2012
March 2012
February 2012
January 2012
December 2011
November 2011
October 2011
September 2011
August 2011
July 2011
June 2011
May 2011
April 2011
March 2011
February 2011
January 2011
December 2010
November 2010
October 2010
September 2010
August 2010
July 2010
June 2010
May 2010
April 2010
March 2010
February 2010
January 2010
December 2009
November 2009
October 2009
September 2009
August 2009
July 2009
June 2009
May 2009
April 2009
March 2009
February 2009
January 2009
November 2008
October 2008
September 2008
August 2008
July 2008
June 2008
May 2008
April 2008
February 2008
January 2008
December 2007
November 2007
October 2007
August 2007
July 2007
June 2007
May 2007
April 2007
March 2007
February 2007
January 2007
December 2006
November 2006
October 2006
September 2006
August 2006
July 2006
June 2006
May 2006
April 2006
March 2006
February 2006
January 2006
December 2005
November 2005
October 2005
September 2005
August 2005
July 2005
June 2005
May 2005
April 2005
March 2005
February 2005
January 2005
December 2004
November 2004
October 2004
September 2004
August 2004
July 2004
June 2004
May 2004
April 2004
March 2004
February 2004
January 2004
December 2003
November 2003
October 2003
September 2003
August 2003
July 2003
June 2003
May 2003
April 2003
March 2003
February 2003
January 2003
December 2002
November 2002
October 2002
September 2002
August 2002
July 2002
June 2002
May 2002
April 2002
March 2002
February 2002

ATOM RSS1 RSS2



LISTSERV.LOC.GOV

CataList Email List Search Powered by the LISTSERV Email List Manager