OR 08 and 0.3 specification fallout - OAI-ORE

Message from discussion OR 08 and 0.3 specification fallout

Mark Diggory

More options Apr 15 2008, 1:06 pm

From: Mark Diggory <mdigg...@MIT.EDU>

Date: Tue, 15 Apr 2008 10:06:09 -0700

Local: Tues, Apr 15 2008 1:06 pm

Subject: Re: OR 08 and 0.3 specification fallout

  Reply to author
  |
  Forward
  | Print
  | View thread
  | Show original
  | Report this message
  | Find messages by this author
  

On Apr 14, 2008, at 6:56 AM, Graham Triggs wrote:

> On Apr 11, 11:30 pm, Mark Diggory <mdigg...@MIT.EDU> wrote:
>> I'll bite!
>> 1.) I think a specification defining URI that are not "opaque" is
>> overly restrictive and introduces a significant overhead in
>> complexity that developers will have to implement on top of the
>> existing RDF tool set.

> I'm pretty sure you aren't arguing for 'true' opaque URIs ;)

Correct, I simply mean the spec does not define what the structure of
a URI should and leaves that open to the implementer to decide.
However, there may be recommendation or best practices on the usage
of such URI and that such should be clearly identified as such if
used within "the spec".

> Besides, any overhead from processing an invented URI schema is
> entirely dependent on what the details of such a scheme would be.

Just the word "invented" is enough to ruffle my feathers on this
subject. Your example: "ore:aggregation;http://server.com/resource"
alone presents:

1.) The requirement for the specification to define the internal
structure of a URI.

2.) And as such that development of tooling to support parsing that
representation when

<#myAggregation> ore:aggregatesAggregation <http://server.com/some/url>
<#myAggregation> ore:aggregates <http://server.com/some/other/url>

Is ultimately transparent and requires no tooling beyond an RDF
parser and an a Http Client to acquire. Besides this, if in Atom,
something like a <category> is used to identify if an ore:aggregates
points at a resource or an aggregation (as captured in the Atom
schema and not some "invented URI" why impose on the RDF community
that some invented URI be used over a properly defined, schema
enforced validate-able approach?

>> 2.) If its not the case that URI are opaque, I make the argument that
>> new RDF predicates are cheaper and more easily enforced in the model
>> and require much less development effort to work with than a wholly
>> custom URI syntax.

> New predicates add verbosity to the document (increased transfer
> time), and more interactions with the XML serialization toolkits. At
> this point, you would have to define your concept of cheaper ;)

Thats such a load of bunk... is custom code somehow guaranteed to be
more efficient than a standard parser?

> Also, it's only easily enforced in the model if the model allows it to
> be enforceable. This is the problem with the current specification -
> the ore:isAggregate (or whatever it is) predicate is not a MUST, which
> means it can't be enforced, and if you are presented with an RDF
> document that does not contain any of these predicates, how do you
> determine if they were simply omitted, or if the aggregation is truly
> not aggregating other aggregations?

Not sure what this has to do with URI, seems more schema/ontology
related.

> For this to be practical in the real world for anything more than a
> niche set of use cases for a niche community, this kind of details
> needs to be:

> a) enforceable
> b) enforced
> c) clearly and obviously described in the specification, not tucked
> away where it is easily missed

[warning... stereotyping ahead]

This is an argument on a continuum of evolutionism vs. creationism...
Evolutionist say, establish the smallest possible set of laws to
enforce on a system and see what emergent behavior arises... while
the Creationist say, define the entire mechanism, top to bottom,
written in stone, and damn all who do not comply. Seems to me, folks
that come from the RDF World ascribe to the former and those from XML
Schema world tend to the later, both could stand to learn a little
from each other.

>> Placing semantics in the URI makes it necessary to
>> require tooling to parse and interpret the URI, which makes the
>> information lost to generic SW/LOD clients and tooling like RDF
>> triplestores/SPARQL etc...

> If a generic client encountered the URI for an aggregation, would it
> know how to derefence the URI to obtain a ReM, and continue processing
> that ReM?

If its a #name, that is something outside the spec that suggests an
identifier referenced within the document. If its a relative or
absolute uri, it suggests that its resolvable separately from the
Aggregation, and in RDF it doesn't need to be either, it could be a
bare node or and id reference that is used to locate the ReM wholly
independent of any uri based rdf:reference, which is what Robert
Sanderson is talking about.

> Besides, these clients are bound to potentially encounter URIs that
> aren't regular http/https/ftp, etc. schemas (as there is no RDF
> specification that limits the URIs to being just that) - so wouldn't
> they have some way of coping with arbitrary URI schemas?

No not necessarily... Why overcomplicate things with such complexity.

>> And following my above position, that
>> distinction should be in the model and not hidden in the syntax of a
>> URI.

> Or it could be both. One other argument to consider is that URI-As,
> etc. can be cited... you may not be seeing those URIs only within the
> confines of a semantic document describing aggregations (or semantic
> links to those documents from resources). So you could argue that it
> should be clear from the URI that you are talking about an
> aggregation, or you can argue that the URI should be resolvable in a
> web browser and redirect / display human readable information about
> that aggregation. Either way, we would benefit from strong
> recommendations as to how this should be approached, rather than
> hoping it works itself out.

I wouldn't rely on the URI's structure, I've not ever seen an RDFS/
OWL ontology that explicitly says a URI representing this object has
to adhere to "X structure"... The closest thing I can think of is
DCMI Encoding schemes. But even then, I'm not convinced I know of any
validation engine outside of those for w3c XML Schema that might be
capable of validating such structure. And even then, I think it'd be
a real pain to get right and would be much easier to do in the
"model" rather than its "referencing mechanism".

In programming, do you code a variable that may be dereferenced by
the languages standard dereferencing mechanism, or do you make up a
wholly new and different dereferencing mechanism for that language
because you think the the byte addresses being dereferenced should
use N-1 bits instead of N bits? I don't think so. Same here, why go
outside the scope of the language to force the developers to do
unnecessary work to manufacture semantically encoded URI when they
could just use a predicate?

Ultimately, I finally got what Rob is saying about

AggrParent ore:aggregates AggrChild
AggrChild rdf:type ore:Aggregation

And I rather agree now, just define another statement about the
aggregation in the instance, it may not be "everything" about that
aggregation, it is simply "stuff about this aggregation in relation
to the current Aggregation". I.E. just add a third level to your rdf
with the statements necessary to identify that something is an
aggregation. This is something I am now adding to my prototype.

-Mark

Reply to author Forward