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

 


Help: OASIS Mailing Lists Help | MarkMail Help

humanmarkup-comment message

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


Subject: Re: [humanmarkup-comment] Referents


Looks good to me. Maybe Len can do a DTD? I know he's working on the 
DTD for the semiotic engine. DTDs are arguably simpler in that they 
narrow focus onto very specific kinds of documents. I'm inclined 
toward default namespaces, but I could be persuaded against it if we 
get our elements and attributes qualified without having elements or 
attributes with the same name but different definitions in other 
vocabularies with which we need to be compatible and consistent.

Thanks, Manos.

Ciao,
Rex

At 4:49 PM +0300 8/22/02, Emmanuil Batsis (Manos) wrote:
>Bullard, Claude L (Len) wrote:
>
>>The value of a referent is likely to be
>><!ELEMENT referent (URI | (some set of element names)+) >
>><!ATTRIBUTE referent
>>   rdf:id  #REQUIRED >
>>
>>or something like that.  I put the URI there because it might be 
>>useful to point to something uniquely, or to use a unique URI as 
>>the proxy name.
>>
>>Ok, Manos.  How much trouble did this start? :-)
>>
>
>The only trouble is me; I don't speak DTDs ;-). But from what I can 
>see and the RDF-friendly approach we are trying to work out the 
>above goes towards
>
><referent rdf:id="rdfid1">
>   <uri>http://www.mydomain.com/some/dir</uri>
></referent>
>
>minimized as
>
><referent rdf:id="rdfid1" uri="http://www.mydomain.com/some/dir"; />
>
>What bother me is the child elements I don't know about; that's what 
>this RDF-friendly approach is all about. We will have to ensure that 
>child elements map both syntactically and logically into RDF 
>predicates (properties), having the referent as a subject, while 
>also fitting the simple XML viewpoint.
>
>Also, we may want to use rdf:about instead of rdf:id to specify we 
>are talking about a certain resource instead of something that 
>currently is in memory under the id reference.
>
>Some people may dissagree but I would like every element and 
>attribute node to be qualified and default namespaces to be avoided. 
>What do you think?
>
>Anyway, here is the RDF friendly version (i made up the HumanML namespace:
>
><huml:referent rdf:ID="rdfid1">
>    <huml:uri rdf:resource="http://www.mydomain.com/some/dir"/>
></huml:referent>
>
>This produces the following two triples:
>
><#rdfid1> <rdf:type> <huml:referent> .
><#rdfid1> <huml:uri> <http://www.mydomain.com/some/dir> .
>
>
>You have probably noted the rdf:resource attribute, I included it so 
>that we can be able to view the uri value as a resource under RDF. 
>If we just want literals, we can convert the above to:
>
><huml:referent rdf:ID="rdfid1"
>  huml:uri="http://www.mydomain.com/some/dir"/>
>
>The triples now are
>
><#rdfid1> <rdf:type> <huml:referent> .
><#rdfid1> <huml:uri> "http://www.mydomain.com/some/dir"; .
>
>The only difference is the literal view of the uri object. 
>Personally, I would urge you folks to favour against literals, as 
>they are more or less useless under RDF. You cannot use them as 
>subjects so you can't say anything about them.
>
>For people that don't know what is going on, Len had the idea to 
>combine our markup design with RDF, so that people can use it either 
>as vanilla XML or RDF; personally I like the idea, although we are 
>still trying to erase the rough edges. This means that one will be 
>able to use either a simple XML parser or an RDF processor to 
>process our markup. It may also mean that we may be able to use both 
>XML Schema languages and RDF Schema for the same format.
>
>How does all this looks?
>Cheers,
>
>MAnos
>
>
>
>
>
>
>----------------------------------------------------------------
>To subscribe or unsubscribe from this elist use the subscription
>manager: <http://lists.oasis-open.org/ob/adm.pl>


-- 
Rex Brooks
Starbourne Communications Design
1361-A Addison, Berkeley, CA 94702 *510-849-2309
http://www.starbourne.com * rexb@starbourne.com



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


Powered by eList eXpress LLC