Account Options

  1. Sign in
The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Google Groups Home
« Groups Home
comp.text.sgml
+ new post
About this group
Subscribe to this group
This is a Usenet group - learn more
Message from discussion A DTD for Personal Identity
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
Ashley Colin Yakeley  
View profile  
 More options Oct 11 1996, 3:00 am
Newsgroups: comp.text.sgml
From: Ashl...@halcyon.com (Ashley Colin Yakeley)
Date: 1996/10/11
Subject: Re: A DTD for Personal Identity
Print | View thread | Show original | Report this message | Find messages by this author

In article <vwjwwwyj3k3....@osfb.aber.ac.uk>, p...@aber.ac.uk (Piercarlo

Grandi) wrote:
> The formats you allude to above are defective not because they are not
> ``rich'' enough, but because they are based on weak data models. Now,
> designing a proper data model is not an easy thing; using a document
> structure notation (based on somewhat context free grammars) as a data
> modeling notation does not quite work.

Why not? SGML is powerful enough: I can simply use links to represent any
arbitrary graph, either within a document, or between documents.

> Just to illustrate some issues, consider the simple idea that if you
> know ten people that all work for the same company at the same site, you
> don't want to replicate the common data many times; also, if some
> people, e.g. consultants, work at several companies, or some employee
> work at several sites for the same company, you also want to avoid
> duplicating data about that as well.

It seems to me this is a problem arising from the need for documents to be
self-contained for interchange, but 'relational' (i.e. common data
factored out) when stored in a database. This means no matter what
data-formats I use, some kind of processing needs to be done when
accepting a new entry into the database.

Therefore, I claim:

1. SGML markup can represent information, not just document structure. I
believe SMDL is an example of this: it can represent music directly (its
'logical domain', 'cantus' elements), as well as documents/scores ('visual
domain', 'score' elements).

2. It's possible to create an SGML DTD powerful enough to properly
represent the information in interchange documents. I can even use ID and
IDREF attributes (or HyTime clinks) to represent any graph, not just
trees. Interchange is actually the main purpose of these documents -
simply storing a list of interchange documents is not an ideal format for
a database, even though most contact-managers do just that.

3. It's possible to design a contact-manager to recognise already existing
data in one of these interchange documents, and use that to build a
relational database. It may even be possible to store the database as a
list of documents using the same or similar DTD as interchange documents,
but with documents linking to other documents in the database for their
information.

> You end up with a many-to-many relationship between people and
> companies, and perhaps a one-to-many between companies and sites. These
> cannot be expressed easily with anything but a full featured data model,
> (relational, DBTG CODASYL, E-R, and a few others) and not even with
> HyTyme (SGML DTDs describe hierarchical structures; HyTime describes
> graph structures, indirectly).

Isn't a graph structure the same thing as a many-to-many relationship?

> What one can do in SGML is not quite to "describe the information
> properly and clearly", but to describe, properly and clearly, _reports_
> containing that information. Then the very useful and important theme of
> using SGML DTDs to describe the structure of database output comes
> out...

I believe SMDL can represent information directly, and I believe there are
a number of other existing applications of SGML that involve representing
semantic information rather than reports of that information.

--
Ashley Colin Yakeley


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
©2013 Google