W3C home > Mailing lists > Public > public-xg-omm@w3.org > October 2011

Re: Object Memory Modeling XG and RDFa

From: Jens Haupert <jens.haupert@dfki.de>
Date: Mon, 24 Oct 2011 12:13:29 +0200
Message-ID: <4EA53A49.5080601@dfki.de>
To: Manu Sporny <msporny@digitalbazaar.com>
CC: Alexander Kröner <Alexander.Kroener@dfki.de>, Sebastian Germesin <sebastian.germesin@dfki.de>, Massimo Romanelli <massimo.romanelli@dfki.de>, Felix Sasaki <felix.sasaki@dfki.de>, "public-xg-omm@w3.org" <public-xg-omm@w3.org>, public-rdfa-wg@w3.org
Hello,

thank you very much for your feedback. I added some comments.


Am 10.10.2011 04:28, schrieb Manu Sporny:
>
> 1. You should be using RDFa 1.1. Instead of xmlns:, use prefix, like
> so:
> prefix="omm: http://www.w3.org/2005/Incubator/omm/elements/1.0/"

fixed.

> 2. Your declaration of xsd is not correct, it should be:
> prefix="xsd: http://www.w3.org/2001/XMLSchema#"

fixed.

> 3. Your OMM vocabulary isn't human or machine readable, you should
> public a vocabulary document at:
> http://www.w3.org/2005/Incubator/omm/elements/1.0/

At the moment, we do not have a simple human readable vocabulary 
document, that can be reached with this url. You can find further 
information at the XG report 
(http://www.w3.org/2005/Incubator/omm/XGR-omm-20111026/XGR-omm.html#n3). 
What does "machine readable" mean?


> 4. I suggest that you do not version your vocabulary with minor
> release information unless you intend to publish minor releases,
> and if so, those minor releases shouldn't break backwards
> compatibility in which case the minor release number doesn't
> matter. In other words... just use major numbers:
> http://www.w3.org/2005/Incubator/omm/elements/1/

fixed. (1 instead of 1.0)

> 5. You don't need to express the version number of your vocabulary,
> your vocabulary URL above does that. Don't do this:
> <span property="omm:version">1</span>

fixed.

> 6. If your primary ID is a URL, it should be expressed as one, so
> instead of this:
> <span property="omm:primaryID">http://example.com/p1</span>
> do this:
> <a rel="omm:primaryID" href="http://example.com/p1">...</a>
> You should be doing this with all of your URLs

This link may be an URL but this is not mandatory, it can be any string.

> 7. This whole Header, Table of Contents, Block stuff in OMM just
> does not seem like the right way to model this information. You
> have a graph data structure available to you... don't treat it
> like tape-based storage data structure. :)

Our approach is "how to express the fixed, block-based OM-model with 
RDFa-strucutures", not "how to encode some data in RDFa the best 
possible way" (please take a look to our report at 
http://www.w3.org/2005/Incubator/omm/XGR-omm-20111026/XGR-omm.html#n3). 
So an RDFa enriched HTML5 document should lead to the same model as our 
sample XML files and other/binary encodings.

> 8. omm:uri - this term is suspect... why do you need it? IRIs are
> first-class citizens in RDF. Do this instead:
> <a rel="omm:additionalBlock" href="http://URL_OF_BLOCK">...</a>

see (6.)

> 9. omm:type is suspect as well. Instead of this:
> <span property="omm:type">omm_http</span>
> do this:
> <span typeof="omm:Http">...</span>
> or something to that effect.

fixed.

> 10. This is redundant:
> <span property="omm:date"
> datatype="xsd:dateTime">2011-01-31T08:12:50+02:00</span>
> of encoding: <span property="omm:encoding">ISO8601</span>
> xsd:dateTime is an ISO8601 formatted date, you don't need to
> specify that it is again in the next triple.

fixed.

> 11. omm:hasTag looks a bit like a mess - it looks very complicated and
> open ended.
>

we simplyfied this area as much as possible.

> Other than that, the RDFa markup looks fairly good. I think the biggest
> issue is the OMM vocabulary itself - it seems to be over-modeling. If
> you don't make the vocabulary simpler, the chances of uptake are reduced
> greatly.
>

we keep this in mind and try to ease our approach.

> Instead, of trying to think of it in terms of Headers and Tables of
> Contents and Blocks... just think of modeling the data as you would a
> real object - just add Event objects to the main object and timestamp
> them. That said, I don't really know what use cases you need to support
> - but the vocabulary seems quite complex for the intended use (and it's
> not documented, so I can't understand how each vocabulary term is meant
> to be used).
>

see (7.).


We would be pleased to receive your feedback again. Thank you in advance 
for your help.


Best regards,
Jens Haupert


-- 
Jens Haupert (M.Sc.)
DFKI GmbH Campus D3_2 Stuhlsatzenhausweg 3 D-66123 Saarbrücken
Phone: +49 681 85775 5319
Fax:   +49 681 85775 5021
Mail:  jens.haupert@dfki.de
Web:   http://www.dfki.de/~haupert

-------------------------------------------------------------
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
Trippstadter Strasse 122, D-67663 Kaiserslautern, Germany

Geschaeftsfuehrung:
Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster (Vorsitzender)
Dr. Walter Olthoff

Vorsitzender des Aufsichtsrats:
Prof. Dr. h.c. Hans A. Aukes

Amtsgericht Kaiserslautern, HRB 2313
-------------------------------------------------------------


Received on Monday, 24 October 2011 10:14:07 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 24 October 2011 10:14:08 GMT