W3C home > Mailing lists > Public > www-rdf-interest@w3.org > December 2001

Re: RDF/XML Syntax Specification (Revised) W3C Working Draft published

From: Mike Moran <mmoran@netphysic.com>
Date: Fri, 21 Dec 2001 12:04:20 +0000
Message-ID: <3C232544.40204@netphysic.com>
To: "Thomas B. Passin" <tpassin@home.com>, RDF Interest List <www-rdf-interest@w3.org>
Thomas B. Passin wrote:

> [Mike Moran]
> 
> 
>>What it all seems to boil down to though is that I can't represent that
>>
> two
> 
>>resources share some properties in a portable (vanilla RDF) way. I either
>>
> have to
> 
>>preprocess my own internal vocabulary into RDF, doing the expansion
>>
> pre-RDF, or
> 
>>define some rules to post-process the RDF model to make the inferences I
>>
> require.
> 
>>
> 
> Wait a minute here.  Why can't Mike create a resource having whatever value
> he wants, and then create statements for both Tom and Jane saying that they
> have that same resource as the object of the appropriate property?  That's
> how you would do it in a normalized database.  It's true that this isn't the
> same as inheritance, but Mike said he wanted a single point to update, and
> this would do it.
> 
> This sharpens the question some: Mike, do you really want some kind of
> "inheritance", or do you want single-point update capability for equal data
> values?  Put another way, can you move from a programming viewpoint to a
> database viewpoint?  Because an RDF statement can be viewed much like a row
> in a database.
[ ... ]


Ok, to give a concrete example of what I am trying to do:

I am using the head-body[1][2] pattern to represent meta-data associated 
with some content. I've attached the metadata in this way since the 
document will be passed around via email and suchlike, so we need to 
ensure it stays together, and because some metadata will likely be used 
to affect how the body is processed later.

Now, at least two things are represented in this metadata: what the 
whole document is, and what the enclosed body is. For instance, the 
whole body is called a controlled document ie it has various Dublic Core 
attributes attached to it such as author and so on. Then there is the 
body, which by dint of being enclosed in the document should also be a 
controlled document, sharing some control information (author, rights 
etc), but has some other properties such as format (eg text/html) and a 
type (plus possibly other properties) which tells the system what it 
should do with it. So, we have whole-document metadata, and sub-document 
meta-data, with the RDF trying to represent the shared properties explictly.

On top of this, I'd like to factor out shared properties such as rights 
into a separate document, so that it can be changed once (eg if it is 
just to fix mistakes such as "Foo Ltd" -> "Foo Ltd."). Also, following 
from this, additional in-house attributes could be added to a type 
without needing to update all current live documents.

Now, there a couple of things about this which make me reconsider using 
RDF at all apart from what we've discussed here already. All points 
concern the representation of resource addresses. I've used 
<rdf:Description rdf:about=""> to imply that a statement is about `this' 
document. I've added an id to the body part of "body", and I make 
statements about this using <rdf:Description rdf:about="#body">. For 
expression of a type I've tried using <rdf:Description 
rdf:about="http://www.madeupname.com/RDF/Types/Common"> or suchlike.

I'm not entirely sure if this is an appropriate usage scenario for rdf 
since I am making statements about things which exist in email and in 
the local filesystem ie not on the globally addressable internet.

As it stands, I'm currently favouring dropping RDF but keeping related 
things such as the basic Dublin Core properties.

Btw, thanks everyone for the clarification on classes, types and properties.

[1]: http://www.xmlpatterns.com/HeadBodyMain.shtml
[2]: http://www.xmlpatterns.com/SeparateMetadataAndDataMain.shtml


--
Mike
Received on Friday, 21 December 2001 07:04:54 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:51:52 GMT