W3C home > Mailing lists > Public > public-owl-wg@w3.org > October 2007

Re: Serialization issues

From: Elisa F. Kendall <ekendall@sandsoft.com>
Date: Fri, 26 Oct 2007 10:09:21 -0700
Message-ID: <47221F41.60203@sandsoft.com>
To: public-owl-wg@w3.org
Hi,

There are some things that we can do in the metamodel to specify 
ordering - I'll need to investigate what is supported in OCL, as it 
would be better, given that you want it to be optional, to provide 
optional ordering constraints rather than creating mandatory ordering 
requirements on the diagrams themselves.

In the ODM metamodels for RDF and OWL 1.0, we separate the notion of a 
statement occuring in a graph from that same statement occurring in a 
particular document; RDF statements can be ordered within the 
document(s) that they occur in.  This isn't a constraint on the core RDF 
metamodel, but in a separate, optional package where we defined notions 
such as namespaces, URIs, documents, etc.  See section 10.7 in [1] for 
details.  Jeremy and Dave Reynolds helped us tease out the relationship 
between graphs and documents, which may be useful for this discussion.

We should think about whether you want to impose ordering (optionally) 
on all possible concrete syntaxes or only in some cases - say, for 
example, yes if RDF/XML, no if N3.  I'm not advocating either way, but 
the decision to impose ordering, even optionally, if done in the 
abstract syntax, would apply to all potential concrete syntaxes.

FYI, with regard to the imports question, a similar question came up 
when developing ODM, on whether you are importing the ontology or its 
name -- I can argue this both ways, but given that by importing an 
ontology you are committing to all of the facts it contains, aren't you 
really referencing the name and importing the ontology? (That was our 
conclusion at the time.)  I can think of cases where you might want to 
reference "something" in another ontology, but not import it (some 
mapping ontologies come to mind).  We accomplished this via allowing one 
to reference the relevant URI but not import the ontology in that case 
for ODM.  It would be good if you could provide examples of how this 
should work in both cases.

Elisa

[1] http://www.omg.org/docs/ptc/06-10-11.pdf

Bijan Parsia wrote:

>
> On Oct 26, 2007, at 11:01 AM, Peter F. Patel-Schneider wrote:
>
>> How far do you want to carry this trend?  Should we define a canonical
>> order for the serialization of ontolgoies?
>
>
> Yep. Lexicographical would be smart. That's what some serializers do  
> anyway.
>
>>   This would certainly have
>> some advantages (searching, diffs, source control), but also has some
>> drawbacks (inflexibiliy, gratuitous rejection of ontologies).
>
>
> I was thinking of making it optional, or a condition on output not on  
> barring parses. E.g., it would be a canonical serialization.
>
>> How about having the functional-style syntax be very forgiving of  
>> order,
>> but having a suggested ordering?  Tools should then try to  serialize in
>> the suggested order (perhaps with an option to not do so) but would
>> accept "out-of-order" inputs.
>
>
> yeah. that was the basic intention.
>
>> So for ontologies, the suggested order could be annotations first (in
>> some order), followed by imports, followed by declaration and entity
>> annotation then class then object property then data property then
>> individual axioms (each in some order).  However, the function-style
>> syntax would be something like
>>
>> ontology := 'Ontology' '(' ontologyURI
>>                           { importDeclaration | annotation | axiom }
>>                 ')'
>
>
> I'm pretty indifferent to exactly how we spec this. One could always  
> have a tighter grammar and then relax things.
>
>> By the way, it appears that the UML diagram for ontologies is not  quite
>> right.  Shouldn't the imports of an ontology be ontology names, not
>> ontologies?
>
>
> From a specing api point of view, I would think that the former is  
> correct.
>
> Cheers,
> Bijan.
>
>
>
>
Received on Friday, 26 October 2007 17:09:47 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:13:26 GMT