JiscMail Logo
Email discussion lists for the UK Education and Research communities

Help for DC-ARCHITECTURE Archives


DC-ARCHITECTURE Archives

DC-ARCHITECTURE Archives


DC-ARCHITECTURE@JISCMAIL.AC.UK


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

DC-ARCHITECTURE Home

DC-ARCHITECTURE Home

DC-ARCHITECTURE  February 2012

DC-ARCHITECTURE February 2012

Options

Subscribe or Unsubscribe

Subscribe or Unsubscribe

Log In

Log In

Get Password

Get Password

Subject:

Re: DCAM - collecting requirements and examples

From:

Karen Coyle <[log in to unmask]>

Reply-To:

DCMI Architecture Forum <[log in to unmask]>

Date:

Wed, 15 Feb 2012 14:03:20 -0800

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (240 lines)

On 2/15/12 12:30 PM, Jon Phipps wrote:
> Are we only talking about Linked Data or are we talking about information
> modeling?

I doubt if it makes sense to take on the entirety of information 
modeling within the DCAM. My impression was that the goal was 
information modeling for the Semantic Web/linked data environment. If 
it's broader than that, then we move up from abstract to something so 
far out it may never be finished. I'd say that we should stick with an 
abstraction that is an abstraction of something useful, not a pure 
abstraction.

DCAP is a documentation model for describing an information
> ecosystem and DCAM is its formal abstract 'domain' model, or should be.

DCAP to me is narrower than that. It describes a coherent set of 
statements for a particular metadata activity. It verges on being a 
record format, although it is a "record format" in a data environment 
that is more flexible than, say, a relational database with a set data 
format. I'd equate the Singapore framework's domain model with an 
"information ecosystem." That to me is the general model before you 
start adding constraints, and perhaps even before you define your set of 
properties.

And, as I said before, DCAM to me defines the design patterns that are 
available to you. It is plausible to me that DCAM's patterns have some 
universality, but I wouldn't want to embark on a task of making sure 
that DCAM covers every single metadata possibility, known today or to be 
discovered in the future. That would probably prevent DCAM from have 
such specifics as "property URIs" or "literal values." It's going to be 
hard enough to come up with a model that functions well within the 
semantic web universe.

kc

> Whether or not that model results in Linked Data is beside the point, isn't
> it?



>
> Jon,
> who just found this and had to paste it here:
>
> Endless invention, endless experiment,
> Brings knowledge of motion, but not of stillness;
> Knowledge of speech, but not of silence;
> Knowledge of words, and ignorance of the Word...
>
> Where is the Life we have lost in living?
> Where is the wisdom we have lost in knowledge?
> Where is the knowledge we have lost in information?
>   -- T. S. Eliot, Choruses from 'The Rock'
>
>
> On Wed, Feb 15, 2012 at 11:26 AM, Karen Coyle<[log in to unmask]>  wrote:
>
>> Hmm. In terms of analogies, I would equate DCAP with a data dictionary,
>> not DCAM. To me a data dictionary is the actual metadata elements you will
>> use, not an abstract definition of the possible structures. DCAM seems to
>> be closer to the idea of "design patterns."
>>
>> I don't see how something can be linked data if it doesn't have certain
>> characteristics:
>> - http uris
>> - subjects, predicates, objects (whether serialized as triples or not, and
>> RDF/XML and turtle are examples of not)
>> - subjects and predicates constrained as URIs; objects constrained
>> differently (which DCAM would address)
>>
>> It's possible that the JSON examples in that blog post met these criteria
>> (I didn't perceive URIs for the predicates, but maybe I don't read JSON
>> well).
>>
>> kc
>>
>>
>> On 2/15/12 7:58 AM, Jon Phipps wrote:
>>
>>> Re: "Underneath it all you still have to have something that expresses
>>> valid triples, n'est pas?"
>>>
>>> Actually, my point here is that there are many data serializations, models
>>> and use cases for creating, validating, and distributing metadata and many
>>> of them don't include a notion of triples, (e.g. nosql) although many of
>>> them do include a notion of domain-specific validity and some form of
>>> distribution. RDF is extremely useful for distributing metadata in an Open
>>> World context, but it's hardly the only data model and hardly the only
>>> method of distributing useful metadata.
>>>
>>> We need to provide, or at least try to provide, a specification that makes
>>> it possible for an organization to describe how they expect the 'things'
>>> they know about to be described: which properties are valid or not, what
>>> constitutes valid data, and what does each property mean. In the old days,
>>> this model used to be called a 'data dictionary' and it's an incredibly
>>> useful concept in a world of distributed heterogeneous data. Providing a
>>> way for someone to create a single 'data dictionary' that can be used
>>> (preferably by a machine) to create validations for domain-specific data
>>> and that can be used by anyone (preferably a machine) in the organization,
>>> or alternatively in the world, to understand the meaning of that data
>>> across departmental, organizational, or national boundaries would be
>>> incredibly and fundamentally useful.
>>>
>>> If we say that RDF is the ONLY useful way to do this, then we might as
>>> well
>>> go back to "DCAM is just RDF".
>>>
>>> Jon
>>>
>>> I check email just a couple of times daily; to reach me sooner, click
>>> here:
>>> http://awayfind.com/jonphipps
>>>
>>>
>>> On Wed, Feb 15, 2012 at 9:47 AM, Karen Coyle<[log in to unmask]>   wrote:
>>>
>>>   What *does* seem to be core in this blog post is the use of http URIs for
>>>> values. I'd add to that: properties defined with http URIs, so you know
>>>> what you are describing. Although you can serialize all of this in JSON
>>>> if
>>>> you wish, it means that you have started with LD concepts, not the usual
>>>> JSON application. Underneath it all you still have to have something that
>>>> expresses valid triples, n'est pas?
>>>>
>>>> kc
>>>>
>>>>
>>>> On 2/15/12 5:49 AM, Jon Phipps wrote:
>>>>
>>>>   I've been doing some wandering around in JSON land for the last few days
>>>>> and, as part of a continuing observation that RDF is an implementation
>>>>> detail rather than a core requirement, I'd like to point to this post
>>>>> from
>>>>> James Snell
>>>>> http://chmod777self.blogspot.****com/2012/02/mostly-linked-****
>>>>> data.html<http://chmod777self.**blogspot.com/2012/02/mostly-**
>>>>> linked-data.html<http://chmod777self.blogspot.com/2012/02/mostly-linked-data.html>
>>>>>>
>>>>>
>>>>> And the JSON Scema spec: http://json-schema.org/
>>>>>
>>>>> Jon,
>>>>> who may someday get his act together and pay attention to these meetings
>>>>> more than a couple of hours before the meeting.
>>>>>
>>>>> On Tuesday, February 14, 2012, Thomas Baker<[log in to unmask]>    wrote:
>>>>>
>>>>>   On Tue, Feb 14, 2012 at 05:25:17PM -0500, Tom Baker wrote:
>>>>>>
>>>>>>   --  that DCAM should be developed using a test-driven approach, with
>>>>>>>      effective examples and test cases that can be expressed in various
>>>>>>>      concrete syntaxes.
>>>>>>>
>>>>>>>
>>>>>> Jon suggested that we take Gordon's requirements for metadata record
>>>>>>
>>>>>>   constructs
>>>>>
>>>>>   [1] as a starting point.  As I understand them, these are:
>>>>>>
>>>>>> --  the ability to encode multicomponent things (which in the
>>>>>> cataloging
>>>>>>     world happen to be called "statements", as in "publication
>>>>>> statement"
>>>>>>     and "classification statement") either:
>>>>>>
>>>>>>     -- as unstructured strings, or
>>>>>>     -- as strings structured according to a named Syntax Encoding
>>>>>> Scheme,
>>>>>>
>>>>>>   or
>>>>>
>>>>>      -- as Named Graphs with individual component triples
>>>>>>
>>>>>> --  the ability to express the repeatability of components in such
>>>>>>
>>>>>>   "statements"
>>>>>
>>>>>
>>>>>> --  the ability to designate properties as "mandatory", or "mandatory
>>>>>> if
>>>>>>     applicable", and the like
>>>>>>
>>>>>> --  the ability to constrain the cardinality of "subsets of properties"
>>>>>>     within a particular context, such as the FRBR model
>>>>>>
>>>>>> -- the ability to express mappings between properties in different
>>>>>>
>>>>>>   namespaces.
>>>>>
>>>>>
>>>>>> It has also been suggested that we find examples of real metadata
>>>>>> instance
>>>>>> records from different communities and contexts -- e.g., libraries,
>>>>>>
>>>>>>   government,
>>>>>
>>>>>   industry, and biomed -- for both testing and illustrating DCAM
>>>>>> constracts.
>>>>>>
>>>>>> Tom
>>>>>>
>>>>>> [1]
>>>>>>
>>>>>>   https://www.jiscmail.ac.uk/****cgi-bin/webadmin?A2=ind1202&L=****<https://www.jiscmail.ac.uk/**cgi-bin/webadmin?A2=ind1202&L=**>
>>>>> dc-architecture&P=6405<https:/**/www.jiscmail.ac.uk/cgi-bin/**
>>>>> webadmin?A2=ind1202&L=dc-**architecture&P=6405<https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind1202&L=dc-architecture&P=6405>
>>>>>>
>>>>>
>>>>>
>>>>>> --
>>>>>> Tom Baker<[log in to unmask]>
>>>>>>
>>>>>>
>>>>>>
>>>>>   --
>>>> Karen Coyle
>>>> [log in to unmask] http://kcoyle.net
>>>> ph: 1-510-540-7596
>>>> m: 1-510-435-8234
>>>> skype: kcoylenet
>>>>
>>>>
>>>
>> --
>> Karen Coyle
>> [log in to unmask] http://kcoyle.net
>> ph: 1-510-540-7596
>> m: 1-510-435-8234
>> skype: kcoylenet
>>
>

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

JiscMail Tools


RSS Feeds and Sharing


Advanced Options


Archives

November 2019
September 2019
August 2019
July 2019
June 2019
May 2019
April 2019
March 2019
February 2019
January 2019
December 2018
November 2018
October 2018
September 2018
August 2018
July 2018
June 2018
May 2018
April 2018
March 2018
February 2018
January 2018
December 2017
November 2017
September 2017
August 2017
July 2017
June 2017
May 2017
April 2017
March 2017
February 2017
January 2017
December 2016
November 2016
October 2016
September 2016
August 2016
July 2016
June 2016
May 2016
April 2016
March 2016
February 2016
January 2016
December 2015
November 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
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
September 2007
August 2007
July 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
September 2005
August 2005
July 2005
June 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
March 2004
February 2004
January 2004
November 2003
October 2003
September 2003
August 2003
June 2003
May 2003
April 2003
March 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
January 2002
December 2001
November 2001
October 2001
September 2001
August 2001
July 2001
June 2001
May 2001
April 2001
March 2001
February 2001
December 2000
November 2000
October 2000


JiscMail is a Jisc service.

View our service policies at https://www.jiscmail.ac.uk/policyandsecurity/ and Jisc's privacy policy at https://www.jisc.ac.uk/website/privacy-notice

Secured by F-Secure Anti-Virus CataList Email List Search Powered by the LISTSERV Email List Manager