OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office-metadata message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [office-metadata] Question about the IRI of a RDF subject from anODF document


Hello Elias,

I think I can speak for all that it is good to see you back on the list.
Your technical experience is as welcome as needed as you just proved 
again. I am honestly happy to have you back in the SC.
The usage of xml:base seems to be a very good idea.

I am not sure, if this SC has to solve the following xml:base related 
problem, at least it plays into the area of #10 on our list "How do we 
cope with changes in content".

I assume the base URL describes as well the document instance, which is 
usually described by no reference at all.
Which means, if the RDF reference of the document instance is being 
changed, all relative references to resources in the document are being 
changed as well and by this their RDF references.
Meaning that by changing the RDF subject of the document instance, all 
RDF subjects of the contained resources are being changed and are 
something completely new to RDF applications.

Let me give an example:
We use an ODF invoice template containing a certain imagine, which stays 
the same in all invoices.
I assume that the base URL for the invoice document would change for 
every new invoice written.
How would a RDF application is able to figure out that the images in the 
document are all the same, when the base URL and by this the image RDF 
reference is always different?

Some might say a possible solution could be to change the base URL with 
every save of the document, by this we would be sure to talk about a new 
instance. We could use an owl:sameAs to the first URI used by the 
template or the URI of the first occurrence of the resource in the document.
On the other hand in the end the user has to define, when the resource 
is being changed in a way that it is no longer correct to give an 
owl:sameAs.

My sincere condolences for your loss, Elias.

Regards,
Svante

Elias Torres wrote:
> Hello everyone,
>
> I'm slowly starting to get back to work, after a long hiatus, but not only
> because of my vacation but due to a death in the family and an additional
> personal accident I had. I hope things have progressed while I was gone and
> that there's still ways in which I can offer some help to the group. Let me
> try for example to suggest some things on the subject of this email. Please
> forgive me if I repeat some suggestion stated before and whether it was
> already made clear that what I'm suggesting either doesn't apply or the
> group decided it was not the right solution. I acknowledge I am not fully
> up to date with all of the discussions that have been going on during my
> absence.
>
> -Elias
>
> Svante.Schubert@Sun.COM wrote on 02/05/2007 03:10:55 PM:
>
>   
>> Bruce D'Arcus wrote:
>>     
>>> On Jan 30, 2007, at 1:51 PM, Bruce D'Arcus wrote:
>>>
>>>       
>>>> This is a trick issue, BTW. Ideally you want a globally unique IRI
>>>>         
>
> Definitely a tricky situation. But one that needs to be addressed. First, I
> don't think that there is a simple solution (e.g. an almighty IRI that will
> solve all of the problems). In my opinion, it's just a matter of providing
> enough metadata to describe whatever it is that we are trying to
> communicate/document.
>
>   
>>>> with which you can also locate the document. But that's not realistic
>>>> in many desktop scenarios, so I think you're left with two choices:
>>>>
>>>> 1) the one above
>>>> 2) using a URI-encoded UUID
>>>>         
>>> Well, and of course using the Flickr URI, which would be good for this
>>> particular case.
>>>       
>> By this we have at least one case where the RDF subject IRI is not the
>> reference to the local instance.
>> As we use the flickr URL as the RDF subject IRI, we are in need of a way
>> to reference to the image from our RDF syntax.
>> Only by this, the RDF application would know, that we are talking about
>> a picture in this document.
>> BTW a similar reference would be needed for linking to other ODF
>> elements, for instance if we would like to reference to a certain ODF
>> table or the linked image, that is being used in the document.
>>
>> My question to you now, is it from the RDF point of view  sufficient to
>> say, we have this picture somewhere in this document?
>>
>> In N3 something like:
>> <> has <http://www.flickr.com/photos/images/holidayimage.png> .
>>
>> Or are we in need of a package URL to the described content?
>>
>> In N3 something like:
>> @prefix odf: <http://www.oasis-open.org/package-rdf#>
>> <http://www.flickr.com/photos/images/holidayimage.png> odf:pack-ref
>> <odf:/images/holidayimage.png>
>>
>> (A package URL  as relative URI references are not allowed in RDF URI
>> References [1] )
>>     
>
> You can't use a relative URI in a triple at the model level, but you can
> use a relative URI in the serialization of triples.
>
> In a document located at /home/eliast/package.n3 you can have the
> following:
>
> <eliast.jpg> dc:title "Elias' mugshot" .
>
> When the document is loaded eliast.jpg would be resolved to the URI:
> "file:///home/eliast/eliast.jpg".
>
> However, we need more than that, because our package doesn't have a stable
> location. Hence, I would suggest we ground it on some URN, like LSID for
> example or whatever.
>
> urn:lsid:www.oasis-open.org:SOME_PACKAGE:SOME_UUID/eliast.jpg
>
> Now if we use RDF/XML we can make use of
> xml:base="urn:lsid:www.oasis-open.org:SOME_PACKAGE:SOME_UUID/".
>
> <eliast.jpg> dc:title "Elias' mugshot" .
>
> For the case that the same exact picture lived on Flickr, then we can use
> owl:sameAs:
>
> <eliast.jpg> owl:sameAs
> <http://www.flickr.com/photos/images/holidayimage.png> .
>
> N3 doesn't have an @base property like SPARQL or RDF/XML, but Turtle which
> is updated by the SWIG, is in the process of adding such extension.
>
>   
>>> Might be nice if we could add the ability to have both a path and a
>>> global IRI in the manifest entry for a file.
>>>
>>>       
>> [1]  Note: Relative URI references are not allowed in RDF URI References:
>> "RDF URI references are compatible with the anyURI
>> <http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#anyURI> datatype as
>> defined by XML schema datatypes [XML-SCHEMA2
>> <http://www.w3.org/TR/rdf-concepts/#ref-xml-schema2>], constrained to be
>> an absolute rather than a relative URI reference.", taken from
>> http://www.w3.org/TR/rdf-concepts/#section-Graph-URIref
>>
>>     
>
>   


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]