Sorry for the delay... I'm juggling lots of technologies and the RDF
aspect is one piece of the big puzzle and I'm dividing my time among
them all.
On Apr 18, 2005, at 6:52 PM, Stefano Mazzocchi wrote:
> Erik Hatcher wrote:
>>> the second means that you need a 'rdf:type' statement, or, using
>>> RDF/XML, you need to say something like
>>>
>>> <blah:Blah rdf:about="http://your.host.com/uri/3809480">
>>> ...
>>>
>>> instead of
>>>
>>> <rdf:Description rdf:about="http://your.host.com/uri/3809480">
>>> ...
>> I've now converted to using your recommended syntax. And I'm also
>> adding a <dc:type> element that points to some different metadata
>> that we have. Longwell2 is showing both together as "type" - is that
>> correct? Is the implicit rdf:type somehow connected to dc:type?
>
> hmmm, no, dc:type and rdf:type are two completely different things.
> What do you mean by "joining them together"? are you sure you map the
> dc: prefix and the rdf: prefix to the proper namespaces?
I'll get back to you on this when I can provide more details. I'm
using the right namespaces. I'm not providing an rdf:type explicitly.
> Note: the big advantage of # over / is that you can clearly
> distinguish between the model and the item, when you use / it's hard
> to tell which is the model and which are the items... in welkin, we
> say that the token after the last / is the item and the token before
> that is the model, but it's a heuristical analysis. With # you are
> certain of what the modeler wanted to do.
>
> As a rule of thumb, I use # for ontologies and / for collections, but
> that's my personal perference and not something that is mandated or
> required or even considered a best practice. I find it easier to work
> with.
Thanks for that # versus / info! Very helpful.
>>> If you want to get a little deeper, it's probably easier to keep
>>> asking specific questions here as soon as you encounter a roadblock.
>> With that said, I've gotten a bit further. I've RDF'd the Rossetti
>> Archive files. I've done a 1-for-1 transformation from our XML files
>> into RDF, though I'm sure this is not granular enough. I'm tossing
>> this out details in case someone is interested in pointing me in the
>> right directions - in other words, help if you want, and it'll be
>> appreciated, but worries if not.
>
> I hope you mean "no worries" here ;-) I really hope you don't come all
> the way to boston to beat me up if I don't help you out ;-)
Haha! *no* worries definitely intended :)
>> http://www.rossettiarchive.org/docs/1-1847.s244.raw.rdf
>
> Suggestion, I would split the comma separated subjects in different
> statements.
No question... on the TODO list!
>> How do I represent these connections? For example, we "workcodes" on
>> various objects (down to the <div> level within actual manuscripts)
>> that connect things back to a formal work. You can see this
>> aggregation our collection view like this:
>> http://www.rossettiarchive.org/docs/1-1847.s244.rawcollection.html
>> Hyperlinks with #anchors are down to the <div> level.
>> I've distilled lots of our gory XML metadata out into fields I
>> indexed with Lucene. Queries connecting workcodes can be made like
>> this:
>> http://www.rossettiarchive.org/rose/?query=workcode%3A1-1847.s244
>> Putting these connections into RDF, of course, is the next goal.
>
> Holy cow, that's going to be an interesting modelling and presentation
> problem :-)
The presentation is already handled with the mess of XSLT tricks going
on. But it'll definitely be interesting to see how the connections are
made in RDF.
> Encoding relationships in RDF is easy, just put unique names to all
> the items and write relationships between them:
>
> So, if you have
>
> <div id="1">
> <div id="1.1">
> ...
> </div>
> </div>
>
> in XML, in RDF/N3 it's something like
>
> _at_prefix text: <http://www.rossettiarchive.org/2005/04/text#> .
> _at_prefix ros: <http://www.rossettiarchive.org/docs/1-1847.s244/> .
>
> ros:1
> rdf:type text:Fragment;
> text:contains ros:1.1
>
> ros:1.1
> rdf:type text:Fragment;
Cool. I'll give this a try soon.
>> How can I open up directory full of RDF files in Welkin? Or will it
>> accept a .zip file of .rdf files?
>
> No, but you are welcome to submit a patch :-)
I'll take that as a running invitation!
>> Piggy-Bank - this is right up the "collection" alley we're looking
>> for, but we'll want to be able to collect objects in non-Firefox
>> browsers also somehow. One idea I have is to use a bookmarklet to
>> "Collex It!" which will somehow send information to our system. We
>> could have our archives marked with embedded RDF which is what
>> Piggy-Bank leverages. And we could, perhaps in addition, have a
>> <meta> tag that pointed to the RDF. When our system receives a URL
>> to collect, it'd parse out the RDF and allow the user to pick the
>> specific objects desired. Is this a reasonable approach? What other
>> suggestions do folks have in this regard?
>
> I admit I have not given much thought about an environemnt where we
> don't have full control of the browser... I'll think about it.
Any thoughts on this? Think of our Collex system as a del.icio.us of
archive objects in a way. So the same type of bookmarklets used to add
the current page as a del.icio.us bookmark could be used to feed Collex
the page you're viewing and then our system could extract metadata from
it and let the user pick the object(s) to collect.
Erik
- application/pkcs7-signature attachment: smime.p7s
Received on Wed Apr 20 2005 - 15:46:34 EDT